What Governance Was in Place at the Time?
Every organization can produce a policy document. Almost none can show which governance was actually in force when a specific thing was produced. That gap is where the risk lives.
Pick any output your organization produced six months ago. A report, a decision, a model response that fed a workflow. Now answer a simple question about it: what governance was in place at the time?
Not what the policy document said. What was actually in force, for that item, at that moment. Which model produced it. Whose authority stood behind the request. Which data it was allowed to rely on. Whether the conditions the policy assumed were true when it ran.
You can find the policy. You almost certainly cannot find the answer.
The distance between “we had a policy” and “this was produced under it” is not a documentation gap. It is the whole of the risk.
The old model was not careless. It was correctly designed for a world that ended
Added-on governance — the policy document, the control catalogue, the audit on a sample, the log reviewed after an incident — is not sloppy. A good control environment is genuinely rigorous, staffed by serious people, and it worked.
It worked because the work moved at human speed and a person signed each consequential step. The signature was the governance. The paper was the record. When something went wrong you could find the human who decided, and ask them.
Software takes the step now. It takes thousands of them in the time it takes to read this paragraph, using credentials that are entirely valid, and each one looks exactly like the one before it. There is no human at the moment of the act to ask afterwards, and the sample you audit is a rounding error against the population.
So the failure is not one of rigor. It is one of position. The control is in the wrong place, and no amount of care moves it closer to the moment that matters.
Added-on governance can tell you what happened. It cannot be present when it happens.
The tell is that everyone describes a log
Ask almost anyone what governance looks like in practice and they will describe a record: a log, an audit trail, a register. Something written down about the work and kept somewhere safe.
Look closely at what that is. A log is a statement about a message, stored apart from the message, in a system the operator controls, under credentials the operator issues. It is evidence for the operator, and only for the operator.
Meanwhile the data does not stay where it was made. It is forwarded to another department, cached by a model, quoted into a report, handed to an agent three systems away, incorporated into somebody else's output and passed on again. Every one of those recipients has to make a decision about it. None of them has an account on your logging system, and you cannot hand them the store.
A log file is governance that stays home. Your data does not.
Embedded governance: the frame is manufactured with the thing
The alternative is not more logging. It is moving the governance into the work, so that the record of what was permitted and what was measured is part of the output rather than a parallel account of it.
When that holds, the question at the top of this article becomes answerable. Not “we had a policy that covered this” but here is the governance frame this was produced under, attached to the thing itself, checkable by someone with no access to our systems and no reason to take our word for it.
That last clause is the entire test. Evidence a relying party cannot evaluate independently is not evidence. It is an assurance, which is a different and much weaker product.
| Added on | Embedded | |
|---|---|---|
| Where it lives | Beside the work, in a store you control | Inside the exchange, travelling with the data |
| When it is read | After the fact, if someone looks | Before the next action, every time |
| Coverage | A sample | Every exchange |
| Who can check it | You, and anyone you grant access | Anyone holding the data and a public key |
| Answers “what governed this?” | Only by inference from policy | Directly, for the specific item |
It starts with signing the prompt
None of this works from the middle. You can measure a process perfectly — model, hardware, conditions, the lot — and still not know whose work it was, because measurement describes the factory and says nothing about who placed the order.
Rootz has made this argument before, and the sentence still does the work:
“The prompt is the act. Everything downstream is process.”
So the governance frame has to begin where the act begins: the request is signed at the source. That signature establishes the origin of the request before any of the machinery runs. Everything the process then measures is bound to a known starting point rather than floating free.
Without it you have a beautifully instrumented factory producing goods with no purchase order. The provenance of the manufacturing is excellent. The provenance of the intent does not exist.
The signature is the foundation of ownership
This is the part most often mistaken for a security feature. Signing the prompt is not authentication. Authentication asks whether you may use the system. This asks something else entirely: who caused this to exist.
That is an ownership question, and its answer is what turns an output from an artifact the provider happens to hold into an asset with a determinate owner. The signature on the request is the root of the title chain. Everything downstream inherits from it.
Which means it also decides who benefits. An output whose origin traces to you is yours to license, to sell, to withhold, to build a record on. An output with no traceable origin belongs, in practice, to whoever stored it.
Anonymous is fine. Sovereign is not optional
A signature does not have to carry a legal name. It can be pseudonymous and still be entirely useful, because reputation accrues to the key. A key with ten thousand signed, verifiable, uncontested exchanges behind it is a known counterparty whether or not anyone knows who holds it. That is how a great deal of commerce already works.
What the signature must not be is a provider account.
If your identity is an account on someone else's platform, then the thing your reputation and your ownership rest on is a row in a database you do not control. It can be suspended, migrated, repriced, deprecated, or lost in an acquisition. Your accumulated history — the only part of this that cannot be copied — sits inside a system whose interests are not yours.
An identity you were issued is a permission. An identity you created is property.
Sovereign here means something specific and testable: the key is created and held by the owner, the signature verifies without reference to the issuer, and no provider can revoke the owner's ability to sign. Not federated. Not delegated. Not “portable, subject to terms.”
What actually changes
Governance stops being an assertion and becomes a property of the work.
The regulator's question changes from “do you have a policy” — which everyone answers yes to, truthfully, and which discriminates between nobody — to “show me the governance this specific thing was produced under.” The second question is answerable, and it is answerable by the recipient rather than by the producer's own assurances.
For the party relying on the data, the change is larger. They stop having to trust the sender and start being able to check the record. For an organization producing data, that is the difference between output someone has to take on faith and output that carries its own argument.
What this is not
Precision matters more than enthusiasm here, and the failure to be precise is what has made this field so easy to dismiss.
A signature establishes integrity — that these bytes are the bytes that were signed. It does not establish that the content is true. A measured process describes origin at a stated depth. It does not certify quality. An authority claim is asserted and independently checkable. It is not a guarantee that the assertion was correct.
These are three separate claims requiring three separate kinds of evidence, and collapsing them into one word is the most common error in this field. Rootz measures and signs. Whether to rely on the result remains the relying party's decision, made against evidence rather than against a vendor's word.
That division is deliberate, and it is the reason the model holds up. A system that told you what to believe would be asking for exactly the trust it claims to make unnecessary.
Embedded governance, in full →
Verify the primitive live — then break it →
A running implementation: signed output from a signed request →