Effective Proof
When something goes wrong and someone asks a company to prove what happened and when, the honest default is: you have to take their word for it, because the evidence and the ability to quietly edit the evidence live in the same place. Tx-Rails changes that — every record gets a fingerprint, and that fingerprint gets stamped by a public network that nobody in the relationship owns, including us. From then on, nobody has to trust anyone’s paperwork. They can check it.
This document explains how, in plain terms, using a housing example throughout. The mechanism itself has nothing to do with housing specifically — the same chain works for a hospital’s equipment log, a factory’s safety inspection, a bank’s transaction record, or a supermarket’s cold-chain reading. Housing just makes a good, concrete story.
The everyday problem
A tenant complains that their smoke alarm hasn’t been checked in over a year. The landlord says: it was checked, right on schedule — here’s the maintenance log. The regulator’s real question was never “do you have a log.” Everyone has a log. The real question is: how do I know this log wasn’t touched after the complaint came in, to make the problem disappear?
Today, there usually isn’t a good answer. The log lives on the landlord’s own computer, kept by the landlord’s own staff, in a system the landlord controls completely. A regulator can ask to see it, but they’re still trusting the same party they’re supposed to be checking up on.
Think about the difference between a private diary and a postmarked letter. Both can say “written on the 3rd.” A diary page can be quietly torn out and rewritten with nobody the wiser — you’re the only one who ever had a copy. A postmarked letter is dated by somebody else entirely, who keeps their own independent record of it. Only the second one is actually proof, and the reason has nothing to do with paper or ink — it’s that checking it doesn’t require trusting the person who wrote it.
Every record inside tx-rails gets the postmark treatment.
How the postmark actually gets made
Four things happen, in order, and each one does a specific job:
| Step | What happens | In the housing example |
|---|---|---|
| 1. Record | Every action of consequence gets written down, structured, and tagged with who did it and when. | An engineer completes the annual smoke-alarm check and it’s logged against that dwelling. |
| 2. Fingerprint | Batches of these records get boiled down into a single number — a fingerprint that changes completely if even one character of one record in the batch is altered afterward. | That check, along with dozens of other maintenance events logged around the same time, becomes one fingerprint. |
| 3. Public stamp | That one fingerprint — not the underlying records, just the number — gets sent to a public network that no party in the relationship owns or controls, which timestamps it permanently. | The fingerprint covering that batch of maintenance events is now on the public record, dated, forever. |
| 4. Check | Anyone, at any later point, can redo the fingerprint from today’s copy of the records and compare it to what’s actually sitting on the public network. | A regulator investigating the complaint recomputes the fingerprint and checks it against the public stamp. |
If the two numbers match, nothing in that batch has changed since the day it was stamped. If they don’t match, something has — and there’s no plausible innocent explanation, because a fingerprint that changes completely from a single altered character doesn’t drift by accident.
The trap that looks like a fix but isn’t
Here’s the part that’s easy to get wrong, and worth being honest about, because it’s the difference between real proof and something that only sounds like proof.
Step 3 — the public stamp — is the whole point. But it only matters if step 4 actually reaches it. It’s tempting to build the public-stamping step, declare the job done, and then have the checking step compare against a local note-to-self about what was sent, rather than the public network itself. That quietly brings back the original problem: whoever can edit a record can also edit their own note about what they claim they stamped, and the check would come back clean either way.
We recently closed exactly this gap in tx-rails. The checking step now reaches all the way out to the public network’s own independent copy of events, not a local record of what we believe we sent it. That one distinction is the entire difference between “we promise this is tamper-evident” and “here is a contradiction anyone can find for themselves, without asking us anything, or trusting our software at all.”
That’s not a small technical footnote — it’s the sentence that makes “verifiable” actually true instead of just reassuring-sounding.
How deep the check actually goes
The “Check” step in the table above sounds simple, and it is — but the reason it’s trustworthy rather than just reassuring is specific, and worth spelling out. Proving that one record belongs to a stamped batch does not require anyone to hold, retrieve, or even see every other record that batch contains. It takes a short chain of intermediate fingerprints — roughly fifteen to twenty numbers, a few hundred bytes altogether — connecting that one record all the way up to the public stamp. Whoever holds the record and that short chain can redo the arithmetic themselves, by hand or with a short independent script, and compare the result to what’s actually sitting on the public network. Nobody needs ITOTCCA’s database, our software, or our cooperation to do this — that’s the actual mechanism behind “verifiable,” not a figure of speech.
We built the tool that issues this chain and tested it against a real validator producing real blocks, not only synthetic data: submitted a real transaction, generated a real proof connecting it all the way to a real public stamp, deliberately corrupted one intermediate value to confirm the check actually notices — it did, with a precise explanation of what disagreed with what — then reverted the corruption and confirmed the check passes again. We also tested what happens if the original machine holding that data is lost entirely: blocks are now archived independently as they’re produced, specifically so a hardware failure can’t quietly erase the ability to prove something that was never in dispute. We deliberately let a real node prune data it no longer needed, then confirmed the same check still reconstructs an identical proof from the independent archive alone.
What a regulator actually does with this
This does not mean a regulator gets to browse a company’s systems. It means the opposite: they only ever touch two things — a specific record they already have, and a public network anyone can already query. Nothing about this opens a new door into a company’s enterprise data.
- Start from the record already in hand — the maintenance event, the transaction, the reading — obtained the way regulators always obtain evidence: an inspection, a complaint response, a disclosure request. That part is unchanged.
- Identify which batch it was fingerprinted into, and recompute that batch’s fingerprint. This only needs the chain of already-hashed batch fingerprints leading up to it — not anyone else’s underlying records, and not a live connection into the company’s database.
- Look up what was actually stamped for that batch, directly on the public network — not through the company, not via anything the company hosts.
- Compare the two numbers.
A match means the record is exactly as it was when it was first logged. A mismatch is proof — not an accusation resting on the regulator’s judgement of the company’s character, but a contradiction anyone with the same two numbers could reproduce and confirm themselves.
What this proves, and what it doesn’t
| Claim | True? | Why |
|---|---|---|
| A specific record existed, unchanged, at a specific point in time. | Yes | That’s exactly what the fingerprint-and-stamp chain proves, independently of anyone’s say-so. |
| Nobody — including the company, including us — can quietly rewrite history after the fact. | Yes | Rewriting it would mean also rewriting the public network’s own independent, permanent record, which no single party controls. |
| Checking a record requires trusting ITOTCCA’s software, database, or cooperation. | No | Verification only needs the disputed record, a short chain of public fingerprints, and open, independently-implementable cryptography — not our systems, and not our word. |
| The underlying photo, certificate, or document is stored forever by this system. | No | The company still keeps and is responsible for the actual document, exactly as today. What’s permanent is the fingerprint that proves whether their copy still matches the original. |
| A company has to replace its existing software to get this. | No | Tx-rails sits underneath the systems already in use — that’s a separate story, covered in our integration-modes note. |
| A regulator gets broader access to a company’s systems or data than they’d otherwise have. | No | The regulator only ever sees a record they were already given through the normal process, plus a fingerprint check against a public network. This doesn’t open any new door into a company’s data — it verifies what comes through the existing one. |
We’d rather a regulator, an investor, or a customer catch us understating this than overstating it. The claim we’re making is narrow and specific — a fingerprint, publicly and permanently checkable — and it’s exactly that narrowness that makes it strong. It doesn’t ask anyone to take our word for anything.
Enough to hold up in court?
Cryptography alone doesn’t win a legal argument, and we don’t claim it does. A defence doesn’t need to disprove the mathematics — it just needs to raise doubt about some other link in the chain: a software bug, a procedural slip, a black box nobody outside the company can inspect. What actually closes that gap is making every one of those other links independently checkable too, not just the fingerprint itself.
Two things do most of that work. First, the check itself is reproducible by anyone, using nothing but public, open-source cryptography tools and the same short inclusion proof described above — not ITOTCCA’s software, database, or cooperation. Second, a mismatch is unusually strong evidence, not weak evidence: forging one would mean either breaking the underlying hash function or rewriting the public network’s own permanent history, neither of which is a live option for anyone. A verified match confirms integrity; a failed check is close to unimpeachable proof that something was altered after the fact.
Independent corroboration matters too. ChubbyChecker — our separately-built auditor layer, running on its own infrastructure — reaching the same conclusion as the primary system is the same kind of evidence as independent lab replication in scientific testimony: a much harder line to attack than one system’s word alone. And which public network actually carries the stamp is a real, deliberate choice, not an afterthought — it can be set per deployment, trading cost and speed against the size and scrutiny of the network doing the stamping, which is exactly the kind of tradeoff worth deciding openly rather than defaulting silently to whichever option is cheapest.
We’ve also written the procedural document a court-appointed expert would actually need — a fixed, numbered verification protocol using nothing but a disputed record, one proof file, and public tools, so it can be followed by an expert on either side of a dispute, independently of ITOTCCA’s cooperation. Read it here. One honest limit, stated plainly rather than left implicit: it’s a first edition — not yet used in an actual legal proceeding, and not yet reviewed by retained counsel for any specific jurisdiction’s evidentiary rules. The technical content behind it isn’t hypothetical — it’s been checked against a real chain, deliberately corrupted data, and a real pruned node, as described above — but “technically sound” and “courtroom-tested” are different claims, and today we’re only making the first one.
Proof of what, exactly? Tamper-evidence is not the same thing as honesty
Everything above answers one specific question well: was this record altered after the fact? That’s a real and important question, and the postmark answers it properly. But it is not the same question as was this record honest in the first place, and a serious system has to be equally clear-eyed about the difference — otherwise “tamper-evident” quietly gets mistaken for “corruption-proof,” which it isn’t, on its own.
A postmarked letter proves a letter wasn’t rewritten after it was sent. It says nothing about whether the person who wrote it was lying. Both matter. They need different mechanisms, and some kinds of lying can’t be caught by any mechanism at all — they need a human looking at the world, not a computer looking at a database.
So the honest next question isn’t “is tx-rails tamper-evident” — we’ve answered that above, and stand behind it. It’s: given that a record can no longer be quietly rewritten, what other forms could corruption still take, and which of those does the platform actually catch today? The rest of this document is our own answer to that, kept to the same standard as everything above: no claim beyond what’s actually built and checkable, and no pretending a gap is smaller than it is.
A working map of what “corruption” actually covers
Different kinds of dishonesty happen at different points and need different kinds of defence. The table below is our own working taxonomy — not a marketing list, a genuine engineering audit of where the platform stands today, one category at a time. We’ve grouped them by what’s actually true of each: solidly built and standing guard continuously, identified and buildable but not yet built, structurally hard because it needs infrastructure the platform doesn’t have yet, or — a category we think is important to name explicitly — simply not fixable by any internal check, ever, because the problem lives outside the data entirely.
| Type | What it looks like | In plain terms | Where it stands |
|---|---|---|---|
1. |
Quietly editing a record after the fact | The classic case this whole document is about — changing what a record says once it’s inconvenient. | Solved structurally — the postmark mechanism above, plus the fact that the platform’s own clock, not the person submitting the record, decides what “when this happened” means. No caller — including a legitimate one — can supply their own timestamp for a record that matters; the platform stamps it, the same way, every time, no matter who’s asking. |
2. |
The same party on both sides of a check meant to require two | Someone approving their own work, verifying their own remediation, or a company quietly transacting with itself under a different name. | Built and continuously running — the platform already rejects the most direct form of this at the point of the action itself (a person can’t mark their own remediation work as independently verified through the normal path). Two standing checks now also catch it after the fact: for housing remediation specifically, a bypass around that gate is reconciled against the tenant’s own independent confirmation (see the housing example below); more generally, a company quietly transacting with itself under a second, separately-registered identity is caught by comparing the platform’s own payment records against their own declared counterparty. Both are raised as leads for review, not proof — the same caveat as the structuring and cycle checks above. |
3. |
Forged identity or provenance | Claiming an asset, certificate, or submission is something — or from someone — it isn’t. | Built and continuously running — a standing check independently recomputes each item’s own identity fingerprint and flags any mismatch, fanning an alert out to every affected stakeholder the moment it fires, not just at audit time. |
4. |
A statutory deadline that quietly gets missed and nobody flags it | The clock was running and nobody was watching it, or nobody wanted to be. | Built and continuously running — see the housing example below. |
5. |
Breaking one large, reportable thing into many small, unreportable things | Structuring a series of transactions specifically to sit just under a threshold that would otherwise trigger scrutiny. | Built and continuously running — a standing check groups payments by counterparty and direction, and flags any cluster that’s individually under the reportable threshold but collectively crosses it within a short window. Treated as worth a second look rather than proof of anything — the same pattern shows up in entirely ordinary staged payments, rent, or subscriptions, so it’s surfaced for review rather than sanctioned automatically. |
6. |
Value moving in a hidden loop back to where it started | A chain of transactions that looks like independent parties dealing with each other, but is actually circular — dressed-up self-dealing at several removes instead of one. | Built and continuously running — a narrower version (one party transacting directly with itself) was already checked; a standing check now generalises it, tracing declared payment counterparties into a graph and flagging any loop that leads back to where it started, however many parties are involved. Raised as a lead for investigation, not proof — the counterparty links it traces aren’t independently verified identity, the same caveat as the structuring check above. |
7. |
Misrepresenting where a transaction actually happened | Claiming a transaction sits inside a jurisdiction with easier rules than the one it actually happened in. | Built and continuously running — the platform already checked a federation’s own claimed country against its registration; it now also cross-checks each transacting party’s own registered location — admin-set, not self-attested, so a party can’t simply declare whatever location suits it — against what a transfer claims, and rejects by default if the two don’t match or nothing is on file for that party. Deployed live tonight and confirmed firing on a real transaction; the specific match-succeeds path is covered by passing tests but not yet demonstrated against a live transaction, pending a separate, unrelated registry-node outage currently blocking new location registrations. |
8. |
Systematically over- or under-stating what something is worth | Valuation fraud — the number is wrong on purpose, not the record of who-did-what-when. | Partially built: Requires Internal &/or External Audit to Completely Prevent — the platform can verify identity and location against a registry it controls. It has no equivalent independent source of truth for value, and this isn’t a gap more of our code closes: for a unique, illiquid asset — a specific building, specific cladding panels, specific equipment — only an internal or external audit (an appraisal, an inspection, a forensic review of the actual physical thing) can ever say whether a declared value was accurate. The one partial exception is a liquid, publicly-traded asset with its own market price, where an external price feed can serve the same verifying role without a person — but that’s the same principle, not a workaround for it: checking a claim against a source of truth the platform doesn’t control. A standing check now catches this half — built, live, and running: it detects a value that changes suspiciously between re-attestations of the same asset and notifies every affected stakeholder the moment it fires, not just at audit time. But it deliberately doesn’t claim to be an audit. It answers “did this move in a way worth a second look,” not “was this ever true”; only an audit answers the second question. |
9. |
A real, valid login used in a way that doesn’t match who normally uses it | Not a forged identity — a genuine one, behaving suspiciously (unusual volume, unusual counterparties, unusual hours). | Partially built: Ready for external SIEM tooling — the platform now logs every call into its live services (who, what, when, how it went), live-verified end to end. That’s the raw material a behavioural baseline needs, but the baseline itself — deciding what “normal” looks like for a given party and flagging a departure from it — doesn’t exist yet, and is intentionally left to an external analysis layer (Elastic, or an equivalent AI-driven SIEM/log-analytics tool, is the obvious fit — the log is already structured for exactly that kind of pipeline) rather than reinvented here. See the note below the table. |
10. |
Someone quietly reading data they shouldn’t, as opposed to writing something false | Exfiltration and unauthorised access — a different kind of breach entirely from a falsified record. | Partially built: Ready for external SIEM tooling — every call into the platform’s live services, read or write, now produces a structured record of who made it, what it was, when, how long it took, and how it went — including calls rejected before they touched anything, which previously vanished without a trace. That’s a real audit trail where none existed before, but it’s a log, not a check: nothing yet flags a read as suspicious on its own — the same external analysis layer (Elastic, or an equivalent AI-driven SIEM/log-analytics tool) that would build a behavioural baseline for the row above is the natural place to add that, not something reinvented here. See the note below the table for what this does and doesn’t cover. |
11. |
A convincing lie told at the very first point of entry | The engineer never actually inspected the smoke alarm and wrote up a detailed, entirely fictional report — before anything reaches the platform at all. | Partially built: Close the loop, independently, via the Client (SMS/Mobile Phone) where possible — no internal consistency check can ever catch a lone, internally-coherent first attestation; that stays permanently true. But for housing-hazard records (as well as many other examples), the platform now lets the person a record is actually about — the tenant/client/patient/customer — confirm or dispute it under their own identity, distinct from whoever submitted the record, via a single-use link rather than requiring a platform login. A dispute is independently re-verified by the auditor layer across every replica and raised as its own standing finding, not left to a single replica’s own say-so that it notified anyone. That party will have a provable disinterest in falsely confirming something that didn’t happen: eg a tenant gains nothing and risks their own safety by signing off on a smoke-alarm check that never occurred, unlike a paid or appointed inspector, who can be negligent, captured, or complicit. This cuts one way more than the other, worth saying plainly — strong evidence, in this case, against a landlord and tenant colluding to fake a record together, weaker evidence against a tenant disputing a real one for reasons of their own. Generalising this beyond housing — an asset’s declared owner or condition confirmed by an interested third party — is a real extension, not yet built; most record types don’t yet have a workflow point where asking for this confirmation is catered for already, naturally. |
12. |
The people checking for corruption are themselves compromised | A finding gets quietly dismissed or overridden rather than corrected — the watchers, not the watched. | Not yet scoped — we haven’t yet confirmed whether a dismissal-or-override mechanism even exists amongst Regulation mechanisms, for something like this to happen through. That has to be answered before this can become a real, checkable item rather than a hypothetical one. If it is possible for a Regulator to unilaterally dismiss an issue, this would be a possible open door to corruption, relying on Trust in Regulation to satisfy corruption questions. |
13. |
Collusion among the very validators meant to keep each other honest | A set of “independent” parties checking each other’s work that turn out to be the same interest wearing different hats. | Out of scope, permanently — needs external screening of who actually controls each validating party (beneficial-ownership checks), not anything derivable from the data itself. |
14. |
Sanctioned or watchlisted parties operating under clean-looking records | Every record is internally honest and consistent — the party involved simply shouldn’t be allowed to transact at all. | Out of scope, permanently — needs an external screening feed the platform doesn’t hold and was never going to build; this is a compliance-integration question, not a data-integrity one. |
We built and live-tested the piece behind the two rows above this session: every call into the platform’s live services is now logged, including the ones that get rejected before they do anything — a gap we found and closed the same day, since a rejected call used to leave no trace at all. What we deliberately didn’t build is the layer on top that decides a given read or login pattern looks wrong; that’s intentionally left to an external, purpose-built analysis tool — Elastic is the natural fit, since this log is already structured JSON built for exactly that kind of pipeline — rather than reinvented inside tx-rails. Two caveats go with this, stated as plainly as everything else in this document. First: today this log only sees calls made through the platform’s own services — some auditor-side reads still go straight to the underlying database and never touch it, a real and named gap, not a hidden one. Second: unlike every other record in this document, this log was never going to get the cross-replica half of the postmark treatment — a read is observed by exactly the one replica that served it, so there’s no second replica’s version for it to agree or disagree with; forcing that agreement would mean routing every read through full consensus for an agreement that wouldn’t mean anything anyway. What it can get, and now does, is the other half: proof that a given replica’s own log hasn’t been quietly edited since it was written. Each replica periodically fingerprints its own unreviewed log entries and stamps that fingerprint externally, the identical mechanism used throughout this document, just anchored per-replica instead of cross-replica, since that’s the only kind of agreement this data was ever capable of needing. All three services that write this log now carry the identical pattern — built, unit-tested, and wired in — though only one of the three has been live-tested against a real running deployment so far; the other two are built and tested but not yet turned on in production. A third party — an auditor, an insurer, a regulator — building a review process on this data now has a real, buildable way to trust the log itself once every service is live-verified and switched on — closing the same gap every other record in this system had before its own postmark existed.
The three rows above are worth dwelling on, because they’re the ones a less careful version of this document would leave out — though not all for the same reason. The last two need external data feeds the platform was never going to hold itself, full stop: who’s really behind an “independent” validator, and whether a counterparty belongs on a sanctions list. No amount of internal engineering closes those. The honesty of whoever writes the very first record, just above them, is a related but different kind of limit: no internal check can verify it alone either, but unlike those two, the platform can build real infrastructure that makes an outside party’s own independent check possible and just as tamper-evident as everything else here — it just can’t perform that check itself, and most records still won’t have one unless someone requires it. Human judgement and real-world verification close all three gaps in the end, not a cleverer fingerprint; how far the platform’s own infrastructure can go toward supporting that judgement is the only thing that differs between them. Saying so plainly costs us nothing next to what it would cost to imply otherwise and be wrong.
Housing, in the same honest terms
Housing was our running example for the tamper-evidence mechanism above. It’s also where we’ve done the most concrete work applying the wider taxonomy — so it’s the fairest place to show what “built,” “identified gap,” and “open question” actually look like in a real system, rather than in the abstract.
| Scenario | Status | What actually happens |
|---|---|---|
| Backdating a safety check to hide that it was late | Structurally prevented | The date a hazard was reported, investigated, remediated, or verified is never something the person submitting the record gets to state — the platform’s own clock decides it, identically, no matter which of the network’s own independent validators computes it. There isn’t a field to backdate, and a claim that there was one wouldn’t survive the network’s own validators disagreeing with each other about it. |
| The same person marking their own remediation as independently verified | Caught, live-tested | The platform’s normal path already rejects this outright: verification has to come from someone other than whoever did the remediation work. We ran a real test this session simulating a bypass around that gate (a self-attested sign-off slipping through some other route), then reconciled the platform’s own anchored record against a fabricated, dishonest maintenance log claiming a prompt, same-day, self-handled response. The reconciliation correctly flagged all three problems: the investigation date didn’t match, the remediation date didn’t match, and the same party had signed off on their own work. |
| Forged safety certification on building materials | Caught, live-tested | A genuine, fire-rated component registered by its real manufacturer, then re-attested under an identical forged serial number by parties trying to substitute cheaper, non-compliant material — exactly the kind of substitution behind real building-safety failures. The platform’s identity-fingerprint check catches the mismatch and automatically notifies every affected party: the client, the responsible architect, and the regulator — not just whoever happens to audit the file later. |
| A statutory response deadline quietly slipping by | Built and continuously running | Every hazard report starts a real, server-computed compliance clock the moment it’s logged. A continuous check — not a periodic audit — fires the instant a fixed deadline is missed, the same underlying design as the deadline itself: nobody has to remember to go looking. |
| Tenancy, bond, and rent-charging integrity — false occupancy claims, bond or rent double-charging, a sign-off recorded by someone without authority to give one | Open question | These actions exist in the platform today, but we have not yet completed the same kind of dedicated fraud-vector review for them that hazard reporting and asset attestation have already had. We’re naming this here rather than leaving it unstated: it’s real, in-scope work we intend to do, not a gap we’re pretending isn’t there. |
Two of those four rows exist because we went and actually tried to break the system this session, on purpose, and wrote up exactly what happened rather than a description of what should happen. That’s the same standard the rest of this document holds itself to, and we think it’s the only way a claim like this stays credible over time.
The mechanism above doesn’t change by industry — only the kind of record being fingerprinted does. The same chain that proves a smoke-alarm check wasn’t quietly backdated proves a cold-chain temperature reading wasn’t edited after a food-safety incident, or that a financial reversal was logged when it actually happened, not when it became convenient to say it did. The same is true of the wider taxonomy above: the categories of corruption are the same whatever the industry, only the concrete story changes — housing gave us a real one to tell honestly, gaps included.
Tx-Rails — Built by IT/OT Chain & Cloud Australia (ITOTCCA). Sydney · London.