Platform · 5. Assurance and compliance

This chapter states what CueCrux can prove, what it cannot prove, and where the evidence has not been produced yet. It exists because the first question a security reviewer actually asks is never "what do you capture?"; it is "what can bypass capture?", and a documentation set that will not answer that question in writing is not worth reading. Everything below is dated 2026-07-27 and carries a source link or a status you can check.

This chapter is reference. It is written for the person who has to sign the form: risk lead, internal auditor, DPO, platform-security reviewer. If you are integrating rather than approving, start at Crux Engine or the daemon architecture chapter and come back here before you go to production.

Three notes on how to read it.

Nothing here is softened. Where a control is built and not enforced, it is listed as built, not enforced, in those words. Where a document does not exist, the row says it does not exist.
Every claim that names a file, flag or function links to the line in the public daemon repository. If a claim has no link, it is a statement about a document's existence and status, which you can hold us to directly.
The Crux Daemon is open source under the Apache License, Version 2.0. The hosted plane and the substrate engine are closed. For the closed systems this chapter publishes contracts and behaviour only, never mechanism. That boundary is deliberate and is itself disclosed in 1.21.

5.1 What a receipt proves, and what it does not

The positive claim, stated precisely. A CROWN receipt is a verifiable record of what was stored and retrieved. Given a receipt body, its signature envelope and a keyring containing the named key, verification establishes that these exact bytes were signed by the holder of that key and have not changed since. That is tamper-evidence. It is a real, useful, independently checkable property, and it is the whole of the guarantee.

The negative claim, stated just as plainly. A CROWN receipt is not an attestation that an agent behaved in a particular way. It does not prove the agent did what the record says it did, because every substantive field in the record is a self-report by the party being audited. The honest bar for attestation of conduct is mediated capture, a witness process on the traffic path holding its own key, and beyond that external attestation, a counter-signature by a party off the host. Mediated capture exists in an opt-in, same-host form with a stated limit (5.2). External attestation is not built.

We do not write "receipts prove what your agents did", and if you find that sentence on a CueCrux surface, it is a defect. Report it.

5.1.1 Two receipt families, and why they must never be collapsed

They carry different guarantees. Presenting them as one guarantee is the single easiest way to mislead an auditor, and it is a mistake earlier CueCrux copy made.

	Execution receipts	Retrieval receipts
What they record	An operation that executed, a model invocation, an approval decision, a stream that completed or aborted	A retrieval: what was searched, what ranked, what was selected
Integrity mechanism	Ed25519 signature over the stored body bytes	BLAKE3 content-address over canonical inputs
Signed?	Yes	No
Chained?	Yes, hosted receipts link by `parent_receipt_hash`; daemon-emitted records link per session by `seq` and `prev_hash`	No
How a third party checks it	Verify the signature against a published public key	Membership in the public benchmark receipts table
Verification response when unsigned	`valid: false`, `reason: "receipt_unsigned"`; it does not fudge	n/a

The hosted verification endpoint says this in its own response body, and the wording is worth quoting because it is already honest:

"Retrieval receipts are content-addressed via blake3(canonical inputs). They are not Ed25519-signed; verification is membership in the public benchmark receipts table."

POST /v1/receipts/verify is unauthenticated by design. Public signing keys are discoverable at GET /.well-known/crown-keys. Both are contracts; see 1. Crux Engine for the full field list.

5.1.2 What verification actually checks

On the daemon side, verify_receipt_v1 performs these checks in this order, and every failure returns a report rather than an exception, so you always get a machine-readable reason code:

BLAKE3 over the stored body bytes matches the recorded payload hash.
The body parses as CBOR (recorded, not fatal).
The signature envelope is present, decodes, and declares ed25519.
The envelope's receipt_id matches the receipt being verified.
signed_payload_hash is 32 bytes and equals the stored hash.
A keyring was supplied, indexes cleanly, and resolves key_id to a valid 32-byte Ed25519 point.
The 64-byte signature verifies under verify_strict (verify_v1.rs:536).

