Earned, never manufactured
An approval that can be manufactured is worth nothing, and it takes the real ones down with it. Part 3 of the Refusal Series: what may produce a yes, and what the escape hatch can and cannot do.
The erasure job for RET-204 finally exists. A build implements it, the build passed validation, and deploying it needs two signatures. It has one. The second signer is on leave, cutover is nine days out, and somebody senior asks the reasonable question. Can we force it through and regularize it after?
Every governance system meets this moment. What separates them is not whether an escape hatch exists. They all have one, because a system with no hatch gets abandoned the first time reality disagrees with it. What separates them is what the hatch can produce.
The hatch closes. It does not approve.
In Coherence, the forced path can end an approval request in exactly three states: rejected, withdrawn, or expired. It cannot end one as approved. Ask it to, and the platform refuses, and the refusal is typed the way part 2 described: an authority problem, reported as such.
The reasoning deserves to be spelled out. An approved verdict is a claim that specific people put their names behind a change. If an administrator can also produce that verdict, the verdict stops carrying the claim. Every real approval in the estate loses value the moment a fake one is possible. A reader can no longer tell which kind they are holding.
So the hatch has one job. It closes a request that will never be signed, under the closer's own name, so the request does not haunt the queue forever.
Who may not sign
The yes is earned, and earning is defined relationally. The person who asks for a change may not be among the people who approve it. The platform enforces that at every door the rule could leak through.
It starts before the request exists. When a request is opened, the requester is removed from its required-signer list, so a request that only self-approval could satisfy is never born. At signing, a requester's signature on their own request refuses. At evaluation, the check runs again from the other side. If a submitter's signature somehow appears in the signed set, the recommendation flips to rejected. That holds even when the arithmetic says quorum was met.
And at closing, the requester may not finalize their own request as approved, and may not ratify a verdict that went their way.
Above the collusion rules sits the arithmetic itself. Deployment takes two people. Where the estate demands it, a gate needs three distinct human identities, counted as people rather than as accumulated weight. A shortfall keeps the request open. It never converts to a rejection, because not-enough-signers is an unfinished state, and part 2 already made the case for naming states truthfully.
The machine's line
The signer rules govern people. One line governs the machine, and it is the hardest line in the platform.
Agents propose constantly here. They draft, classify, match, and recommend, and most of that work is good. But one verb is withheld from them at any severity: accepting a risk. To retain a risk is to decide the organization will live with it. That decision belongs to a person, always, because acceptance is the one act where the party bearing the consequence must be the party choosing it.
The guard is built for the paths nobody predicted. It does not keep a list of forbidden callers. A machine decision can arrive indirectly, through a chain of automated consequences that no list could anticipate. Instead it checks the principal itself, at the moment of the act. Detection is positive: the platform recognizes known machine identities. It never assumes an actor is human because a machine marker is absent.
A machine-triggered accept refuses cleanly, as a result rather than an error, and the risk stays open for a person.
A rule at the caller, a property at the writer
Where these guards live matters more than what they say.
Every operative fact in the platform has exactly one writer: one function through which that kind of fact enters the record. The guards sit inside those writers. They do not sit in the screens, the services, or the agent tools that call them.
The difference shows up over time. A rule enforced at the callers protects the callers somebody remembered. The deploy screen can refuse a forced approval today. Next quarter brings a new integration, or an agent tool, or a script written at midnight during a cutover. All of them reach the writer directly.
A guard at the writer is inherited by every caller, including the ones not yet written. A rule depends on being followed. A property does not.
The platform still keeps the outer layers, and refuses the same act at the route and again at the primitive. On a good day that redundancy is invisible. On a bad day it is the only layer left standing.
Nine days later
Back to the deadline. Nothing in the platform turns one signature into two.
The senior voice in the room has two honest moves. Wait for the second signer. Or close the request as withdrawn, under their own name, and let the cutover readiness gate report a control that is not yet covered. Both moves leave a record that matches reality. Part 2's readiness gate treats the second one exactly as it should, as an open question that blocks. The move the platform removes is the third one, the approval nobody gave.
The second signature arrives two days later, and it means what it says. The record beside it shows the week when a shortcut was wanted and was not available.
The override that stays visible
One more thing belongs in this part. Leaving it out would be the kind of omission this series argues against. A real override exists. A platform administrator holds genuine power over gates, and there are days that power is used.
The design point is what the override cannot do: it cannot wear the costume of an earned approval. The forced outcome would have silently faked a quorum. The override visibly does not. It is sealed, logged, and the overriding administrator is named on the proof itself. Power exists in the system and leaves fingerprints, and no reader will ever mistake it for consent that was never given.
Which raises the question part 4 answers. When someone does use that power, what does the record show afterward? The platform's answer is structural. The record holds met and overridden as different values of one field, so one can never be written over the other. Honesty, enforced not by policy but by the data model.
Part 4: Honesty you cannot misrepresent. What an override clears, what it cannot touch, and why the difference is a data type.
This site uses cookies
We use essential cookies for the site to function and analytics cookies (Google Analytics) to understand how you use it. Analytics cookies are only activated with your consent. We do not track you across other websites. Your data is stored in the EU and processed in accordance with GDPR. Read our Privacy Policy