How the trust ledger works.
A technical note on the tamper-evident record beneath every governed action — written for the engineers who will be asked to pressure-test it.
Every governed action in the Celbridge Trust Platform — a request routed, a policy activated, a document retrieved, a recommendation turned into a change — writes an audit record. The records for each client organization form a single, contiguous, cryptographically linked chain: each entry carries a hash computed over the organization, its position in the sequence, the previous entry's hash, and the canonical content of the record itself.
The linking hash is a keyed HMAC, and the key deliberately lives outside the database it protects. That separation matters: a hash chain computed with a key stored beside the data can be recomputed by anyone who can rewrite the data. Keeping the key out of the table means a would-be tamperer needs two independent compromises, not one.
The chain's head — its latest fingerprint — is periodically appended to an external, append-only anchor outside the application database. Verification then has two layers: internal consistency, where every entry's hash matches its recomputed value and chains to the previous event, and anchor consistency, where the current head is compared against the last anchored head. The result is reported plainly as consistent, rolled back, or rewritten. Even someone who could rewrite the database cannot hide the rewrite.
Even someone who could rewrite the database cannot hide the rewrite.
Around the ledger sit the properties a regulated review needs. Every AI request produces a full evidence trace — identity, policy decision, data retrieved, model route, response, cost — written atomically with the request, not reconstructed afterward. Retention policies and legal hold are first-class: a held record cannot be purged, scheduled retention always yields to a hold, and evidence packages can be generated and exported for counsel-directed or reviewer-directed examination.
Two design choices are worth stating because they are unusual. First, prompt and response content is masked in the audit view by default; revealing it requires explicit authorization, and the act of viewing is itself written to the chain — the auditors are audited. Second, the platform refuses to fabricate: a status without evidence renders as unavailable, a failed scoring call returns no score, and a verification that cannot run says so, rather than displaying a reassuring green check.
None of this is presented as a certification. It is an architecture — one your engineering and compliance teams are welcome to pressure-test in detail during a scoping conversation. The claims here describe deployed behavior, and where a capability is roadmap rather than shipped, we say so.