The verifier is bytes-first: it hashes and verifies the stored bytes exactly and never re-serialises them (lib.rs:11). That is the right design, a CBOR library upgrade can never silently invalidate historical receipts, and it has a consequence you should know: canonical is a producer convention here, not a property the verifier re-checks.

One vocabulary correction, because the term is misused in the wild: verify_strict is the ed25519-dalek API method. It rejects non-canonical signature scalars, small-order group elements and small-order public keys. It is not a Crux configuration toggle or a "strict mode" you can turn on. Any documentation describing it as a posture setting is wrong.

5.1.3 What a receipt does not establish

This is the definitive list. It is longer than the positive list, and that is the correct ratio.

#	It does not prove	Why
1	That the content is true	Every substantive field is asserted by the daemon or by a client the daemon trusts, never independently measured. `prompt_hash`, `output_hash`, `retrieval_set_hash` and `stable_hash` are strings the client supplies. `provider` and `model` are observational and default to the literal `"unknown"`.
2	That the model saw the cited memory	There is no signal from the model and no provider acknowledgement. The strongest honest statement is: a `context_injected` receipt proves the daemon committed, at the time, to a specific hash of a specific fact set for a specific session, and cannot later change that commitment without re-signing.
3	That the agent did anything at all	Hook and tailer lanes are self-reported telemetry. See the coverage matrix in 5.2.
4	Anything against an operator holding the signing key	The node key is a `0600` file readable by the daemon's UID. Chain validation checks internal consistency only; a fully recomputed chain passes. Tamper-evident, not tamper-proof.
5	That nothing was deleted	There is no signed chain tip, no length commitment and no enumeration of expected chains. Truncating a chain, or deleting a session's records entirely, is not detectable from the remaining records.
6	That the timestamp is real	`signed_at` is unauthenticated and unchecked; verification performs zero temporal validation. Nothing is TSA-stamped in the default configuration.
7	Third-party non-repudiation, for a single receipt	The keyring is an unsigned JSON file, and the daemon's own HTTP verification route builds a one-entry keyring from the node's own public key (receipts.rs:469). That route is asking the daemon "did you sign this?" and the daemon is answering with its own key. Use the offline path in 5.6 instead.
8	Anything about a handoff, to an outsider	Handoff packages are authenticated with a symmetric keyed BLAKE3 MAC, `blake3-mac-v1` (handoff.rs:23). Anyone holding the key can mint one. Do not present a handoff MAC as a signature.
9	That a key is still valid	The keyring has no revocation, no validity window and no key state, "intentionally not a full JWKS implementation yet" (keyring_v1.rs:25). Rotation is adding an entry; removing one retroactively invalidates every receipt it signed.
10	That content still exists	Verification hashes only the receipt body. A chain can be intact and fully verifying over a store from which every fact has been deleted.

Where the guarantee is genuinely stronger. Audit bundles are the strongest link in this subsystem: the manifest is domain-separated, key-canonical, and pins the verifying public key inside the signed manifest, so a bundle is verifiable offline with no network and no daemon, and there is an independent Python reimplementation run in CI against committed vectors. If you need one artefact to hand to an auditor, hand them an audit bundle, not a single receipt.

5.1.4 Erasure, and the thing that surprises people

Receipt bodies are immutable by construction, and they can hold identifiers. fact_ids, entity names, subject_ids, passport_ids and free-text reason fields cannot be edited without breaking the signature. If personal data lands in a receipt's reason or entity field, the receipt chain is precisely the thing that makes it un-erasable. Treat receipt-bound fields as a retention decision at design time, not an operational one afterwards.

Two related honesty points. memory_forget receipt bodies are returned to the caller and are not signed and not persisted, only the caller who received that response holds the pre-forget content hashes. And crypto-shredding is explicitly non-destructive in this build: "production CEK destruction is a separate human-gated operation" (crypto_shred_v1.rs:8). The destroy marker records intent. It does not delete a key.

5.2 What is outside the chain

This section is the coverage matrix from docs/assurance-coverage-matrix.md, which is the platform's declared authority on evidence claims: "Every claim on a public surface about 'evidence' must be consistent with this matrix. When in doubt, the matrix wins." It was written on 2026-07-15 and this is its first customer-facing publication.

