§ Transparency

What we publish about ourselves

Tessaliq's receipts let a third party check what happened for a single verification. This page is meant to cover the complementary view — what happens across all verifications (volume, conformance rate, latency, which wallets interact with the verifier, which errors appear) — so that an auditor, a Relying Party or a curious reader does not need to take Tessaliq's word for the shape of the operation.

Inaugural report — Q2 2026

The first quarterly snapshot is targeted for early July 2026, covering April–June 2026. The dashboard itself is a work in progress — right now this page lists what the report will contain and what it will not, so the commitment is public before the data is.

Framing document : receipt spec §8, internal runbook reference docs/ops/observability.md.

What the report will contain

Verification volume — total sessions that reached a terminal state (verified or failed) over the reporting period, broken down by credential format (mdoc / SD-JWT-VC) and by environment (production / staging).
Conformance rate — share of sessions that reached verified vs those that failed with a known error class. Published absolutely, not as a marketing claim.
Rejection class breakdown — when sessions fail, in which class (invalid signature / unknown trust chain / policy not satisfied / credential expired / nonce replay / format error / other).
Latency percentiles — p50 and p95 of the full /v1/sessions/:id/proof duration over the reporting period.
Wallet coverage — which wallets / issuer IACAs have issued at least one credential the verifier accepted during the period, listed by IACA subject.
Quarterly commentary — interop issues encountered (anonymised), credential non-conformances detected, spec version support changes (OID4VP / HAIP / DCQL), security events if any.

What will never appear in this report

Per-Relying-Party breakdown. Aggregation is done at the level of the whole verifier, not per tenant. A Relying Party's traffic must not be inferable from our publication.
Per-session identifiers. Session IDs, request IDs, organisation IDs never appear in the public numbers.
Wallet user attributes. None are in our logs to begin with (ARCOM double-anonymity by design), but it bears restating as published policy.
Real-time data. The page is a snapshot, refreshed at reporting cadence. No live feed, no per-event stream. Reducing attack surface on the observability endpoint itself is deliberate.
IP addresses, user agents. Redacted from logs, never aggregated for publication.

Anonymisation rules

A rejection class with fewer than 10 events over a reporting period is merged into "other" rather than published on its own. This prevents inference of small-population patterns.
Wallet coverage is listed by IACA subject, not by a per-IACA session count. Prevents ranking of wallet adoption.
Latency percentiles are derived over at least 1 000 sessions, or reported as "insufficient sample" otherwise.

Cadence

Q2 2026 (inaugural report) — published early July 2026, covering April-June 2026.
From Q3 2026 onwards — quarterly, first week of the following quarter.
Ad-hoc security notices — published immediately if a key rotation or a verified vulnerability affects the trust model, without waiting for the quarterly.

Verify receipts yourself, programmatically

The @tessaliq/receipt-verifier library (MIT-licensed, source on GitHub) lets any third party — auditor, regulator, Relying Party, curious developer — verify a Tessaliq receipt JWT cryptographically without coordination with us. The library reads only the public, unauthenticated /.well-known/jwks.json endpoint, and supports fully air-gapped operation by accepting a pre-fetched JWKS.

Three lines of TypeScript :

import { verifyReceipt } from '@tessaliq/receipt-verifier'

const result = await verifyReceipt(receiptJwt)
if (result.valid) console.log(result.claims)

The receipt format specification (v1.0-draft) documents every claim, the cryptographic guarantees (§8) and the known limitations (§9). It is the source of truth that the library and the Tessaliq signer both implement against. The CHANGELOG tracks every change, and the package will be promoted from 0.1.0-draft to 1.0.0 once a real wallet end-to-end run has been verified through the library (see spec §10).

Not yet on npm — the publication is gated on Tessaliq incorporation. In the meantime, install via git dependency or clone-and-link as documented in the package README.

Why this exists

Verifier products typically return a boolean yes/no over an API call and keep the logs on their side. When an auditor asks for proof, the verifier hands over an extract — so the audit depends on the logs being accurate. Publishing aggregate metrics on a fixed cadence is one way to reduce how much of that depends on taking the verifier's word.

The per-verification receipt and this quarterly dashboard are the two surfaces that let a third party reconstruct the audit trail using the cryptography and the published aggregates, rather than direct access to Tessaliq's internal logs.