Attestation — full text

What a NeuralRing attestation proves — and what it does not

This note is for an operator's compliance team to hand to an auditor. It states, in plain language, exactly what a NeuralRing attestation signature means. The engine is specified in CLAUDE.md Phase 4; this is the human-readable contract.

The one sentence that matters

This signature attests that NeuralRing performed the routing recorded in `observed` and faithfully recorded the serving endpoint's declarations in `claimed` at the stated assurance level. It does NOT attest that inference physically executed in `claimed.executionJurisdiction`, nor that the endpoint's self-declared properties are true. The strength of any jurisdictional claim equals `claimed.assurance` and no more.

Why two blocks

Every record is split into two clearly separated parts, and the split is the whole point:

• `observed` — facts NeuralRing can prove, because it performed and

measured them: which endpoint it dispatched to, the host it actually dialed (connectedHost), the full chain of route hops and their outcomes, the metered input/output token counts, the finish reason, and the latency. The signature genuinely stands behind these.

• `claimed` — the serving endpoint's own declarations: its execution

jurisdiction, data-center region, operating-entity and parent jurisdictions, key custody, log residency, sovereignty tier, and — decisively — its assurance level. NeuralRing routed to an endpoint that declares these things. A single transaction does not independently prove geography or custody.

These are never merged into one assertion such as "inference ran in ES." A signature looks like proof; collapsing an unproven claim into it would manufacture exactly the overclaim the assurance ladder exists to prevent. (In the code, that collapse is treated as a P0 bug.)

Worked example — the GX10 box

The operator runs a physical inference box on their own LAN in Madrid and can personally vouch for where it is. Even so, a record served by it reads:

• observed.connectedHost = "192.168.1.20" — provable: NeuralRing dialed that host.
• claimed.executionJurisdiction = "ES" at claimed.assurance = "self_attested"

— the endpoint declares Spain; a LAN probe cannot prove geography, so the claim stays honestly self-attested even though the operator vouches for it.

The observation matches reality; the claim does not pretend to be more than a declaration. That is the honesty test, made concrete.

Under federation (Phase 8)

When a request is federated across operators behind a white-label tenant, the attestation names provenance honestly:

• observed.servedByOperator = { slug, jurisdiction } — the operator (supplier)

that actually served, with the execution jurisdiction NeuralRing observed for that endpoint. A federating tenant cannot paint this greener than the endpoint's substantiated assurance — claimed.assurance is still the serving endpoint's real level.

• observed.servedViaTenant — the federating tenant slug.
• A cross-operator failover records each operator hop in observed.routeHops

(failover then served), so "your inference kept running, in-jurisdiction, provably — and here is which operator carried it" is auditable.

Both fields are omitted for first-party (non-operator) requests, so prior records and the verification script stay byte-compatible (the canonical hash drops absent fields).

When the server is an NVIDIA AI Grid (Phase 10)

A delegating AI Grid does its own intra-grid placement, so it hands NeuralRing most of the attestation metadata for free. A record served by one carries an observed.aiGrid provenance block — metadata only:

• observed.aiGrid = { backedBy: "nvidia-ai-grid", controlPlane, servingRuntime, intraGridDelegated, affinityHonored? }

— that NeuralRing dispatched to a catalogued grid, delegated intra-grid routing to the operator, and what the grid reported (whether prefix/KV affinity was honored).

• observed.routeHops[].gridNode / gridRegion — the node/region the grid reported

as having served; reason carries the SLA/cache outcome (kv-cache hit/miss) and, on a cross-grid failover, the affinity context reset note.

• claimed.dataCenterRegion is set to the grid-returned region when the grid

