Authority Is Derived, Never Listed

Somewhere in your company right now there is a spreadsheet that says who is allowed to approve things. A signing matrix, a delegation-of-authority policy, an access list, an approvals tab. It has a column for the person and a column for what they can wave through, and everyone treats it as the truth.

It is not the truth. It is a photograph of the truth, taken at some point in the past, by someone who has since changed jobs.

Open it and read carefully and you will find a name that left last quarter still holding sign-off on wire transfers. You will find a threshold that made sense before the reorg and makes no sense after it. You will find an approver for a region the company exited. The list is not malicious and nobody neglected it on purpose. It drifted, the way every hand-maintained list drifts, because it is a copy of a fact that lives somewhere else, and copies do not get the memo when the original changes.

This is why "access review" is a season. Entire departments exist to walk the list once or twice a year and ask, person by person, does this still match reality. That season exists because the list and reality are two different objects, and the gap between them is exactly where incidents live.

A hand-maintained authority list is a second copy of your org chart that nobody agreed to keep in sync, and it is wrong the moment you look away.

Now hand that list to a hundred agents moving at machine speed and ask it to decide, in real time, who is allowed to approve a merge. You do not have a governance problem anymore. You have a governance problem with a throughput multiplier bolted to it.

Two copies of one fact is one fact too many

The principle here is older than software. Wherever the same fact lives in two places, you do not have redundancy. You have two truths, and a countdown to the day they disagree.

The org chart is already code in a governed agent org (The Org Chart Is Code is the paper on why structure lives in a file the system reads on every task instead of on a slide nobody updates). It says who reports to whom, which role sees what, which stage of the pipeline each role owns. That file is the original. The authority list, the thing that says "these roles can block a merge, these can approve one," is the copy. And the copy is the problem, because the instant it exists it can disagree with the original, and nothing on earth guarantees anyone will notice when it does.

The fix is not a better process for keeping the copy current. There is no process disciplined enough to win that fight forever; the access-review season is the proof that the discipline always eventually loses. The fix is to delete the copy.

Authority should not be a list you maintain alongside the org. It should be a question you ask of the org, answered at the moment you need it, by reading the structure that already exists. The pipeline does not consult a roster of reviewers who are allowed to block a merge. It derives that set from the stage definitions that already say whose review gates what. There is one source of truth, and the authority answer is computed from it, live, every time. A computed answer cannot drift from the thing it is computed from. That is not a policy promising the copy will be kept fresh. It is the absence of a copy.

The bank teller who could suddenly say no

I can tell you the moment this stopped being theory for me, because it came with a genuine contradiction that had been sitting in our pipeline in the dark, waiting.

We were moving merge authority off an implicit convention, the kind of "everybody knows the reviewer signs off before it ships" arrangement that works right up until you ask it a precise question, and onto a derived rule read straight from the pipeline's stage definitions. Routine hardening. The sort of change that is supposed to be plumbing.

Deriving authority forced us to read a field we had never had to read precisely before, and the field contradicted itself. The documentation-review stage's configuration said, in its data, that the documentation reviewer's verdict could block a merge. The comment sitting on the very same line said the opposite: this is a task-not-done flag, not a merge-block. One line. Two answers. The data said this reviewer can halt finished work. The human-written comment right next to it said this reviewer absolutely cannot.

Under the old implicit regime, that contradiction was harmless, because nobody ever forced the question. The convention floated above the config and the config was never really consulted, so the two readings coexisted like a couple who have quietly disagreed about a thing for years by never once discussing it.

The moment authority became derived from that field, the contradiction grew teeth. Now the system was going to read that line and act on it, which meant one of two futures. In one, an incomplete-documentation verdict could hold finished, reviewed, correct code hostage because the docs were not perfect. In the other, a truly broken pipeline could sail through because the reviewer who should have been able to halt it had been quietly declawed. The field had to mean one thing, and until this moment it had been allowed to mean both.

Because derivation forced the question, the ambiguity went where ambiguity is supposed to go: to a human, as a decision (The Ratifier Role is the paper on the person whose job is to make exactly these calls). I ruled. Documentation review keeps the power to halt a truly broken pipeline, and loses any claim to block finished work over imperfect docs. Both halves of that ruling were then pinned by tests, so the decision could not quietly rot back into ambiguity the next time someone edited nearby.

