Why keep a secret store's access rules as reviewed text applied by a job, rather than editing the live rules directly?

## What "declared as reviewed text" actually means A store's access rules are statements of the form *this identity, or this role, holds these rights over these names*. Declaring them means the authoritative copy of that set lives outside the store — in a file, under review — and reaches the store only by being applied by a job with an identity of its own. The store still enforces whatever is live inside it; the file enforces nothing at all. What changes is not enforcement but **how a rule gets to be live**, and that turns out to decide almost everything else about the estate. ## The four things a live edit cannot give you - **A proposal.** A live edit is already in force by the time anyone else hears about it. A declared change exists first as a diff with an author, a reason and an approver, and only then as a rule that allows or denies something. - **A reproducible set.** A store that is rebuilt, restored or stood up a second time needs its rules back. If they were typed in one at a time over two years, nobody can state the whole set except by reading the store and hoping the reader understood it. If they are declared, you apply the file. - **A baseline.** *Drift* has no meaning without a declaration. Once a declared set exists, a job can evaluate declared against live and report the difference, and a grant nobody declared finally has something to show up against. - **A place for the reason.** The store's own record answers *who called it and when* — that record is its own subject. The file is where *why this rule exists* lives, which is exactly what the next reviewer needs in order to decide whether it still should. ## What it does not buy This is where teams overclaim, and an interviewer is usually probing for it. | What people say it gives them | What is actually true | |---|---| | "The rules are reviewed" | The **text** was reviewed. Nobody computed the effect unless something produced a preview of it. | | "No rule changes without approval" | The applier changes rules by definition, and so does anyone who can write to the source it reads or alter the job itself. | | "The file is the rules" | Only while something applies it and nothing edits live. An unapplied file is a document, not a control. | | "We have least privilege" | Declaring a set narrows nothing. A wide rule written in a reviewed file is a wide rule. | ## The applier becomes an identity in your estate One automated identity now holds the right to change every rule. That is a real concentration of power, and it is usually still the better trade against a dozen humans each holding the same right: one identity reading one reviewed source is far cheaper to watch than twelve consoles. But the argument only holds **while the input genuinely is the only way in**. Whoever can write to that source, change which source the job reads, or edit the job definition has the applier's authority without ever appearing in a review. The controls on the source and on the job are therefore part of the access-rule system, not infrastructure housekeeping. ## Where this fails in practice 1. **The file is edited and never applied.** The declaration becomes aspirational; people read it and believe it. Nothing in the mechanism applies a file by itself. 2. **Two sources.** A second copy someone also applies, or a job that will accept input from more than one place, quietly removes the single review path that the whole design rests on. 3. **Nobody knows the schedule.** Whether the applier runs on every proposal, every few minutes, or only when someone remembers, changes how long an unreviewed state can survive — and how long a revert takes to land. 4. **The emergency edit.** Someone widens a rule by hand at 3am. Whether that edit vanishes later or lives forever depends on a property of the applier that most teams have never checked. 5. **Review by text alone.** A reviewer approves three lines and an identity gains rights over a whole branch of names, because nothing turned the text into a statement about who holds what. ## What good looks like - One protected source that only reviewed changes reach, and an applier that accepts input from nowhere else. - An effect preview attached to the proposal, so the approver is approving a change in access rather than a change in wording. - A drift report that compares declared against live on a schedule and tells a human, rather than silently converging. - The applier's own right to change rules kept outside what an applied set may alter. - A rehearsed way back in for the day an applied set locks the applier out.