reports one (the operator's orchestrator is the source of truth for placement).

What this block does NOT prove (the AI-Grid-specific honesty caveats):

1. Vendor ≠ operator. backedBy: nvidia-ai-grid records that NVIDIA technology

served the request — NIM/Dynamo on the operator's metal. It does not mean NVIDIA operated or could access the data. The CLOUD-Act exposure that matters is in claimed (tier/assurance) and reflects the operator's posture, not the vendor's. The provenance block is a technology marker, not a sovereignty signal — an AI-Grid endpoint can be any tier.

1. Hardware-supply dependency is a separate, un-erased axis. Even a Tier-0/1 EU

grid runs on US-export-controlled NVIDIA GPUs. Where aiGrid.hardwareSupplyDependency is set, the honest framing is "data-sovereign, hardware-supply-dependent": the data is sovereign at the stated tier, but continued hardware supply depends on US export licensing. This does not lower the tier (the tier measures data custody) and a GPU export-control event raises a customer-facing supply-risk notice, not a tier downgrade.

1. NVCF/telemetry posture is only as strong as `claimed.assurance`. A grid that is

self_attested on its no-hosted-NVCF / no-telemetry-egress posture says so; the attestation never paints an unverified grid as fully sovereign because it sits in the EU.

When a record carries location evidence (Phase 16)

Two optional observed surfaces may appear; both are NeuralRing-performed-verification facts, and neither changes what claimed.executionJurisdiction means:

• observed.networkRegionBound — NeuralRing measured challenge round-trips from

named third-party landmarks to the endpoint at measuredAt, and the minimum RTTs bound the responding key's distance to the stated disks. Read the method: tee-bound-latency-v1 binds a non-exfiltratable TEE key (inherits the CC integrity residuals); tls-bound-latency-v1 binds only the endpoint's TLS key, which the operator custodies — relayResidual: true states that an in-region front defeats it. In both cases this is a physics corroboration with a TTL, not a legal-jurisdiction proof: borders cut disks, a key is not a computation, and the field never raises `claimed.executionJurisdiction`'s assurance. The landmark locations are themselves host- or NeuralRing-attested (named in trustAnchors).

• observed.locationCertification — NeuralRing checked a named scheme's registry

snapshot at checkedAt and a named human reviewed the scope. Read certifiedGranularity: today's strongest live schemes (SecNumCloud, HDS) certify EU/EEA-bloc execution/residency — so a record may honestly show executionJurisdiction: "DE" @ self_attested beside executionRegion: "EU/EEA" @ certified. The bloc certificate never paints the country claim.

• observed.facilityCorroboration — what NeuralRing machine-verified about a named

facility (existence in a registry, an archived operator-letter hash, a geofeed RPKI signature). Confidence only, never a rung — the DC operator is a coercible business partner, not an auditor. Renders strictly below verified.

What none of this proves: which country inside the certified bloc; which building; that the operator could not be compelled elsewhere (that is the tier/GLEIF axis); anything after the TTL. The strength of a country-level jurisdictional claim equals claimed.assurance for that claim — and no more. All three fields are optional; canonicalization drops them; every prior record's hash and signature are byte-identical and verify under the unmodified scripts/verify-attestations.mjs.

The ceiling, stated plainly: country-level certainty of execution location is not purchasable, buildable, or attestable by anyone today — and NeuralRing's records will keep saying so until that changes.

The assurance ladder (what claimed.assurance means)

certified is never written without a live certification reference. A certification a provider merely claims (unverified) does not count and is not carried into certificationRefs.

What a `verified` composite covers — and what it deliberately leaves separate (Phase 29 §2, owner ruling 2026-07-12). claimed.assurance = verified states that the entity, parent, and execution location are proven from captured evidence. It says nothing about the two DOCUMENTARY claims — data residency and key custody — which are raised only by a captured binding document or a location-auditing cert. Those two are carried and rendered as their own per-claim status beside the composite (observed/claimed per-claim block, /verify/:id, catalog, badge), never folded into the verified rung. So a record may honestly read assurance: verified with dataResidency and keyCustody still self_attested — that is the composite working as designed, not a gap being hidden. The documentary claims remain required for Tier-0, the :sovereign variant, and any certified composite.

Operational vs jurisdictional verification are separate axes. A conformance probe can prove an endpoint works as claimed (operationally verified) but can never prove where it runs. assurance tracks only the jurisdictional axis, so operating a box yourself is exactly self_attested jurisdictionally.

Tamper-evidence (no blockchain)

Records are append-only and hash-chained: each record stores the previous record's hash in prevRecordHash, and its own recordHash is the SHA-256 of its hashable view (every field except recordHash, signature, signingKeyId), canonicalized with sorted keys. recordHash is then signed with Ed25519.

Because each link commits to the one before it, altering any stored field — or reordering records — changes a hash and breaks the chain at the altered link.

Verifying an export yourself

1. GET /api/v1/attestations/export?from=…&to=… returns a bundle: the records,

the genesis hash, the public key, and the signature statement above.

1. Run the standalone verifier (only Node's crypto, no NeuralRing code):

``bash node scripts/verify-attestations.mjs bundle.json ``

It recomputes every hash, checks the chain from genesis, and verifies every signature against the published public key. Green means: the records are intact, in order, and signed by the holder of the published key — i.e. the observed facts are exactly as NeuralRing recorded them, and the claimed declarations are reproduced at their stated assurance, nothing more.

1. The bundle embeds publicKeyPem. To confirm it is genuinely NeuralRing's,

cross-check it against the canonical, published copy:

`` https://neuralring.eu/.well-known/neuralring-attestation-key.pub ``

This is the LIVE key the deployment signs with (served from the control-plane API, never a committed copy) — so it matches the key that signed your records. The GET /api/v1/attestations/public-key endpoint returns the same key with its signingKeyId, genesis, and signature statement.

Content

Prompts and completions are not logged by default. If an org opts into content logging, only a hash (contentHash) of prompt+completion is stored — never the text.

Phase 14 — the observed.quorum block (multi-model trajectories)

A request to the neuralring/quorum meta-model dispatches several turns (Thinker → Worker → Verifier, stopping on Verifier ACCEPT). Its attestation carries the whole trajectory in observed.quorum:

quorum: {
  turns: [{ endpointId, role, outcome, tokensIn, tokensOut }, …],
  terminatedBy: "verifier_accept" | "budget_exhausted" | "pool_too_small",
  coordinatorKind: "heuristic",   // v1; a future trained coordinator is distinguishable
  totalTurns
}

The field is optional and omitted for non-Quorum requests — canonicalization drops absent fields, so every pre-Phase-14 record's hash and signature are byte-identical and the unmodified scripts/verify-attestations.mjs verifies mixed chains (gate-verified).

The conservative-minimum rule. The claimed block of a Quorum attestation is bounded by the WEAKEST endpoint actually used in the trajectory — never the best one, never an average (buildQuorumClaimedBlock):

• sovereigntyTier = worst (highest) tier across used endpoints;
• assurance = lowest assurance rank across used endpoints;
• executionJurisdiction / dataCenterRegion = the deduped union of every

used endpoint's claim (the trajectory genuinely touched all of them);

• entity/parent/custody/log-residency fields come from the weakest-link

endpoint (its exposure bounds the whole claim);

• certificationRefs = the intersection of verified refs across ALL used

endpoints — a cert only part of the trajectory holds would overstate.

terminatedBy: "budget_exhausted" means the turn budget ran out without a Verifier ACCEPT: the answer returned is the last Worker output, and the response's finish_reason says budget_exhausted — it is never presented as equivalent to an accepted answer.

Report packs (Phase 26 — "The Notary")

A proof pack is a self-verifying zip a compliance team generates for a period and hands to an auditor. It is a presentation of signed records, never a new claim (§1.2 attestation honesty). Contents:

report.pdf      human-readable rendering (neutral ink; no compliance verdict)
report.csv      one row per record
records.json    the org's attestation records, verbatim (the /export inner shape
                + publicKeyPem + signatureStatement — self-contained)
manifest.json   SIGNED: sha-256 of every other file + the ProofSummary + the
                chain-check statement + the signing-key id
PROVES.md       what this pack proves / does not prove (from a committed template)
verify-pack.mjs zero-dependency offline verifier, copied verbatim from scripts/

What the manifest signs. manifest.json is canonicalized with the same canonicalize and signed with the same Ed25519 attestation key as the records. Its preimage is sha256(canonicalize(manifest-without-signature)). verify-pack.mjs recomputes that, checks the signature, then checks every file hash, every record signature, and recomputes the ProofSummary from `records.json` and diffs it against the manifest — a report that disagrees with its own records fails verification (summarizeAttestations is mirrored in verify-pack.mjs, the browser lib, and the pure module; all three must agree).

Subset ≠ chain (the honesty split). The attestation hash chain is global across all orgs; an org's records are a filtered subset, so prevRecordHash continuity cannot be recomputed from the subset. A pack therefore offers two distinct things, never merged into one "chain verified" claim:

1. Per-record signature verification over the org's subset — offline, by

anyone, with no NeuralRing account.

1. A global-chain segment check (verifyChainSegment) run server-side at

pack generation, recorded inside the signed manifest as NeuralRing's own signed statement (chainCheck, statementBy: "neuralring"), clearly labelled as such and independently checkable from a full export.

Painting subset-signature-verification as chain verification is a §1.2 violation. PROVES.md states this split in plain words; the auditor room renders it too.

Verify a pack:

unzip neuralring-proof-<org>-<period>.zip && cd neuralring-proof-<org>-<period>
node verify-pack.mjs manifest.json    # manifest sig → file hashes → record sigs → summary recompute
curl -s https://neuralring.eu/.well-known/neuralring-attestation-key.pub  # cross-check the key

Exit 0 = every check green; any tampered byte in any artifact fails with the specific finding.

Coverage. The one figure derived from usage_events/rollups (not the records) is the coverage statement: attested N of metered M requests. If N ≠ M the gap is printed prominently in the summary, the PDF, and PROVES.md — never reconciled away.

The Observatory (Phase 39) — proxied vs witnessed, declared upstreams, integrity, framework packs

Phase 39 adds three optional observed blocks. Nothing else changes: routing, tiering, canonicalisation, hashing, signing and verification are byte-for-byte the Phase-38 code, and every record and export written before Phase 39 verifies unmodified (canonicalize drops absent fields; the frozen dev-compose chain of 555 records is the test oracle in packages/sovereignty/src/__fixtures__/).

observed.upstreamOrigin — catalog | org_declared

Where the serving endpoint came from. catalog is the public supply admitted through the Assay Office / Night Watch. org_declared is an upstream the org declared for itself (its own Azure OpenAI deployment, its Bedrock region, its OpenAI organisation, its on-prem vLLM). A declared upstream is recorded, never endorsed: it routes only for its owner (the pin, min_tier and min_assurance apply unchanged — an org pinned to DE at verified cannot be served by its own self-attested Azure Germany West Central deployment until NeuralRing's own probes have corroborated it), it never appears in the public catalogue, and its claimed block is built from its declared profile at the assurance the evidence supports — self_attested with confidence < 1 until a NeuralRing probe substantiates a field. Presets pre-fill declarations from the provider's own published pages (source + date on every field); they never raise assurance. An Azure OpenAI deployment in Sweden Central resolves to Tier 2 (EU residency, non-EU control); OpenAI or Anthropic direct resolve to Tier 3.

observed.observation — the FOURTH independent statement

Every receipt already states three things that are never merged: whether the signature verifies, whether the request was served, and how strongly the sovereignty claim was substantiated. Phase 39 adds a fourth, observation provenance:

• `proxied` — NeuralRing dialled the upstream itself and observed the connection.

Every gateway record from Phase 39 on carries this. (A record with no block predates Phase 39; NeuralRing routed it — proxied by construction.)

• `witnessed` — the customer kept its traffic where it was and dropped a witness

into its own client or gateway. The witness signed a content-free record (host, resolved address, leaf-certificate hash, status, model, tokens, latency, the policy it intended); NeuralRing verified the witness signature against the org's registered Ed25519 public key at receivedAt, ran its own corroboration from its own vantage (DNS resolution, ASN/registry-country of the addresses, the leaf certificate it fetched, a registry-country check where a region was declared), and chained the record under a wit_ request id with the witnessed timestamp.

What NeuralRing's signature says for a witnessed record — and no more: that it received the signed witness record at receivedAt, that the signature verified against the registered key, and that it obtained the corroboration result it recorded. The connection facts are the witness's observation. A witnessed record's execution-location assurance is capped at `self_attested` unless NeuralRing's own corroboration fully matched (host resolved, address and certificate agree, declared region consistent) and the endpoint's own evidence already stood at verified — then verified, never `certified` (a witness is not a third-party audit). Corroboration is a check, never a location proof beyond the claim level; the block carries that caveat in the record itself.

A customer could fabricate observations. The record is honestly labelled witnessed; the corroboration is NeuralRing's; the cap applies; the pack says who observed what. This is disclosed, not hidden.

observed.upstreamAttestation — integrity, never location (§3.30)

Some upstreams expose an attestation artefact (an NVIDIA NRAS EAT, an Azure Attestation JWT, a Confidential Space token, a provider transparency-log entry). NeuralRing records it and verifies it with its own code against the issuer's published keys (injected trust anchors, never fetched on the request path) and reports exactly one of:

• valid, request-bound — the token carries the nonce the gateway minted for this

request (x-nr-attestation-nonce); what ran and how, for this request;

• valid, not request-bound — a platform statement, not a per-request one;
• invalid — signature or freshness failed;
• offered but not verifiable by NeuralRing (privatemode / tinfoil / other formats

without an in-house verifier) — recorded, not trusted;

• not offered by this upstream — the honest state for every hyperscaler API endpoint

(Azure OpenAI, Bedrock, Vertex, OpenAI, Anthropic expose none to the caller).

The governing rule: integrity evidence proves what ran and how — never where. No verdict here moves claimed.executionJurisdiction, claimed.assurance, the tier or any SEAL value; it is rendered as its own line on the receipt, beside the four statements and never inside them. The shelved Sealed Stack's hardware_attested rung is not produced by this block.

Framework packs and control statements (Δ4)

POST /api/v1/proof/packs takes kind ∈ {records, dora, gdpr-transfers, ai-act, iso42001}. Every pack now carries controls.json — control statements computed as pure functions over the org's records for the period under the org's baseline policy: the share of requests served in the required jurisdiction(s) split by assurance level, the share by tier ≤ N, the count of tier-3 servings, failover counts, the proxied/witnessed split, the declared-upstream share, the provider list with the tier and assurance range each served at, and the integrity split. Each statement records the record range and the first/last record hashes it was computed over; `verify-pack.mjs` recomputes every statement from `records.json` and fails the pack on any mismatch. A framework pack adds framework.json (the mapping table: framework field → evidence source → attestation/profile path → caveat) and assurance-profiles.json (the latest profile of each declared provider, named without any org id).

Framework mappings are vocabulary, not verdicts (§3.29). A mapping says which evidence answers which field of DORA's register of information, GDPR's transfer questions, the AI Act's logging and retention articles or ISO/IEC 42001's supplier controls. It never says an obligation is met. Every framework pack and every control statement carries the non-determination note verbatim; the auditor keeps the judgement.

What a declared-provider assurance profile is (Δ3)

For each provider an org declared, NeuralRing runs the same probes it runs on the catalogue — company registry (GLEIF by LEI, then name), hosting provenance, location probe where a region was declared, certification registries for the schemes the org listed, and a documentary capture of the provider's own DPA / sub-processor / residency pages — and produces a dated assurance profile private to that org. Every field carries source, checkedAt, assurance and confidence; it never reaches certified (a document or a probe is not a third-party audit). A worsening between two profiles — a sub-processor list whose content hash changed, a live certification lost, an ownership change to a non-EU parent matched by LEI, a new hosting/location contradiction — raises a claim-watch alert and immediately cascades to the org's declared endpoints through the shared Phase-25 demotion cascade. An ownership change matched by name only escalates to a human and cascades nothing (SOVEREIGNTY.md §7c). Nothing learned about a declared provider is written to a catalogue row or shared across orgs.

The Manifest (Phase 40) — derived statements over records and profiles

The manifest, the check, the substitutes, the gap rows, the certificate and the continuity statement are DERIVED statements computed over attestation records and assurance profiles that already exist. They are not themselves attested facts: none of them is a record in the hash chain, none moves any value on any ladder — a substitute is the routing filter's own output under the customer's stated policy (a recommendation, dated, expiring), a gap row names an absent piece of evidence and why, a certificate states what was verified, at what assurance, over what coverage and until when. The certificate and the continuity statement are signed with the same Ed25519 key and the same discipline as a record (canonical JSON → sha256 → signature over the hash's UTF-8 bytes) so they can be verified offline (verify-certificate.mjs), but a signature makes them NeuralRing's statements, not facts about a provider: signing never raises a claim. Records after the newest witnessed anchor carry the line "no external time bound yet" (below).

The Witnesses (Phase 33, executed in Phase 40) — observed.anchorRef and what an anchor proves

The field. observed.anchorRef (optional) names the newest anchor event the gateway knew when it wrote the record: { anchorSeq, anchorHash }. It is ADDITIVE and byte-compatible — canonicalize drops undefined, so every pre-anchoring record hashes and verifies exactly as before (both frozen fixtures, 555 dev and 163 GX10, verify unmodified with the post-40 code).

The anchor event. Several times a day (or every N records, whichever bound is reached first, and only when the head moved) the sweep publishes the chain HEAD — its seq and recordHash — to independent external witnesses and records their receipts in an anchor event: its own hash chain (prevAnchorHash → anchorHash), signed with the same key as the records. Witnesses today: RFC 3161 time-stamping authorities in the EU (labelled qualified or non-qualified per service — the free defaults, DFN and Certum, are non-qualified and every surface says so) and a fast-forward-only public witness log on Codeberg (anchors/<seq>.json); OpenTimestamps is built and off.

What it proves. WHEN a chain head existed — no later than the witnessed moment recorded by each witness — and that every auditor sees the one chain: because an anchor's hash commits to unpredictable witness material, a record carrying it provably came into existence after that anchor's witnessed moment; a record whose position lies at or before a witnessed head existed no later than that moment. A record therefore has a two-sided time bound (GET /api/v1/anchors/bounds/:requestId, rendered on /verify/:requestId as its own neutral line). The same anchor number with a different head hash in two sources is a split view — evidence that two chains were shown; verify-anchors.mjs --other detects it.

What it does not prove. Where inference ran, what a provider is, or the quality of any claim. An anchor raises no assurance level, tier, ring or SEAL objective and is no routing predicate. A witness failure is a recorded gap, never filled later; if every witness failed the segment is unanchored and says so. The in-app parser only structure-checks an RFC 3161 token (imprint, nonce, time); openssl ts -verify -digest <headHash> -in <receipt.tsr> -CAfile <TSA root> is the cryptographic path, with the TSA's root obtained out of band.

Verify it yourself. node scripts/verify-anchors.mjs export.json anchors.json receipts/ (zero dependencies): records + chain, the anchor chain, head membership of every anchored head, anchorRef back-references, per-record time bounds, receipt bytes against the recorded hashes, and the exact openssl line per receipt. Proof packs carry an anchors block (the events bracketing the pack's records; PROVES.md states the absence honestly); certificates carry the same block and verify-certificate.mjs checks that the named events bracket the certificate's record range. The public feed is /api/v1/anchors and /.well-known/neuralring-anchors.json; the history page is /verify/anchors. Not even NeuralRing can rewrite this history.