Building an AI evidence system versus buying one
Any competent team can hash decision records and chain them. The question is whether the result is evidence to anyone outside the organisation, and that part is not an engineering problem.
The internal build proposal usually looks reasonable. Hash each decision record. Chain the hashes. Sign the chain. Store it in write-once object storage with a retention lock. Estimated effort: a sprint, maybe two.
That system is genuinely useful. It is also, from an outsider's perspective, a set of records the organisation produced, signed with the organisation's key, stored under the organisation's retention policy.
What is easy to build
- Hashing and chaining records.
- Signing with a key from a cloud key management service.
- Write-once storage with object locks.
- An internal verification tool.
What is hard, and why
- External witnessing. Someone outside the organisation has to see the record's fingerprint at the time it was made. Internally, there is no such party. This is a structural gap, not a coding gap.
- Key custody with real separation. A key the application can use is a key the application's operators can use. Meaningful separation means a different trust boundary, procedures, and rotation practice.
- Independent verification. Verification that runs on your infrastructure proves your infrastructure agrees with you. A third party needs to run it without asking.
- Durability across the retention horizon. Ten-year records need algorithm choices made for ten-year exposure, plus operational continuity for the verification path.
- Standards conformance. If the output needs to interoperate with content provenance tooling, that is a certification process, not a library import.
The question that decides it
Ask who the evidence has to convince. For internal investigation and operational assurance, build. The self-produced nature of the records is not a problem when the audience is the producer.
For a regulator, a counterparty, an opposing party, or a court, the producer's independence is the entire question, and it cannot be built from inside the organisation being questioned.
Check it yourself
Every Rubric attestation resolves publicly, with no account and no API key, and every anchor resolves to a public ledger message you can read without our cooperation.
HCS topic 0.0.10416909 · ML-DSA-65 signatures
The hybrid most teams land on
Keep internal chaining for everything, because it is cheap and useful. Anchor externally only the records whose authenticity could be contested. Volume drops by orders of magnitude, and the records that matter gain a property the internal system cannot supply at any engineering budget.
Verifiable, not asserted
Rubric Protocol is a conformant C2PA Generator Product (Content Credentials 2.4, Assurance Level 1).
Record 01a002b7-3663-7b3b-a60e-db3b99ee2d94 · Echelon Intelligence Group LLC
Related: Why not build it yourself · Attestation vs SIEM logging · Independence