--- title: "Proof of Change" description: "Every change gets an actor, an authority, before and after state hashes, and a rollback id, committed to a hash chain administrators cannot silently edit." url: https://policycortex.com/proof/change sealed: 2026-08-31 amended: 2026-09-05 register: proof/change records: 5 digest: sha3:aa8f5808d30bc79f0fb96e80923fc035788c0b8204be9d1405f0de40e8e64d4d --- # The change happened at 02:14. The question is whether the record of it can still be edited at 09:00. Proof of Change PolicyCortex records who or what changed your cloud, under what authority it acted, and commits every record to a hash chain. An administrator can still change your estate. They can no longer silently change the record of it. **In one paragraph.** Proof of change records who or what altered the environment, under what authority, with before and after state hashes, the hashed delta, the policy gates that ruled, and a rollback identifier, committed to an append-only chain that administrators cannot edit without detection. Changes made around the gates surface at the next capture as drift with no authority attached. [Request Access](https://app.policycortex.com/auth?mode=request-access) ยท [How it runs in your tenant](https://policycortex.com/architecture) ## An agent changed something overnight. Produce the record. Q1. Who or what changed it? Q2. Under what authority? Q3. Can the record of the change be edited after the fact? At 02:14 UTC something modified an inbound rule on a production security group. By morning you owe your AO three answers, in order: who or what made the change, what authority permitted it, and whether the record you are about to hand over has been altered since it was written. Most organizations can answer the first from activity logs. Some can answer the second, if approvals live somewhere findable. Almost none can answer the third, and the reason is structural: in most architectures the audit trail is a table in a database, and anyone with administrator rights on that database can update a row, delete a row, or backdate a timestamp. Nothing downstream detects it. The integrity of the record rests on the good behavior of exactly the people the record exists to check. Proof of Change removes that dependence. Every change record is content hashed with SHA3-256 and committed to the record before it. The question stops being whether you trust your administrators and becomes whether the chain recomputes. What the estate looked like before anything touched it belongs to the previous layer, [Proof of State](https://policycortex.com/proof/state). This layer owns the transition: who moved it, on what authority, and whether the story can be rewritten. ## What we actually record One record per change, whether the actor was a person in the portal or an agent inside its envelope. The field names below are the real ones. Read the schema before you believe the paragraph. - **actor**: The identity that made the change: a human principal or a named agent identity with its own credentials. An agent is an actor in the record, not a service account borrowed for the night. - **authority**: The policy decision id and approval reference that permitted the change. In GATED mode that is the approving human. In AUTONOMOUS mode it is the envelope and the gate results that stood in for one. - **state.before**: SHA3-256 content hash of the state captured immediately before the change. The capture is the input to the rollback contract, not a description of it. - **state.after**: SHA3-256 content hash of the state after apply. The verify step recomputes it, and a mismatch triggers automatic rollback. - **delta.hash**: Hash of the computed difference between before and after, so the change itself is committed, not just its endpoints. - **rollback.id**: The identifier that reverses this exact change through a single API call. Every recorded change ships with its counterfactual: the state as if the change had not happened, executable on demand. - **gates**: Which policy gates evaluated before execution and how each resolved: blast radius bounded, state pinned, policy passed. 3/3 required to proceed. - **captured.at**: When the record was written. Every claim in the evidence base reads as of a timestamp, and the base regenerates to any historical one. - **chain.prev**: SHA3-256 digest of the previous record. This field is what makes the log append-only in effect rather than append-only by policy. ![The PolicyCortex readiness view: every control in one of five honest states, with failing controls the platform can fix automatically flagged per control](https://policycortex.com/images/pcx-readiness-five-state-1600.webp) Exhibit C-1. Every control in one of five states, and the changes the platform is permitted to make flagged per control. Illustrative demo data; the interface is real. ## How the record is verified The change log is append-only, hash-chained JSONL. Each record carries the SHA3-256 digest of the record before it, so every line commits to the entire history above it. Edit one record, anywhere, at any time, and every digest after it stops recomputing. Verification is mechanical: recompute the chain from the first record forward, and the run returns one of two answers, intact, or the sequence number of the first record that breaks. That answer is an attestation a second party can reproduce. An assessor does not have to trust our tooling or your administrators: the digests recompute from the records themselves. Retention is seven years, and the evidence base regenerates to any historical timestamp, so as of is a parameter you pass, not a caveat you add. Changes made around the system, in the portal, through a direct API call, from a pipeline that never met a gate, surface at the next state capture as drift records with no authority attached. A change with no authority is not a blind spot. It is a finding, and it is recorded as one. The same discipline applies when collection fails: if a collector is down or a scope is unobserved, the log contains a declared gap entry with the interval and the reason, never silently fewer rows. All of it runs inside your tenant. There is no telemetry pipeline to PolicyCortex servers and no egress of evidence, so the chain never depends on records that left your boundary. Where the log lives and how collectors reach it is covered in the [architecture](https://policycortex.com/architecture). ## What this layer does not do **Stated limit.** Proof of Change does not prevent change, and it does not see changes made outside connected scope in real time; those surface at the next capture as drift with no authority attached. What this layer holds is narrower and harder: every change it records is attributable to an actor and an authority, and the record itself cannot be edited without detection. Prevention, the question of what a machine is allowed to do before it acts, lives in the autonomy envelope: [Proof of Agency](https://policycortex.com/proof/agency). ## Where it maps Change evidence files under configuration management and protection of audit information. The mapping is deliberately quiet: the record is the product, and the rows below are where assessors expect to find it. SSP, POA&M, and SAR narratives generate from the same implementation record, exported as OSCAL 1.1.2. - **NIST 800-53**: CM-3 configuration change control, AU-9 protection of audit information, AU-10 non-repudiation of who did what. - **NIST 800-171**: 3.3 audit and accountability, 3.4 configuration management, within the same evidence base that covers all 110 requirements. - **CMMC Level 2**: Change and audit records handed to your assessor as generated evidence, not screenshots assembled the week before. - **MITRE ATT&CK**: Defense evasion: indicator removal and audit log tampering become detectable events, because the chain breaks exactly where the edit happened. Make a changed record reveal where trust broke. [Request Access](https://app.policycortex.com/auth?mode=request-access) ## Register colophon | Seq | Label | SHA3-256 | Prev | |---|---|---|---| | REC 0000 | THE QUESTION | 60d850c9f7c3 | 93409bd0a0b8 | | REC 0001 | WHAT WE RECORD | 45156354fe53 | 60d850c9f7c3 | | REC 0002 | VERIFICATION | 39e8137d7c79 | 45156354fe53 | | REC 0003 | STATED LIMIT | 8ebcf1dc320d | 39e8137d7c79 | | REC 0004 | FRAMEWORK MAP | aa8f5808d30b | 8ebcf1dc320d | Head sha3:aa8f5808d30bc79f0fb96e80923fc035788c0b8204be9d1405f0de40e8e64d4d. Each digest is SHA3-256 over the previous digest, the register key, the record label, and the record copy; a second party can recompute it from this document.