Skip to content

What the Record Does Not Cover

This page states, in plain words, the things an AuditProof does not cover — including the cases where the record you would expect does not exist at all. It is a scope statement, not a reassurance. Where a limit is unflattering, it is written that way on purpose, because a reader deciding whether to rely on the record needs the boundary drawn honestly before their counsel draws it for them.

It is the de-identification-stage companion to the Threat Model & Proof Semantics page. The threat model reasons about what the signature covers and what an attacker can and cannot do to a record. This page reasons about what the record means in normal operation — what a field like destruction_state actually asserts, and what happens to the evidence when the real world interrupts. Where the two overlap, this page links across rather than restating.

Deployment posture. The Nanorix-hosted service is an evaluation sandbox and a control plane that does not process regulated data. Production regulated-data processing runs in customer infrastructure (BYOC, per ADR-044). Several limits below only bite in one of those settings, and they say which.

1. What destruction_state asserts — and what it does not

Every AuditProof carries a destruction_state field, and it is bound into the signature — a single character of drift invalidates the whole record. It takes one of three values, and the difference between what each one says and what a reader might assume it says is the most important thing on this page.

complete

complete means: the eight-step destruction pipeline ran end to end without any step returning an error, and the record was signed.

complete does not mean that an independent measurement confirmed zero residual bytes remained on the underlying host. It is a structural assertion that the sequence executed and signed — not a forensic assertion that a separate process scanned memory or disk afterward and found nothing. The state is set once the pipeline reaches the point where the volatile workspace (its in-memory filesystem, its ephemeral keys, its network namespace, its cgroup) has been torn down and the destruction steps produced their evidence hashes; it is set at that point unconditionally, before the signature is applied, so that the record reflects what happened even if signing later fails.

A reader who sees complete and reads it as "an auditor-grade residue measurement certified zero bytes remain" is reading more into the word than the system puts there. The eight-step chain records that each subsystem carried out its teardown operation and emitted a proof of having done so. The per-step verification signals those subsystems produce (memory wiped, filesystem clean, zero-state) feed the evidence hash, but they are not surfaced on the wire as independent measurements a verifier re-checks, and in at least one runtime substrate they are constructed as fixed values rather than derived from a post-teardown scan. So a subsystem that returned success while leaving residue would still yield a complete record. Whether that can happen is a property of the substrate the capsule ran on, and Nanorix does not expose, and does not claim, an independent post-teardown residue measurement.

What complete is good for is exactly what it says: it is tamper-evident, offline-verifiable proof that the declared teardown sequence ran to the end and was committed to at a specific time by the holder of a specific key, and cannot be silently revised afterward. That is a real and useful property. It is just a narrower one than the word invites.

incomplete_destruction

incomplete_destruction means a step in the chain returned an error and the pipeline stopped there. The record is still signed, and it carries destruction_failure_step — the number, 1 through 8, of the exact step that failed. This is the honest-failure path: a diagnosed problem is signed and named, never silently relabelled as complete. The failed-step number and the outcome are both inside the signature, so they cannot be edited after the fact without breaking verification.

aborted

aborted means destruction never began as a sequenced chain — for example, the capsule's state was lost to a process or node restart before the teardown pipeline could run. There is no cryptographic chain to compute, so the object is a partial record, and on that path it is not signed (see the next section).

The one-line version to keep: complete asserts the pipeline ran and signed, incomplete_destruction asserts a named step failed and we signed that fact, aborted asserts the sequence never ran. None of the three is an independent forensic measurement of the host.

2. A real destruction can still leave a missing or unsigned record

The failure most people worry about is a record that falsely claims a destruction happened. In the sequenced chain path, that does not occur — a step failure is signed as incomplete_destruction naming the step, not as a false complete.

The failure that actually occurs is the opposite, and it is worse operationally: a destruction that genuinely happened, with no signed record of it. Two paths produce this, and both are open items we are naming rather than hiding.

  • Node eviction or server restart mid-run. A capsule's state lives in volatile memory only, so if the node it runs on is evicted or the server process restarts, that state dies with it — the data is genuinely gone. But the teardown pipeline never ran as a sequence, so no cryptographic chain can be computed. The recovery path emits a partial, unsigned object (its signing key version is none, its attestation is absent) rather than a signed AuditProof. After an eviction you may therefore hold no signed proof for that capsule, even though the data is destroyed.

  • The signing backend is unreachable when it is time to sign. By design, the volatile workspace is destroyed before the record is signed, so the data is already gone by the time signing is attempted. If the signing backend (a KMS in the production posture) cannot be reached, the capsule enters a state where the customer can retry signing within a bounded window. If that window elapses before signing succeeds, the capsule transitions to destroyed_no_proof and the AuditProof for that capsule is permanently lost. The destruction is real; the evidence is gone.