5.2.1 Three assurance classes, not one

The word "evidence" is doing three different jobs across the industry. Here is the ladder we use, and where each rung is or is not built.

Class	What it is	Forgery resistance	Status here
1. Verifiable record	Hash-chained record signed by a key held by the same trust domain that produced the event	Tamper-evident after the fact; not resistant to a compromise of that same domain	Shipped. This is what the free daemon mints for memory and retrieval operations.
2. Mediated evidence	Record minted by a witness process on the traffic path, holding its own signing key in a separate process	Resistant to a different-user or remote attacker; not resistant to a same-OS-user compromise, because the witness key is a `0600` file under the invoking user's home	Opt-in, experimental. Local and cloud witness modes of `crux-llm-shim`. Bypass, unsetting the base-URL variable, remains detectable absence, not forgeable presence.
3. External attestation	Counter-signature or anchoring by a party off the host (hosted aggregation, transparency-log registration)	Resistant to a full host compromise	Not shipped in the free daemon. No Crux surface may imply it exists locally.

The global honesty note, unedited from the source matrix: everything above runs on the operator's host. An attacker with root on that host can read any local key. Local mediation raises the bar from "the agent can rewrite its own story" to "only a host-level compromise can"; it does not eliminate host-level trust. That residual is exactly what class 3 addresses, and class 3 is not built.

5.2.2 Coverage: what is captured, and what bypasses it

Event class	Captured by	On by default?	What bypasses capture
Memory writes: `store_fact`, `entity_upsert`, `memory_edit`/`forget`/`consolidate`	Daemon, passport-authenticated	Yes, always on	Bypassing the daemon entirely. Nothing is claimed about data that is not in Crux.
Retrieval: `query`, `query_facts`, `query_scan`/`expand`	Daemon	Yes, always on	Nothing. Reads inside Crux are always receipted.
Cloud model calls: Anthropic `/v1/messages`, OpenAI `/v1/chat/completions` and `/v1/responses`	Cloud witness mode of `crux-llm-shim`	No: opt-in, requires the witness flag and the client's base-URL variable pointed at a loopback listener	Unset the base-URL variable and calls stop appearing in the ledger, detectable absence. A same-UID compromise can read the witness key and the session token and forge.
Local model calls: Ollama, vLLM, llama.cpp	`crux-llm-shim` local mode	No, opt-in	Point the client at the model server directly instead of the shim.
Agent tool calls, file edits, shell	Hook snippet posting to the session observations route; signed trace nodes with before/after file hashes	Near-default once the hook is installed; trace nodes flag-gated	A compromised agent can suppress, reorder or fabricate hook events before they ever reach the daemon. The hooks run inside the agent's own harness.
Codex sessions	An opt-in script tailing rollout files	No	Editing or truncating the rollout files before they are tailed.
Handoffs: `create_handoff` / `accept_handoff`	Daemon	Yes	Key holders can mint MACs; third parties cannot verify without the key.
Coordination: work board, announces, leases	Daemon coordination plane	Yes (`CORECRUXD_COORD` defaults on, config.rs:1336)	Advisory by design, a session can simply not announce.
Hosted sync / multi-device	Hosted plane	No: paid, opt-in	Not syncing. Nothing is captured about local-only activity.

5.2.3 What each lane's record proves, and does not

Event class	The record proves	The record does not prove
Memory writes	Which authenticated passport stored or changed what, and when; full version and supersession lineage; erasure receipts on forget	That the stored content is true; that the acting passport was not a stolen credential
Retrieval	What was retrieved, under which token budget, by which passport, when, replayable	That the agent used the retrieved context in its output
Cloud model calls	A request with digest X went to provider Y at time T through the witness, and a response with digest Z came back, signed by this witness key	That the attributed session is a unique person or process; that the agent had no other channel; content semantics (digests only); that the host account was uncompromised
Agent tool calls, file edits, shell	That the daemon received and durably stored these self-reports at time T	What the agent actually did. This lane is telemetry, not evidence, and must never be marketed as proof of conduct.
Codex sessions	That the daemon received these observations at time T	What the Codex agent actually did, the same self-report limit
Handoffs	To key holders: the bundle was not altered in transit	Anything at all to an outside verifier
Coordination	What sessions declared, and when	What undeclared sessions did
Hosted sync	Server-side receipt of what was pushed and pulled	Anything about local-only activity

