Every change, on the record.
A governed-change record is a tamper-evident account of every change in your workspace — who, what, and when. LiquidSilicon builds it on an append-only event stream: each change is a new event, never an overwrite, so any past state can be reconstructed. Over that stream it computes a SHA-256 hash-chain fingerprint that detects any later edit, insert, or truncation; a filterable audit ledger by entity, event type, actor, and time; a per-record timeline with field-level before-and-after diffs; and a JSON or CSV export carrying a manifest an auditor can re-verify later. It is tamper-evident, not tamper-proof, and its design is SOC2-aligned, not certified — we are precise about the difference.
Four capabilities over one append-only stream.
The governed-change record is not a separate logging system bolted onto the app. It is a set of read-only views over the same events table the platform is already built on — the append-only source of truth for every state change.
| Capability | What it does | In one phrase |
|---|---|---|
| Integrity fingerprintG-01 | A SHA-256 hash chain over the tenant’s events in canonical order. The head hash is the ledger fingerprint; recomputing it against a recorded manifest detects any edit, insert, or truncation. | Tamper-evident |
| Filterable audit ledgerG-02 | Every change as an entry — time, actor, event type, entity, and a one-line summary — filterable by entity type, entity, event type, derived actor, and time window. | Who / what / when |
| Per-record timelineG-03 | Expand any record for its full change history, oldest first, with a field-level before → after diff computed between each consecutive snapshot. Non-record events are interleaved in place. | Field-level diffs |
| Re-verifiable exportG-04 | Export the filtered ledger as JSON or CSV with a manifest — head hash, event count, bundle checksum, and a truncation flag — so the file can be re-verified against the live ledger later. | Auditor-keepable |
A hash chain that makes tampering show.
Recompute it anytime. If it moved, history moved.
Events are read in a stable canonical order and serialized deterministically — object keys sorted recursively, so key order never changes a hash. Each event is hashed together with the previous event’s hash using SHA-256, so the final head hash folds in every event before it.
That is what makes the record tamper-evident. An administrator records the head hash in an export manifest today; recomputing the chain later and comparing the head hash and event count reveals any edit, insertion, or truncation in between. The head cannot be forged to match without breaking SHA-256.
- Computed on read. No schema change; it applies to all history retroactively.
- Chained, not per-row. Each hash folds in the one before it.
- Detection, not prevention. It proves tampering; it does not stop a DB admin.
Every change, filterable to the one you need.
A ledger, not a log dump.
Each raw event becomes a normalized entry — the time, the actor, the event and entity types, and a best-effort one-line summary of what happened. You narrow it by event type, entity type, actor label, and a from/to window.
Attribution is deliberately honest. For an autonomous write the actor is the agent id; for anything else it is a derived label — user, import, webhook, sync, or system — inferred from the write path. Per-user identity is not captured for every action, so the ledger labels the source rather than implying an individual it cannot prove.
The ledger is admin-only. It holds every change in the workspace, so viewing and exporting it is restricted to workspace administrators.
Open one record and watch it change, field by field.
Every field that moved, and what it moved to.
Expand any ledger row for the full history of that one record, oldest first. Between each consecutive snapshot the record stored, LiquidSilicon computes a field-level diff — each changed field shown as from → to. Internal plumbing keys are ignored, so you see the record’s data, not its wiring.
Events that are not record edits — an autonomy decision, a permission denial — are interleaved in place on the same timeline, carrying their payload for context. The result is one honest sequence of how a record reached its current state.
Take the evidence with you — and re-verify it later.
Export the filtered ledger as JSON or CSV. Every export leads with a manifest — the small block of metadata that turns a data dump into evidence, because it records the ledger fingerprint the file was taken against.
- tenantId
- The workspace the record belongs to.
- generatedAt
- ISO timestamp the export was stamped — the runtime owns the clock.
- entryCount
- How many entries the file actually contains.
- totalMatching
- How many entries matched the filter. When it exceeds
entryCount, the export was capped. - truncated
truewhen the export hit its cap and did not include every matching entry.- filter
- The exact filter the export was taken under, recorded alongside the data.
- ledger.headHash
- The tenant ledger fingerprint at export time — the value you re-verify against.
- ledger.count
- The event count the head hash was computed over.
- bundleSha256
- SHA-256 of the exported entries payload — the checksum of the bytes below the manifest.
Why it matters: because the manifest carries the head hash and count, anyone holding the export can recompute the live ledger months later and prove whether a single event has changed. The truncation flag keeps a capped export from being mistaken for a complete one.
What the record is, and what it is not.
- Tamper-evident. It detects edits, inserts, and truncation against a recorded manifest.
- Append-only. Every change is a new event; any past state can be reconstructed.
- SOC2-aligned by design. Built around the audit-trail and change-management controls an examiner looks for.
- Honest about attribution. Agent id for agent writes; a derived source label otherwise.
- Re-verifiable off-platform. The export manifest lets an auditor check integrity later.
- Not tamper-proof. It does not stop a database administrator from altering a row — it makes the alteration detectable.
- Not a blockchain. No distributed ledger, no token, no consensus — a plain SHA-256 hash chain.
- Not SOC 2 certified. There is no auditor or attestation date, and we do not claim one.
- Not per-user identity for every action. Where the write path only knows a source, we label the source, not a person.
This mirrors, word for word in substance, the framing shown inside the product itself. We would rather state the boundary than imply a guarantee we have not built. When a formal attestation exists, this page will name it and its date — until then, SOC2-aligned means engineering intent and control coverage, not a certification.
Isolated at the database, not just the app.
The governed-change record reads one tenant’s events and no one else’s, and that boundary is enforced in PostgreSQL itself. The application runs under a non-superuser role with row-level security enabled and FORCED on 31 tenant-scoped tables, so tenant isolation is applied at runtime by the database — even a bug in application code cannot read across the tenant boundary, and the table owner is subject to the same policy.
Every governance endpoint is admin-only on top of that: a non-admin request is answered with a plain “admin only” state, not an empty table. The security brief covers the full model — approval gates, the Guardian scan, trust tiers, and BYOK key handling.
The governed-change record, answered.
What is a governed-change record?
It is a tamper-evident account of every change in your workspace — who, what, and when — built directly on an append-only event stream rather than a bolted-on log. Each change is a new event, never an overwrite, so any past state can be reconstructed. Over that stream, LiquidSilicon computes a SHA-256 hash-chain fingerprint, exposes a filterable audit ledger, reconstructs a per-record timeline with field-level diffs, and lets an administrator export the evidence with a manifest that can be re-verified later.
Is the record tamper-proof?
No — it is tamper-evident, which is a different and honest claim. The hash chain does not stop a database administrator from altering a row. What it does is make any alteration detectable: recomputing the chain and comparing its head hash and event count against a manifest recorded earlier proves whether history was edited, inserted into, or truncated. Detection after the fact, against a recorded fingerprint — not prevention.
How does the integrity fingerprint work?
Events are read in a stable canonical order (created-at ascending, then id). Each event is serialized deterministically — object keys sorted recursively so key order never changes the hash — and hashed together with the previous event’s hash using SHA-256. That chaining means the final "head" hash depends on every event before it, so the head cannot be forged to match a recorded value without breaking SHA-256. The chain is computed on read, so it applies retroactively to all existing history with no schema change.
How are actions attributed?
For an autonomous agent write, the actor is the agent’s id. For every other write, the actor is a derived label inferred from the write path — user, import, webhook, sync, or system. LiquidSilicon does not capture a per-user identity for every action, so it labels the source honestly rather than implying an individual it cannot prove.
What is in an export, and why does the manifest matter?
You can export the filtered ledger as JSON or CSV. Every export carries a manifest: the tenant id, a generated-at timestamp, the number of entries, the total matching the filter, a truncation flag (true when the export hit its cap and did not include every matching entry), the filter used, the ledger head hash and count, and a SHA-256 checksum of the exported bytes. Because the manifest records the head hash, an auditor who keeps the file can re-verify months later that history has not changed.
Is LiquidSilicon SOC 2 certified?
No. The governed-change record is designed to align with the kind of audit-trail and change-management controls SOC 2 examines, but the design being SOC2-aligned is not the same as holding a certification, and we do not claim one. There is no auditor or attestation date to cite. We will say so plainly here on the day that changes.
Put every change on the record.
The governed-change record is on from the first event — no setup, no separate logging pipeline. Start free, and export audit-ready evidence whenever you need it.