Why not build it yourself? — Rubric Protocol

You can. You should understand exactly what it takes before you decide to, because most teams start down this road, get ninety percent of the way, and ship something that fails the one test it was built for.

Here is the road.

"We'll sign our logs."

Signing proves two things: the record has not changed since it was signed, and it came from your key. It proves nothing about when it was signed. You hold the key and you hold the clock. You can sign a fabricated record today and stamp it with last December's date, and the signature will verify perfectly. Against the party under review, signing moves nothing. The editor still controls the timeline.

"We'll hash-chain them. Append-only, like a blockchain."

Better. Now reordering and deletion are detectable within the chain. But you built the chain, you hold the chain, and nothing stops you from rebuilding it. Tonight, from scratch, with whatever history serves you, re-signing every link into a smooth continuous record. An append-only log you control is append-only until you decide otherwise. The tamper-evidence is real against outsiders and worthless against the operator, who is the exact party a reviewer is questioning.

"We'll use a WORM drive. Immutable cloud storage. Our SIEM's tamper protection."

Now you are trusting a vendor's claim that they made it immutable. That is genuinely better, because the vendor has less stake in your dispute than you do. But the auditor's question does not disappear, it just changes target. Can the vendor alter it? Can you and the vendor together? Can an administrator with root override the retention policy? The answers, respectively, are yes, yes, and usually yes. Vendor immutability is a policy, enforced by the vendor, revocable by the vendor. It is stronger testimony. It is not evidence, because evidence cannot rest on any party's continued good behavior.

What actually closes the gap

Every one of the steps above fails the same way: the record is anchored to something a party to the dispute controls. That is the whole flaw, and there is only one fix. The record's existence has to be fixed in time by a system that no party to the dispute can reach. This is the entire function of a notary, a public ledger, a trusted timestamp authority. They do not store your record. They witness that it existed, at a time, in a place you cannot alter after the fact.

The moment you require that property, you have three honest options.

Option One — Build it

Run the nodes. Manage the keys. Integrate a public ledger. Handle the signing, and if you want the records to outlive the current generation of cryptography, handle post-quantum signing. Then operate all of it, without failure, for the seven to ten years your retention obligation runs. This is months of specialized cryptographic engineering followed by a permanent operational burden, to build and run infrastructure that is not your product and never will be.

Option Two — Assemble it from parts

Public timestamp authorities exist. Open-source tools that anchor to a public chain exist. All legitimate. Now you own the integration between timestamping, signing, retention, and recovery. You own the key custody. And you own the question nobody scopes until it happens: what does recovery look like in year six, after the machine that held the keys is gone, when a regulator asks for a record you can no longer open?

Option Three — Use infrastructure built for exactly this

Use infrastructure whose only job is that the record convinces someone who trusts neither of you. Anchoring, key custody, long-horizon recovery, and independent verification, already built and operated. That is Rubric.

The honest bottom line

You can build tamper-evident logs in a week. Tamper-proof against yourself is a different thing, and it requires a clock you do not own. You can build that clock. What you cannot do is convince a regulator, a court, or an adversary's expert with a record you had the power to rewrite — and until you have solved anchoring, key custody, long-horizon recovery, and independent verification, an in-house build gives you exactly that record and no other.

That hard ninety percent is the part we have already built, operated, and proven in public. Not the signing, which is easy. The recovery seven years later. The destruction with a certificate at the end of the retention window. The verification by a hostile third party who has no account and no reason to trust us.

You are welcome to build it. Most teams who price the full thing decide they would rather point the engineering at their actual business, and let the clock be someone else's problem.

Why can't we just build this ourselves?

What actually closes the gap

The honest bottom line