5.2.4 Where the boundary sits, in one sentence

Inside the chain: everything that goes through the daemon's own write and read paths, plus anything a witness process on the traffic path observes while it is enabled. Outside the chain: anything an agent does without telling the daemon, anything routed around an opt-in shim, and anything a party with host-level access chooses to rewrite. The observe-and-hook lane sits in a third place that deserves its own name; it is genuinely useful for timelines, debugging and cost attribution, and it is genuinely not evidence.

5.3 Enforcement status of the trust controls

A control that is built but not enforced is listed as built, not enforced. The distinction matters more than the feature list: a reviewer who reads "route authorization" and assumes a deny-by-default gate has been misled, even if every word on the feature page was individually true.

Control	Flag	Default	State
Route authorization middleware	`CORECRUXD_ROUTE_AUTH`	`shadow`	Built, not enforced. In `shadow` the contract is evaluated and a would-deny emits a `route_auth_shadow_mismatch` warning, then the request proceeds. Only the explicit value `enforce` blocks; `off`, an unknown value and an unset variable all resolve to `shadow` (route_auth.rs:17, :578).
Passport revocation	`CRUX_PASSPORT_REVOCATION`	on when unset	Enforced, narrowly, and fails open. The gate lives on the MCP dispatcher only; the HTTP surface has no equivalent check. Only an explicit `revoked_at` blocks, an unreadable passport record proceeds. Only the literal values `1` and `true` count as on: `yes`, `on` and `enabled` silently disable enforcement (dispatch.rs:116).
Punchcard leases	`CORECRUXD_PUNCHCARD`	`off`	Built, not enforced. Anything unrecognised, and an unset variable, resolves to `off` (agentgraph_kinds.rs:168). In `advisory` a conflicting lease is reported and still granted. In `enforce` the daemon refuses to grant a conflicting lease (HTTP 409); it never blocks a read or a write to the leased resource. The actual edit denial is performed by a client-side pre-tool hook, so a caller that does not run the hook is unaffected by any lease.
Coordination plane	`CORECRUXD_COORD`	on	Shipped and advisory by design. Overlap warnings are signals; nothing blocks.
Typed action traces	`CORECRUXD_FEATURE_TOOL_TRACES`	on (traces.rs:74)	Shipped, with a retention limit that disqualifies it as an audit log. A per-passport in-memory ring buffer, one-hour sliding window, 5,000-entry cap, evicted at read time. Set `=0` to opt out.
Human-in-the-loop gates	per surface	varies	Built per surface, not a platform-wide layer. Typed `approval_decision` receipts are minted where a gate fires, the work gate, which is armed per passport (work.rs:377), and the passport-mint approval surface, which is default off (mod.rs:230). The receipt's risk tier is currently a constant, not a computed classification (approval_receipts.rs:127). There is no global risk-tiered gate across the daemon; do not read "risk-tiered human-in-the-loop gates" as a shipped platform control.
Authentication mode	`CORECRUXD_AUTH_MODE`	none, required	Fail-closed at startup. The daemon refuses to boot if the variable is unset, and refuses separately on an unknown value, so a typo cannot degrade to dev scopes (main.rs:304). But the shipped example config sets `off`, which yields an unauthenticated daemon with scope checks bypassed, loopback-bound. That is a reasonable local default and an unreasonable production one. Set it deliberately.
Stream and model-invocation receipts	`CORECRUXD_STREAM_RECEIPTS`	off (config.rs:1345)	Built, not enabled. The main receipt classes do not fire until you turn them on.
Usage receipts	`CORECRUXD_FEATURE_USAGE_RECEIPTS`	off (config.rs:1346)	Built, not enabled.
External anchoring (transparency log, RFC 3161 timestamps)	`CORECRUXD_WITNESS_ENABLED`, `CORECRUXD_TSA_ENABLED`	off (config.rs:993)	Built, and unreachable in the community edition even when enabled, the only submission trigger requires a dataplane pool that this build hard-codes to absent (main.rs:565). A green witness preflight means "witnessing is off and that is fine", not "anchoring works". The offline verification machinery for externally supplied proofs is real and rigorous; submission is not.
Config audit	`CRUX_HOOK_CONFIG_AUDIT`	on; opt out with the literal string `off`	Warn-only, and fails open. Unaudited paths are surfaced as session context and never block. On any error, daemon down, no auth, network failure, the check returns "everything is fine". The `auditor` field is free text and is not bound to the calling passport.
Custody scorecard	`CRUX_CONTEXT_CUSTODY_AUDIT`	off (context_custody_audit.rs:37)	Built, not enabled: and it is a flag-state reporter, not an inspection. It reads four environment variables, one capability presence check, one boolean and a fact count. It opens no file, builds no export and verifies no receipt. Seven of its ten verdicts are constants, and its lock-in score is arithmetically always 1 (:252). Use it to confirm your runtime flag state. Do not use it, or cite it, as an audit.
C2PA output attestation	`CORECRUXD_FEATURE_C2PA_OUTPUT`	off	Built, not enabled, and the manifests are not validatable by third-party C2PA viewers without a published platform trust anchor. Verification is through our own tooling only.

