What a trust layer must do

When a category is young and the demand is real but the language is unsettled, every adjacent product repositions to claim it. This is not cynicism; it is how markets work. A logging tool, an observability platform, a workflow engine, a data catalog — each has a plausible story about why it is, actually, the decision-record layer you need, and each story is true enough to survive a first meeting. The buyer's problem is that these claims cannot be sorted by demeanor or by demo. They can only be sorted by requirements: a specification of what the thing must do, stated concretely enough that a claimant either meets it or does not. What follows is that specification. It has six requirements, and the important structural fact about them is that they are conjunctive — the record is only as strong as its weakest requirement, because an adversarial outsider will attack precisely the one you left out.

1. Completeness at the moment of decision

The record must capture what actually informed the decision, at the time the decision was made — not a reconstruction assembled afterward from whatever happened to survive. This is the requirement most systems fail first, and they fail it invisibly, because a record assembled after the fact looks complete until someone tests it against a decision whose relevant inputs have since changed or vanished. The account must include what evidence was consulted, which rules and thresholds were in force, and the state the system was in when it decided — captured at that instant, because that instant does not recur. A record that can only tell you what the system would decide now, rather than what it did decide then, is not a decision record. It is a demonstration, and a demonstration proves nothing about the case in dispute.

2. Faithful provenance of the inputs

It is not enough to record the inputs; the record must establish where they came from and that they are the inputs actually used. A consequential decision consumes data — about a person, a transaction, a context — and the defensibility of the decision depends on the defensibility of that data's origin. If the record shows the decision but not the lineage of what fed it, the challenge simply moves one step upstream: "how do we know these were the inputs, and that they were what you claim?" Provenance closes that step. Without it, the record answers "what did the system do with the inputs" while leaving open "were these the inputs at all," and the open question is the one the challenger will occupy.

3. Replayability

The record must preserve enough state that the decision can be run again and shown to hold — that given the same inputs and the same rules in force at the time, the same outcome follows. This is what converts a stored account into a defensible one. Anyone can store a claim that "the system decided X because of Y." Replayability lets a skeptical outsider verify that the stated reasons actually produce the stated outcome, rather than being a post-hoc rationalization attached to a decision that was really made some other way. It is the difference between a record that asserts a decision's logic and a record that can demonstrate it. A trust layer that cannot support replay is asking to be believed on its word — which is exactly the thing an outsider will not do.

A record you can only read is a story. A record you can re-run is evidence. The gap between the two is the entire value of the layer.

4. Tamper-evidence

The record must make unauthorized alteration detectable — not merely difficult, but evident. The point is not to make the record physically impossible to change, which is an unattainable and beside-the-point goal. The point is that any change leaves a mark, so that the record's integrity can be demonstrated to someone who assumes the institution had both the motive and the access to alter it in its own favor. This is what lets a record survive a hostile reading: not that it could not have been changed, but that if it had been, the change would show. Absent tamper-evidence, the record inherits the full discount of self-interest — an outsider must treat it as potentially edited, and a potentially edited record proves whatever its keeper wanted it to prove, which is to say nothing.

5. Independent custody

The record must be kept in a manner the institution being evaluated cannot silently control. This is the requirement that most sharply separates a trust layer from a log, because a log is by definition under the full control of the party that runs it. The credibility of a record is inversely proportional to the interest its keeper has in its contents; a record over which the evaluated party has unilateral, undetectable control carries no weight against that party, no matter how faithfully it was captured. Independence of custody does not require handing the record to a stranger. It requires an arrangement in which the institution cannot alter, delete, or suppress the record without that action itself being evident to the parties who rely on it. Custody, not capture, is where trust is won or lost.

6. Readability by an outsider

Finally, the record must be intelligible to the party who was not present and does not trust the system — the affected person, the auditor, the court. A record perfectly complete, provenanced, replayable, tamper-evident, and independently held is still worthless if only its authors can interpret it. The whole purpose of the record is to be examined by someone outside the institution, which means it must be structured so that an outsider can actually read it, follow it, and contest it. This requirement pushes toward standardization: a record that means the same thing across systems and institutions is one an outsider can learn to read once and rely on everywhere, and a bespoke internal format — however rigorous — fails the outsider precisely because it was built for insiders. The record must speak to its actual audience, and its actual audience does not work for you.

The test, and why the conjunction matters

These six are not a menu. They are a conjunction, and the discipline the buyer should impose is to treat any missing requirement as disqualifying rather than as a gap to be forgiven for a strong showing elsewhere. The reason is adversarial: when a decision is challenged, the challenger does not grade the record on average. They find the single weakest requirement and attack it, because one broken link is all it takes to break the chain. A record that is complete, provenanced, replayable, tamper-evident, and independently held, but not readable by an outsider, fails in front of the outsider it could not address. One that is everything but tamper-evident fails the moment its integrity is questioned. The strength of the whole is the strength of the weakest requirement, which is why a system that nails five and misses one is not five-sixths of a trust layer. It is a trust layer with a hole, and the hole is where every contest will go.

This gives the buyer a concrete test to run against any claimant, and it does not require evaluating the vendor's intentions or the elegance of the architecture. Take a real, consequential decision the system has made. Ask to reconstruct it end to end: show what informed it, where those inputs came from, that the stated reasons reproduce the outcome, that the record has not been altered, that the institution could not have silently altered it, and that a person outside the institution could read and challenge it. A genuine trust layer passes this on a real case, not a demo. Everything that cannot is doing something else — possibly something useful, but not this. The specification is not a wish list; it is the shape the record has to take to do the one job it exists for, which is to be believed by someone who has every reason not to.

— Dispatches · Summit Cognitive