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.