Three things a reviewer should take from that table.

The daemon's default posture is observational. Route authorization observes, punchcards are off, the main receipt classes are off, anchoring is off. This is a deliberate choice, a security layer that blocks before it has been calibrated produces outages, not safety, but it means "the control exists" and "the control is protecting you" are two separate questions, and you must ask the second one against your own deployment.
Two flags fail open on a plausible typo. CRUX_PASSPORT_REVOCATION=yes silently disables revocation enforcement. CORECRUXD_PUNCHCARD=enforced (rather than enforce) silently disables leases entirely. Both should be asserted in your configuration management, not typed by hand.
Enforcement of leases is client-side. In the shipped default configuration nothing on the server prevents two sessions writing the same file. If your control narrative depends on lease enforcement, it depends on every client running the hook.

5.4 The compliance document set: status

CueCrux has been described internally as having nine compliance documents shipped. All nine exist, and a tenth, a Data Processing Agreement template, sits alongside them, so the table below has ten rows. None is currently published anywhere customer-facing, and "shipped" was the wrong word for most of them. Publishing that gap is a deliberate decision by the operator, taken in preference to leaving the earlier description standing.

Eight of the nine live in a private planning repository. The ninth, the assurance and coverage matrix, lives in the public daemon repository and is the exception in every respect.