In both cases the data was destroyed and the missing artifact is the proof, not the destruction. If your operational requirement is that every destroyed capsule is accompanied by a signed record — "a case silently dropped is worse than no capsule" — treat these two paths as the places that requirement is not yet fully met, and design your own reconciliation (for example, alerting on destroyed_no_proof, and on capsules that leave no proof after a restart) accordingly.

3. The record attests events the runtime observed — not the content or the truth of the data

An AuditProof is a record of what the runtime observed and recorded during the capsule's life. It is not a statement about the content of your data, and it is not a statement that your data or your computation was correct.

  • It does not read your data. Nanorix does not scan or classify the content a capsule processes — that is an invariant of the trust model, not a missing feature. The record carries a hash of the command, declared metadata you set, and typed activity events; it does not carry the payload, the note text, or the chart content.
  • It does not judge correctness. A capsule that computed a wrong answer and then tore itself down cleanly produces a perfectly valid AuditProof. The record attests that the workspace existed, ran, and was destroyed — not that what ran inside it was right.
  • data_classification and jurisdiction are your declarations, recorded verbatim. Nanorix stores them and binds them into the signature; it never verifies or overrides them. Declare general while processing regulated data and the record will faithfully attest your declaration, not the reality.

This is expanded, from the attacker's side, under what an AuditProof does not establish in the threat model. The point restated here for scope: the record is evidence of events at a boundary, and the completeness and accuracy of the underlying activity is something an assessor still tests. A signature does not remove that work.

4. Runtime hardware attestation is not wired

The record has a runtime_attestation field, and it is null in every proof issued today. Nothing in the record binds the destruction chain to a measured boot, to kernel state, or to a hardware root of trust. The record does not prove which code ran on which attested machine — it proves that the holder of a specific key committed to a specific declared sequence at a specific time.

This is a deliberate deferral, not an oversight (the design is settled in ADR-045: hardware attestation is a sibling evidence attachment where the substrate supports it, never a required signer, so that the "any infrastructure" promise is preserved). But until it lands, do not read an AuditProof as a hardware-attested statement of what executed. If a hardware root of trust is part of your requirement, it is not something this record provides today.

5. Agent-activity provenance is not wired

For AI and agent workloads there is a natural temptation to read the record as a provenance log of what an agent did and why. It is not, in two specific ways.

  • The reasoning event is a boundary event, not model internals. The activity trail can carry a ReasoningStepCompleted event holding hashes of a prompt and a response. That is a runtime event emitted at an API boundary. It is not access to a model's chain of thought and is not evidence of what a model "actually reasoned." It records that a step occurred and binds the request and response bytes to a hash — nothing more.
  • The SDK's framework-provenance drain is not connected. The client SDKs include integrations that write agent-framework activity into a buffer, but nothing yet reads that buffer into the signed record end to end. Until that drain lands, do not cite the record as agent-framework provenance.

What the record does give agentic workloads is the property in the threat model's an agent editing its own history section: the activity trail is written by the runtime hosting the process, not by the process itself, so an agent cannot retroactively edit a transcript it never held. That is a real property. It is narrower than "a full provenance record of the agent's reasoning," and this page keeps the two apart.

6. What a verification verdict means — integrity under the embedded key versus anchoring to a named authority

A verifier reports the highest stage a record reaches, and there are two very different verdicts that can both look like a "valid" result. Reading them as the same thing is the most consequential mistake a relying party can make.

  • Integrity means: the signature verifies against the public key embedded in the record itself, and no signed byte has changed since it was signed. This shows the record is internally consistent and untampered. It does not show that the embedded key belongs to the authority the record names. A record can carry an attacker's key, be signed by that key, and verify at this level — because it is checking the record against a key the record supplied.
  • Anchoring (authenticity) means: the signing key is resolved against a separately published, separately signed trust-chain manifest that the reader obtains through a channel they trust, with the manifest's own identity fingerprint pinned out of band. This is what establishes that the key belonged to the authority it claims. It is a stronger verdict, and it is the one to require before relying on a record's origin.

