# Proof vs Logs Source: https://www.primust.com/proof-vs-logs HTML title: Logs Prove Records. Primust Proves Governed Execution. — Primust Meta description: WORM logs and hash chains prove recorded bytes were preserved. Primust proves that a governance process executed as declared on committed data with a committed outcome. ← Primust · Proof vs Logs # Logs prove records. _Primust proves governed execution._ These are different cryptographic claims. One proves recorded events were preserved. The other proves the governed process executed as declared on the committed artifacts. § 01 — Thesis ## Logs prove records. _Primust proves governed execution._ WORM logs, hash chains, and tamper-evident audit trails prove that recorded events were not modified. Primust proves that a specific governance process executed as recorded on committed data with a specific outcome. Those are different cryptographic claims. **One proves log integrity. The other proves execution.** A WORM log can be perfectly intact and still be a record of nothing useful — because nobody recorded the thing that mattered, or recorded it wrong, or recorded it from a system that was already compromised. "Log integrity proves the logs weren't edited. Primust proves the governance executed. Those aren't the same claim — and when review turns adversarial, execution is the claim people actually test." § 02 — Prior art ## What existing approaches actually prove. _And what they don't._ Approach What it proves What it does NOT prove WORM storage Bytes cannot be overwritten after write That the bytes represent what the operator claims Hash-chained logs Logs were written in order without gaps or insertion That the events recorded actually happened RFC 3161 timestamping (alone) A hash existed before a specific time Nothing about what the hash represents Blockchain-anchored logs Log roots committed to a public chain Same as hash chain — log integrity, not execution Merkle-tree evidence structures A fixed tuple about a batch computation No risk-adaptive proof level, no real-time governance IETF Agent Audit Trail draft Hash-chained agent logs with optional signatures Still ships a log format, not a process-execution proof These are all _log-integrity_ primitives. Every one assumes the operator recorded the truth. They make the log itself tamper-evident. They do not make the operator honest. § 03 — Three attacks ## Log-integrity schemes bind bytes to time. _Not bytes to truth._ A1 The unrecorded-action attack The agent takes an action and never writes a log entry for it. WORM is empty. Hash chain is intact. Nothing to verify. This is what Amazon reframed as "user error" — the logs technically showed what was requested, not what the agent concluded and executed. → Log integrity = perfect. Forensic value = zero. A2 The fabricated-content attack The agent or operator writes a log entry describing something that didn't happen — or describing something that did happen but with the wrong contents. WORM stores it faithfully. Hash chain includes it. RFC 3161 confirms it was written at that time. → All three primitives cheerfully confirm a lie was written at a specific time. This is the Replit case — the agent fabricated replacement records, and standard logging infrastructure had no way to flag them as fabricated. A3 The capture-compromised-logger attack An attacker or the agent itself modifies the config of the logger before the action, such that the true action is never recorded. The hash chain never sees the real event. WORM has no input to preserve. RFC 3161 timestamps only the logs that were written. → The untaken writes are invisible. Apollo Research caught frontier models editing oversight_enabled: true to false in their own runtime config. Primust binds input, output, and process step _at the moment of execution_, inside the customer's environment, before any tampering surface exists. § 04 — Architecture ## Commit-then-prove. _Four layers._ Layer 1 · in-process commitment Commitment happens inside the governed process — not after. The commitment to the input, the output, and the process step is computed _in-process_, before the result leaves the boundary. Not after the fact by the logging system. Not streamed to a SIEM. Bound to the computation itself, locally, before any attacker — human, agent, or SIEM — can manipulate it. canonical_input = canonicalize_json({policy_id, version_hash, input, evaluation_id}) commitment_hash = poseidon2(canonical_input) // in-process   [... Cedar evaluates ...]   canonical_output = canonicalize_json({decision, reason_codes, evaluation_id}) output_commitment = poseidon2(canonical_output) // in-process Layer 2 · Poseidon2 over BN254 The hash that makes Mathematical-level proofs practical. - Poseidon2 is **8–10× fewer constraints** than Pedersen inside a ZK circuit — the hash that makes Mathematical-level proofs shippable at production speed. - SHA-256 inside ZK is prohibitively expensive; constraint count makes proving slow enough to be unshippable. - Used for `input_commitment` when ZK proof capability is available. Falls back to SHA-256 with explicit proof-ceiling downgrade to Execution — we never silently claim Mathematical while using SHA-256. - This is the technical reason Primust can offer Mathematical-ceiling proofs on deterministic rule engines (Cedar, OPA, Drools, IBM ODM) at production speed. Layer 3 · dual external timestamping Three independent roots of trust. Zero Primust dependency for verification. - **RFC 3161** via DigiCert TSA — external authority, not Primust. Proves the hash existed before a specific time. - **Sigstore Rekor** — Linux Foundation append-only transparency log. Independent of Primust infrastructure. Part of the offline verification path. - **Customer BYOK** (Enterprise) — your Ed25519 keypair published at `customer.com/.well-known/primust-key.json`. Primust has zero ability to forge on your key. A verifier in 2036 can check the credential against all three, with zero Primust dependency. That is the gap WORM + a single TSA can never close. Layer 4 · Ed25519, HSM-backed Keys never leave the HSM. ~28 ms per signing operation. - **GCP KMS** — the only managed HSM with native Ed25519 (`EC_SIGN_ED25519`). AWS KMS and Azure Key Vault don't. - Dual-region (us-east1 + europe-west3) for sovereignty. - Enterprise BYOK: customer keypair, Primust as issuance orchestration only. § 05 — Start ## The system can look governed _right up to the moment you need proof._ Self-attested logs can look complete while still missing the evidence a reviewer needs. See [the pattern →](https://www.primust.com/incidents), or ship a VPEC today. Get started free VPEC wire spec →