A hand-maintained list would never have surfaced any of this. It would have encoded one of the two readings, silently, whichever one the person building the list happened to believe that afternoon, and nobody would have discovered which until the day it fired on the wrong change. Derivation did not just prevent the drift. It detected a latent contradiction that a list would have swallowed whole.

Derivation does not tolerate ambiguity, which is the feature

That is the part people miss about computing authority from structure. Everyone sees the obvious benefit, no drift, one source of truth. The deeper benefit is that derivation is intolerant in a way a list is generous.

A list will happily hold a contradiction forever. You can write two incompatible rows and the spreadsheet will not complain, because a list has no obligation to make sense, only to exist. Derived authority has an obligation to resolve. To compute an answer from the structure, every ambiguity in the structure has to collapse to a single value, which means the act of making authority computable drags every fuzzy, both-ways, everyone-knows-what-we-mean corner of your org into the light and demands it pick. Most of those corners have been fuzzy for years precisely because nobody was ever forced to choose. Derivation forces the choice, and routes it to a human when the choice is a judgment call rather than a lookup.

The corollary for review authority is clean. "Can this reviewer's verdict block this merge" is answered by reading the pipeline stages, not by consulting a separate permission table. And changing that answer means changing the structure, which is itself a governance-gated act (Gates Ship Dark is the paper on how a change to a control ships, and The Code the Build Won't Let You Touch is the paper on the frozen paths some of these definitions live behind). An authority change is not an edit to a spreadsheet that nobody reviews. It is a change to code, reviewed like code, recorded like everything else, leaving the same audit trail as any other consequential act (Logs Are Not Audit is the paper on why that trail is queryable and not just append-only exhaust).

"Derived authority is too rigid, sometimes you need an exception"

There is one real objection worth taking seriously here, so let me state it at full strength. Real organizations run on exceptions. The rule says one thing, but this once, for this deal, this Friday, this customer, you need to let something through that the rule would stop. A derived, computed, structural authority model sounds like it slams that door. Lists are flexible. Structure is rigid. Sometimes you need to bend.

The exception is the strongest argument for derivation, not against it, and here is why. Nobody is proposing you cannot make exceptions. The proposal is about where an exception has to be made. With a hand-maintained list, an exception is an edit to a document nobody watches: you add a row, you widen a threshold, you grant the one-time access that becomes permanent because nobody remembers to revoke it. The exception is invisible, unaccountable, and it never expires. With derived authority, an exception has to be made structurally, a change to the definition, gated and recorded, visible to the same review as anything else, with a name attached to the decision.

The system does not stop you from making exceptions. It stops you from making unaccountable ones. It converts "someone quietly widened access on a Friday" into "here is the change, here is who approved it, here is when." You keep every ounce of the flexibility. You lose only the ability to pretend the exception did not happen.

The same shape, one more time

The series keeps arriving at one shape, and this paper is the highest-stakes instance of it. A fact either lives in structure the system reads, or it lives in prose the system ignores. The wall is either architecture or a sign (The Wall Is Not a Sign). The org chart is either a file that runs or a slide that gets forgotten (The Org Chart Is Code). And authority is either derived from the structure on every use, or copied into a list that starts drifting the moment you save it.

The auditor cannot be the audited (No One Audits Themselves), and the approver cannot be a name in a spreadsheet that outlived the role it described. Delete the copy. Ask the org. The only authority list that is never wrong is the one that does not exist, because you compute the answer fresh every time from the only truth you actually keep.

References

1. SpeyAI, Rise of the Agent Org library. Companion papers: The Org Chart Is Code (structure in a file the system reads at runtime, the parent principle); The Ratifier Role (the human who resolves the judgment calls derivation surfaces); Gates Ship Dark (how a change to a control ships); The Code the Build Won't Let You Touch (frozen paths behind which authority definitions live); Logs Are Not Audit (the queryable record an authority change leaves); The Wall Is Not a Sign (architecture versus prose); No One Audits Themselves (separation of duties).

This paper is part of Rise of the Agent Org, a series by Ed Hoehn, SpeyAI. The full library is at speyai.com/record.