For a record that names a Nanorix authority, the manifest is published (https://verify.nanorix.io/.well-known/trust-chain.json, with the identity fingerprint at /.well-known/identity.txt) and the anchored verdict is reachable offline. A bare verification with no manifest supplied reports integrity only, and the offline verifier prints the exact commands that reach the anchored verdict.

For a record that names a foreign or customer-controlled authority — a customer's own signing key, in the sovereignty posture where the customer signs and Nanorix holds nothing — two things are true today and both must be said. First, customer-signed records are not yet issued or end-to-end verifiable: the format reserves a customer-signature mode, but no proof is signed with a customer key and no verifier validates a dual-signed record. Treat customer signing as specified and unshipped, not available. Second, until a customer authority's key is anchored in a manifest the reader trusts, a verdict on a record naming that authority establishes only integrity under the embedded key — that the bytes are consistent and signed by whatever key the record carries — and does not establish that the key belonged to the named authority. The anchoring is an out-of-band step the reader performs; it is not implied by the record verifying against its own embedded key.

The stage-by-stage mechanics of this are laid out in the threat model's what the signature covers section. The scope point here: "the signature verified" is not "this key belonged to who it says." Ask which verdict you were handed.

7. The record covers one capsule's life — not copies of the same data elsewhere in your pipeline

An AuditProof is scoped to a single capsule: the environment that was declared, what ran inside it, what data moved in and out, and its destruction. It attests what happened during that one stage. It says nothing about the same data as it exists at other points in your pipeline.

If regulated data enters a de-identification stage as one copy among several that also live in an intake queue, a message bus, a data lake, a set of backups, and downstream stores, the capsule's record proves that the copy inside the capsule was worked and destroyed when the stage ended. It does not reach the other copies, and it makes no claim about them. A record that a stage's copy is gone is not a record that the data is gone everywhere.

This is why the "seal roughly the fraction of operations that carry most of the regulatory weight" framing describes a topology where the capsule is where the data lives and dies — not one where a capsule wraps a single stage sitting beside other resting places that persist by design. The honest claim for a multi-copy pipeline is the narrower one: a capsule proves what happened during the one stage where your rawest data is most concentrated, and proves that stage's copy was gone when the stage ended. The other copies are outside the record's scope, and closing them is your pipeline's job, not the record's.

8. Your retention duty is unchanged — destruction applies to the workspace and to what you did not take out

Destruction is scoped to the capsule's workspace, and it applies to the volatile state and to whatever you did not retrieve before the capsule ended. It is not a deletion of your outputs, and it does not touch, discharge, or interfere with any obligation you have to retain records.

While a capsule is alive, you retrieve its outputs through the output endpoints (GET /v1/capsules/:id/output). Whatever you take out is yours, held wherever you put it, and governed by your own retention rules. What destruction removes is the sealed workspace and any data still inside it at teardown — the raw copy the stage was working on, and anything you chose not to export. So the record attests that the workspace and its unretrieved contents were destroyed; it does not attest anything about the outputs you kept, and it does not shorten a retention schedule you are bound to. If your obligation is to keep certain records for years, that obligation is unaffected by the fact that the capsule that produced them was destroyed — you keep what you retrieved, under your own controls.

9. Whether the record itself is regulated data is undecided

One question a customer's counsel will ask is whether the AuditProof is itself subject to the same handling rules as the data it describes — because it can carry case identifiers you placed in its metadata, plaintext egress hostnames where a stage declared egress, and other fields that may be identifying in context. If it is treated as a record about regulated data, it may inherit that data's retention schedule, access controls, breach-notification exposure, and subject-rights obligations.

Nanorix has not decided this, and this page will not fake a decision your counsel would then hold us to. It is an open question, named rather than omitted. What is decidable in your favor today: the metadata in the record is customer-declared and never added to by Nanorix, so you can pseudonymize or hash a case identifier before it enters the record, or keep the mapping in your own index and leave it out entirely; and at a stage with no declared egress, the record carries no egress hostnames. The record's own lifecycle — how long it is kept, how it is destroyed, how subject-rights requests reach it — is likewise not yet specified. Both the classification decision and the lifecycle specification are owed in writing before they are relied on, and they are tracked as such.

Reporting a place where the record claims more than this page allows

The purpose of an open specification and an independent verifier is that you do not have to take any of the above on trust. If you find a Nanorix surface — this page, the product, the SDK, a verifier verdict — that claims more than the boundaries drawn here, that is a defect worth reporting, not a feature.

Report verification-breaking findings to [email protected]; machine-readable contact details are at https://nanorix.io/.well-known/security.txt. Findings in your own workload — code that writes regulated data somewhere the record cannot reach — are outside what Nanorix can remediate, but [email protected] can help you trace which capsule's activity trail recorded a given event.