Status vocabulary used below: DRAFT (substantive but unreviewed or stale) · STUB (a control table too short to serve as the artefact its title implies) · SCOPE ONLY, NO REPORT (a scope of work exists; the work product does not) · WRONG SYSTEM (the document's evidence pointers resolve to a different system than its title implies) · TEMPLATE v0.1 · CURRENT. None of them is SHIPPED.

Document	Words	Content date	Status	What would make it real
Assurance & Coverage Matrix	1,335	2026-07-15	CURRENT	Nothing: it is current, substantive and honest. It needed publishing, which is what 5.2 does.
SOC 2 Control Mapping	176	2026-06-13	STUB · WRONG SYSTEM	A SOC 2 Type II audit by a licensed firm. A 176-word, six-row control table is a useful internal artefact and is not an audit, a report, or evidence that one occurred.
EU AI Act Matrix	170	2026-03-01	STUB · WRONG SYSTEM	Re-scoping to the daemon, then completion against the Annex IV skeleton. See 5.5 for the dated position.
Auditor Guide	212	2026-03-01	STUB · WRONG SYSTEM	A rewrite against the daemon's actual trust chain, with the limits in 5.1.3 stated in it rather than around it.
Threat Model (compliance-corpus copy)	219	2026-03-09	STUB	Retirement. It is superseded in practice by the daemon repository's own threat model, which is 5.7× longer and newer. Two threat models of different lengths is worse than one.
DORA Matrix	228	2026-03-01	STUB · WRONG SYSTEM	Re-scoping to the daemon and refresh; it is five months stale.
DORA Drill Runbook	834	2026-03-08	DRAFT	Refresh and a rehearsed drill with a dated record of the outcome. The content is substantive; the date is not.
PenTest Scope	718	2026-06-11	SCOPE ONLY, NO REPORT	A commissioned penetration test. No penetration test report exists anywhere in the platform. A scope of work is a plan to obtain evidence, not evidence.
Air-Gap Deployment Runbook	504	2026-03-08	DRAFT	A correct title. The document is headed "Air-Gap Deployment Runbook, ReasonerCrux", a product name that appears nowhere else in the platform, and it is five months stale.
Data Processing Agreement	1,438	2026-06-12	TEMPLATE v0.1	Legal review and a versioned release. It is explicitly a v0.1 template, scoped to the managed daemon only.

5.4.1 The finding that matters most: four of them are about a different system

Four documents, the SOC 2 control mapping, the EU AI Act matrix, the Auditor Guide and the DORA matrix, document the hosted service's credit ledger, not the Crux Daemon. The "CRUX" in those filenames is the name of a double-entry credit-accounting subsystem, not the memory daemon.

Their evidence pointers resolve to credit-ledger code, transfer, escrow, budget and kill-switch logic. The Auditor Guide's "what each check proves" section lists zero-sum, transfer pairing and escrow resolution: ledger accounting invariants, not memory-daemon guarantees. The EU AI Act matrix maps "human oversight" to spend envelopes and "decision transparency" to receipts linking spend events to operation context.

This is the same class of error as a page that describes the wrong system, and here it is worse, because the reader is an auditor and the belief they would reasonably form is "the Crux Daemon has SOC 2 and EU AI Act control mappings." It does not. Those four documents remain useful artefacts about the ledger they actually describe. If any of them is published, the product scope must be the first line of the document. One further pointer in that set is now a dead end: it cites a repository that was archived on 2026-07-21.

5.4.2 Two documents that exist only in a superseded repository

The live compliance summary tells customers that the GDPR data-subject-access-request procedure and the customer offboarding runbook are "maintained in the private operations packet". That is technically true. The packet is a documentation repository that has been superseded by the current site and has not been archived, so it is still live and still writable and will drift. Both procedures exist; neither is published; the pointer to them is weaker than it reads.

5.4.3 What is missing outright

For completeness, because absence is the hardest thing to find by browsing:

No SOC 2 report and no SOC 2 audit. A control mapping is not an audit.
No penetration test report. A scope and a commissioning checklist exist.
No subprocessor list published anywhere.
No data-residency statement published anywhere.
A GDPR retention schedule exists at 191 words and is unpublished.
The incident-disclosure policy covers paid tenants only.

5.5 Regulatory posture, honestly dated

The EU AI Act matrices exist. The compliance SKU is a 2027 track. We do not claim EU AI Act compliance today, and you should not accept that claim from us or from anyone selling you an equivalent product in 2026.

What that means concretely:

Article 9, 10, 12, 13, 14, 15 and 50 mappings exist as internal drafts, alongside an Annex IV technical-documentation skeleton at v0.1. They are drafts. Two of them are scoped to the wrong system (5.4.1).
What is available now is operational and governance evidence: signed local records with a published limits statement, bi-temporal reconstruction of what was believed at a given date, contradiction reporting, supersession lineage, offline-verifiable audit bundles, and supply-chain assurance on the software itself.
The honest sequence is: operational evidence first, regulatory mapping second, third-party attestation third. We are solidly on the first, drafting the second and have not started the third.

The same dating discipline applies to DORA. A matrix and a drill runbook exist; both are five months old; the drill has not been rehearsed on a dated record. Treat "DORA-aligned" from us as a design intent with drafts behind it, not as a completed mapping.

5.6 What you can check yourself, without us

Every "we do not" above has a "you can check that" beside it. This section is the list, in descending order of how much it proves.

5.6.1 Verify an audit bundle offline, with an independent implementation

The strongest thing in the platform. tools/verify_audit_bundle_v1.py is a 463-line Python verifier that reimplements the domain tags and canonical-JSON rules rather than linking the Rust, so it is a genuine second implementation rather than a wrapper around ours. It depends only on the cryptography package.

python3 tools/verify_audit_bundle_v1.py <dir-or-bundle.tar.zst> [--json] [--rekor-pubkey <path>]

It checks the bundle format, the Ed25519 manifest signature against a public key pinned inside the signed manifest, and the digest of every member file. It runs in CI against four committed test vectors, each with an expected result. No network. No daemon. No CueCrux.

There is also a stateless HTTP route, POST /v1/audit/bundle/verify, for the same job. Note its contract: a failed verification is ok: false at HTTP 200; only a malformed or over-cap request is a 4xx.

5.6.2 Verify an observation chain offline

cargo run --example verify_observations -- --jsonl <session.jsonl> --pubkey-hex <64-hex>

Per line it strips the receipt, re-canonicalises, recomputes the BLAKE3 hash, compares, and verifies the Ed25519 signature; then it validates the whole file's seq and prev_hash chain. Its own documentation calls it "the cheapest possible offline auditor", which is the right level of claim. Read its scope carefully: it verifies the observation envelope, not the inner receipt bodies, and it is shipped as a repository example rather than a distributed binary.

5.6.3 Run the tamper test: and read what it proves

bash scripts/demo-receipt-tamper.sh

It seeds a throwaway store, verifies it, flips exactly one byte inside a receipt body frame, and re-verifies. The second run must fail. The script states its own limit at line 168: this proves the storage layer detects a byte flip. It does not exercise the receipt verifier. Receipt-level tamper detection is proven by unit tests in corecrux-receipts, which flip a body byte and assert BODY_HASH_MISMATCH, plus companions for bad signatures, off-curve keys, wrong signature lengths, property tests and a fuzz target. Both are worth running. Neither is the other.

5.6.4 Verify a hosted receipt without an account

POST /v1/receipts/verify is unauthenticated. Public signing keys are at GET /.well-known/crown-keys. An execution receipt returns its signature block and a chain walk with per-entry signature_verified. A retrieval receipt returns the honest statement quoted in 5.1.1. An unknown hash returns 404. You can check a receipt we gave you without telling us you are checking it.

5.6.5 Check your own daemon's flag state

context_custody_audit

Enable it with CRUX_CONTEXT_CUSTODY_AUDIT=1 and it reports the runtime state of the flags that matter for custody. Use it for what it is, a flag-state reporter that tells you whether revocation, receipt verification, routing and remote sync are configured on your daemon. Do not read its verdict strings as an assessment; 5.3 explains why. Pair it with check_config_audit, remembering that "audited" means only that a hash was previously posted by someone claiming to be an auditor.

5.6.6 Verify the software supply chain

Every tagged release ships with keyless Sigstore signatures, short-lived certificates bound to the release workflow identity and logged in the Rekor transparency log, so there is no long-lived signing key that can leak.

cosign verify-blob \
  --certificate corecruxd-linux-amd64.pem \
  --signature corecruxd-linux-amd64.sig \
  --certificate-identity "https://github.com/CueCrux/Crux/.github/workflows/release.yml@refs/tags/${TAG}" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  corecruxd-linux-amd64

Also shipped per release: a signed CycloneDX 1.6 SBOM per target, SLSA v1.0 provenance for the native-target binaries generated by the SLSA L3 builder, a signed SHA-256 manifest covering every file in the package, a cosign-signed install.sh, and a cosign-signed, SBOM-attested container image. Full recipes are in docs/verify-release.md. Two honest caveats stated there: the cross-compiled Linux targets are signed but are not yet SLSA subjects, and what you verify is "this exact artefact was built by this workflow at this tag", not that the source is free of defects.

5.6.7 Check the egress claim rather than believing it

The claim is that the daemon does not phone home. It is asserted in CI, not in a policy document: scripts/assert-no-phone-home.sh is run by the release workflow and fails the release on unexpected egress. Run it against the binary you downloaded:

bash scripts/assert-no-phone-home.sh /path/to/corecruxd

Two modes, and the difference matters to what you can conclude. In strace mode, preferred, and what CI uses, the daemon boots under network-syscall tracing in a clean non-git temporary directory, serves traffic, and the script fails if any non-loopback connect or send was attempted. In netns mode, the fallback when strace is unavailable, the daemon boots inside an unprivileged network namespace with only loopback and must still become fully ready and serve requests. Netns mode proves offline-first functionality; it cannot observe egress attempts, because they simply fail inside the namespace. Check which mode ran before quoting the result.

5.6.8 Read the source

The Crux Daemon is open source under the Apache License, Version 2.0. Every claim in 5.1 and 5.3 is a link to a line your reviewers can open. The trust core is not the part we hide, the closed systems are the hosted plane and the substrate engine, and what they promise is published as contracts in chapter 1 and chapter 2.

5.7 If you are compiling a vendor assessment

The short version, so you can fill the form without reading twice.

Question	Answer
Is there a SOC 2 report?	No. A 176-word internal control mapping exists, scoped to a different subsystem.
Is there a penetration test report?	No. A scope of work and a commissioning checklist exist.
Is there a DPA?	A v0.1 template, scoped to the managed daemon. Not legally reviewed.
Is there an EU AI Act mapping?	Drafts. The compliance SKU is a 2027 track. Do not accept a 2026 compliance claim.
Is there a threat model?	Yes: the daemon repository's own, at roughly 1,300 words. Ignore the 219-word compliance-corpus copy.
Are the records tamper-proof?	No: tamper-evident, against an adversary who does not hold the signing key. See 5.1.3.
Is anything anchored externally?	No, not in the community edition. The verification machinery for externally supplied proofs is real; submission is not.
Can we verify without you?	Yes, for audit bundles and observation chains, offline, with an independent implementation. See 5.6.
Is data sent to CueCrux?	No by default, and the claim is asserted in CI under `strace` rather than in a policy.
Can we self-host everything?	Yes. Local-first is structural. If CueCrux disappears, the daemon keeps working, and export is one command.

If a question here is not answered, or an answer here is contradicted by another CueCrux surface, treat this page as authoritative and tell us which surface is wrong.

Sources

Daemon behaviour, verified against the public repository:

Receipt verification and the bytes-first invariant, verify_v1.rs:536, lib.rs:11
Observation chain, observations.rs:243, :248, :1033
Self-attesting HTTP verification route, receipts.rs:469
Keyring limits, keyring_v1.rs:25
Handoff MAC, handoff.rs:23
Crypto-shred is non-destructive, crypto_shred_v1.rs:8
Route-auth shadow default, route_auth.rs:17, :578
Revocation enforcement, dispatch.rs:116
Punchcard default, agentgraph_kinds.rs:168
Coordination plane default, config.rs:1336
Trace ring default and retention, traces.rs:74
Approval gates, work.rs:377, mod.rs:230, approval_receipts.rs:127
Auth mode fail-closed startup, main.rs:304
Receipt-class defaults, config.rs:1345, :1346, :993
Anchoring unreachable in this build, main.rs:565
Custody scorecard flag and scoring, context_custody_audit.rs:37, :252
Tamper-test self-stated limit, demo-receipt-tamper.sh:168

Documents:

Assurance & Coverage Matrix, the declared authority for every evidence claim on a CueCrux surface
Verifying a Crux release
Receipt v1 specification and Audit Bundle v1
Threat model, note that its statement about the receipts keyring being the signing-key source is incorrect on both counts, and is being corrected
Security policy, how to report a vulnerability
Apache License, Version 2.0

Statements about unpublished documents in 5.4 are made from a 2026-07-27 inventory of the private compliance corpus. Word counts and content dates are from that inventory. If you are under an NDA with us and want to see any of them in their current state, ask, the answer is yes, with the status label attached.