Tenon

Every claim on this site, and the artifact behind it.

The estate is synthetic. Every count below is a property of the software, not of usage. Nothing here is argued; each item states what ran, when, and what it does not cover.

What the conformance runs are, and are not

These are the standards bodies' own test suites, self-hosted and run in full. Each run ships the suite's own signed export — every file signed by the suite — committed beside its record, so the result can be checked without taking our word for the log.

They are not a certification. Certification is a separate published status with its own process and register. What is claimed here is that the suites were run and what they returned.

OpenID4VP — the catalogue verifying

9 passed · 0 failed1 skipped2026-08-30

plan    oid4vp-1final-verifier-haip-test-plan
suite   OpenID Foundation conformance-suite
format  sd_jwt_vc      profile  haip

  verifier-happy-flow ................ PASSED
  verifier-minimal-cnf-jwk ........... PASSED
  verifier-invalid-kb-jwt-signature .. PASSED
  …
       9 PASSED · 1 skipped · 0 warning · 0 failed

Run 2026-08-30, self-hosted and offline. Every malformed presentation was correctly refused. Signed export: 21 signatures, committed with the record.

OpenID4VCI — the issuer issuing

14 passed · 0 failed3 warning · 4 skipped2026-08-30

plan    oid4vci-1_0-issuer-haip-test-plan
suite   OpenID Foundation conformance-suite
format  sd_jwt_vc      profile  haip

  happy-flow (235 conditions) ......... PASSED
  happy-flow-multiple-clients ........ PASSED
  fail-invalid-client-attestation .... PASSED
  …
      14 PASSED · 3 warning · 4 skipped · 0 failed

Run 2026-08-30. Signed export: 43 signatures, committed with the record. The full ceremony passes end to end — pushed authorization request with client attestation, a DPoP-bound token, holder proof of possession, and a key-bound SD-JWT VC.

What is unrun is unrun by choice. Signed metadata, batch issuance, key attestation and response encryption are not advertised by the issuer, so the suite skips them. Each is left to the first consumer that needs it rather than built speculatively.

The EU reference issuer

SD-JWT VCISO mdoc2026-08-31

A credential issued by the European Commission's own reference issuer, acquired live on 2026-08-31 and verified in both formats: SD-JWT VC through the x5c chain to the reference PKI, then ISO mdoc — CBOR and COSE, holder binding, replay and relay rejection.

Two negative cases hold: a credential presented by the wrong key is refused, and an untrusted authority fails closed. This is the run that verifies the trust layer against an issuer other than our own.

RESO Commander

Valid metadataData Dictionary 1.72026-08-30

Valid metadata on Data Dictionary 1.7, validated by RESO's own tool against the live catalogue rather than a local build, on 2026-08-30. Two entity types are served, and sixty-two fields on the property resource — forty of them the standard's own, twenty-two declared local extensions.

Scope, stated because the tool's name invites a wider reading: this is metadata validation. It answers whether the served schema is valid, and it does not compare declared types against the Data Dictionary. That comparison is a separate harness and has not been run.

What the credential discloses

GET /.well-known/openid-credential-issuer

"format": "dc+sd-jwt",
"claims": [
  { "path": ["free_market_eligible"],  "sd": "allowed" },
  { "path": ["affords_rent_1750"],    "sd": "allowed" },
  { "path": ["jurisdiction"],  "sd": "never", "mandatory": true },
  …
]

Twenty-one claims in total: nineteen the holder may disclose, and two provenance claims that may never be hidden — which jurisdiction decided, and which version of the rulebook. An answer without those cannot be judged.

The public register

Three requests, no account and no permission. The first returns a signed head; the second proves any single entry is in the log; the third proves the log only ever grew.

GET /ledger/checkpoint
"tree_size": 1028,
"root_hash": "143adf0beb5a2907…2680b70ae1f4",
"signed_at": "2026-08-30T23:21:36Z",
"signature": "eyJhbGciOiJFUzI1NiIs…"   ES256

GET /ledger/proof?seq=1            leaf + audit path to the root

GET /ledger/consistency?first=1000&second=1028
"first_root": "1070c391…3400d8"   ← the older head still proves

Read 2026-08-30. Served by the catalogue, which holds no key: the signature is the orchestrator's, and its verification key is published separately, so the party serving the record is not the party that signed it.

The third request is the one that matters. A rewritten history can always be re-signed into a tree that looks sound on its own; what it cannot do is still produce the root an earlier head was already signed over. The log is an RFC 9162 Merkle tree — the construction that made the web's certificate authorities auditable.

No person appears in it. The record is emitted per listing, never per person, and a published figure is suppressed until at least ten lettings stand behind it.

The counts, and what each covers

  • 7,456 testsRun by the push gate before any commit leaves a machine: the architecture and unit tiers of all three services, plus the issuer's verdict tiers against a real database. Integration, mutation and cross-service contract tiers exist and are not in this gate.
  • 92 rulesAcross 14 policies. Every rule cites the law or market convention it comes from; the column is mandatory, and none of the 92 is empty.
  • 21 statutory valuesEach carrying a source URI, a publication date and the quoted text it was read from — all three populated on all 21. Six further values are market convention rather than statute.
  • 21 modelsSeven BPMN process models and fourteen DMN decision tables, openable in any conformant modeller.
  • 66 decision recordsOf which 13 record a later supersession, amendment or correction in their status.
  • 322 componentsLicence-audited across the three services from reproducible inventories. Scope is the application layer: the container base image and the vendored front-end libraries are outside it, and both are recorded as such in the inventory's own README.

Version, and what would move it

0.9.03 of 10 criteria met7 open

0.9.0 closes development. 1.0.0 is reserved for ten stated exit criteria. A version that moves without a criterion moving is a version nobody can read.

Three of the ten are met and dated: the walk-throughs across all three roles, the go-live prerequisites, and the issuer's verdicts being emitted by the governed decision model. Seven remain, and they are the reason the number is 0.9.0 rather than 1.0.0.

Disclosed rather than discovered

The forward roadmap is a roadmap. Eleven capabilities are recorded as trigger-gated seams, each with the condition that would open it. Three have code behind them today; the remaining eight are reasoned prose and nothing more. Building any of them before its trigger fires would be over-engineering, which is why they are written down rather than built — but a roadmap must never be read as an implementation.

The front-end libraries are outside the licence audit. The inventories cover the Python application layer. The vendored browser libraries and the container base image are not in them, and the inventory README says so rather than leaving it to be found.

The estate is synthetic. There are no real data subjects in it. That is what makes every figure above inspectable, and it is also the reason none of them is a usage claim.