Part 5: The three-tier authority model

[#1]

---

The last article named four questions any skill file has to answer to actually be a role. The second of them — what is my authority? — is the one this article is about, because it turns out to be the hardest of the four to answer well, and the model that answers it is the single most reusable idea in this project's workflow.

Straw decisions, stick decisions, and brick decisions

An agent working a ticket hits a steady stream of small questions. Not big ones like "should we build this?" — the workflow already answered that. Small ones. The description says "sync users daily" but doesn't say what "daily" means: 00:00 UTC? Local midnight? Rolling 24 hours? Or: there's a param that could reasonably be optional or required and the item doesn't say which. Or: the acceptance criteria don't mention what happens on error — should I add "graceful degradation" as an implicit sixth criterion?

Each of those is a decision. Each has a defensible answer. And each sits, quietly, at a different level of permission: whether the agent may just answer it and move on, or has to record the answer as a decision, or has to stop and hand it back to a human.

For a human team the answer is usually "just decide it, and mention it in Slack if it matters". That works because the substrate is there to catch the ones that shouldn't have been silently decided. The social substrate: the Slack threads, the stand-ups, the ambient awareness. For an agentic team the substrate isn't there — that's the whole series. The default of "just decide it" becomes "silently commit an unrecorded answer to a question nobody knew was being asked", and half of them are wrong.

So the workflow needs a small, memorable, unambiguous framework that answers the authority question crisply for every small decision the agent will face. Not "use your judgement". Something concrete enough that the agent can apply it in the middle of a refinement pass without stalling out.

The framework in this project has three tiers. It's used most heavily by the requirements analyst — because refinement is the phase where these small questions come most concentrated — but it applies to every role in the workflow.

The three little tiers

Tier 1 — Derivable. A human reading the item, the linked issues, and the codebase could verify the answer without a judgement call. The information is there; the agent just has to find it.

Example: the description says "sync users daily" and the codebase already has three scheduled syncs, all running at 02:00 UTC. That's your derivable answer; "daily" is 02:00 UTC because that's what "daily" means in this codebase, verifiably. Write it into the item silently. Nobody needs to know you decided anything; you didn't. You found something.

Tier 2 — Determinable. The answer isn't stated anywhere, but a defensible answer follows from precedent. There's a codebase convention that resolves it, or a decision already recorded in CLAUDE.md or a design doc, or a shipped sibling item that answered the same question the same way. It's a decision, but the decision has an obvious right answer if you look at how the team has previously chosen. Decide it — and record the decision. Not because the answer is contentious, but because the decision is: a later reader has to be able to see that a choice was made, what informed it, and where.

Example: the item adds an action that deletes something. It doesn't say what guards that deletion needs. The project's own written conventions do: destructive actions require a completed dry run first, a typed confirmation, the admin role, and a feature flag that's off by default. Nobody would invent that four-part combination by accident, and nobody has to — it's already written down. So the analyst applies it and records the call: "Destructive-action guards per project conventions — dry-run-first, typed confirmation, admin role, feature flag off by default." The decision is made, but it's now attributable and reversible.

Tier 3 — Reserved. The question is a product-, priority-, scope-, cost-, or risk-shaped trade-off; a convention that would set precedent beyond this item; or a deviation from a locked stack decision (a framework, language, or infrastructure choice the team has already committed to and closed). The agent never decides. It escalates, and waits for a human. What that looks like depends on the role: the analyst posts a Refinement: NEEDS DECISION marker and fires Escalate for decision, which parks the item in Awaiting Decision; the readiness reviewer marks the question and stops short of a READY verdict. Either way the question is recorded as a question, and no agent answers it.

Example: the item asks for user data to be persisted to a new table. Nobody has decided whether that table is per-tenant or global. It could plausibly be either; the codebase has precedent for both. The choice would set a convention for every future feature that stores user data. The agent stops; the analyst posts the open question with both options and the implications; a human decides.

Three tiers — two for deciding, one for escalating. But the tiers only tell you how to handle a question once you’ve established it’s yours to answer. That prior question is what the next section is about.

Tier	Name	Agent action	Recording requirement	Example trigger
1	Derivable	Decide silently	None	Answer is in the codebase or linked sources
2	Determinable	Decide and record	Structured decision entry (answer + evidence + rejected reading)	Convention or precedent resolves it
3	Reserved	Escalate and wait	Open question recorded as a question	Scope, priority, cost, or risk trade-off

What the wolf was actually thinking

The tiers describe how decisions need to be handled. The wolf wants to blow houses down — plain and simple. But two things stand in the way of huff-and-puff victory. First, the wolf needs a clear way of knowing whether he's even allowed to blow a house down. When faced with a tempting house, he needs a test that determines his authority to act. The what/how test helps Brovo Wolf categorise the decision into Tier 3 (no blow — escalate) or Tier 1 or 2 (blow authorised, but follow process). Once he's cleared that hurdle, he must ensure his justification is solid (Tier 2). And if the decision is so routine it barely warrants a second thought — that's Tier 1: just huff-and-puff and move on. Ultimately, the wolf's dilemma is the same one any agent faces: is this decision mine to make? That call is what the tiers are really about — and the cleanest way to make it is the what/how test:

The what/how test

Use this as a gateway question: does answering this define the purpose, promise, priority, or boundary of the item — what it is — or only the implementation path for something already agreed?

• What → Tier 3. If the answer changes intent, scope, risk, cost, user promise, or another product-shaped trade-off, stop and escalate it as an open question.

• How → Tier 1 or 2. If the answer only chooses the way to build an already-set outcome, the agent may decide it. Use Tier 1 when the answer is directly derivable from sources; use Tier 2 when a convention or precedent resolves it and should be recorded.

That test cuts through most of the hard cases. Every developer instinct I have is to answer questions like "per-tenant or global table?" by picking the one that seems more elegant and getting on with the work. That instinct is what makes engineers productive — and it's exactly wrong here, because the choice sets the shape of the feature rather than its implementation. The item's purpose was "persist user data"; the choice makes it "persist user data per tenant" or "persist user data globally", and those aren't the same thing.

By contrast, "should this function be async or sync?" is a how. The item's purpose doesn't change either way. Decide it — probably at tier 2 if there's a codebase convention, tier 1 if the convention is loud enough that everyone else has already followed it. Write it, ship it, and don't lose sleep.

One rule of thumb worth memorising: when genuinely unsure, treat as tier 3. The cost of over-escalating is one human round trip. The cost of a wrongly-taken tier-3 decision is that it gets built — and now the item’s shape has been silently decided by an agent, in a codebase where the team’s next look at it is going to be the PR. That asymmetry means the default has to lean towards escalation.

An agent that escalates too much is annoying. An agent that decides too much is dangerous.

Show your stickwork

Tier 1 is silent. Tier 3 is a marked open question. Tier 2 — the tier where the agent does decide, but records the decision — is the interesting one, because "record it" sounds informal and it can't be.

The record has to be structured enough that a downstream reader (the readiness reviewer, the developer, the review agent, a human three weeks from now) can find it, see that it was made, see what informed it, and see where to argue with it if they disagree. In this project it lives in a ### Decisions section in the item's description — one numbered entry per call, each with three parts:

• The decision taken

• The evidence (a file path, a design-doc section, or a sibling issue key)

• The rejected reading, with why not

Example ### Decisions entry:
1. Destructive-action guards applied per CLAUDE.md.
   Evidence: CLAUDE.md §"Destructive actions", confirmed against three prior deletion features (PROJ-12, PROJ-34, PROJ-67).
   Rejected: Applying guards only to hard-delete (not soft-delete) — rejected because CLAUDE.md does not distinguish; applying selectively would set an undocumented precedent.

 

The same list is mirrored into the analyst's exit comment as Decisions taken, so a reader scanning the item's history sees the decisions without opening the description. Article 7, on documentation as contract, will go into the grammar of that record properly.

The rejected line is the part people may leave out, and it is the part doing the work. An entry that records only what was chosen tells a later reader that a decision happened. An entry that records what was rejected, and why, tells them whether it is worth reopening — and, crucially, lets them distinguish between "this was the only option" and "this was chosen over an alternative." That distinction is what makes the record genuinely useful rather than just a log.

The tier-2 record is not "the analyst's notes to itself". It is the artefact that makes the decision reversible. Without it, the tier-2 decision is functionally a silent tier-1 answer, and now the workflow has lost a class of information it can't get back.

With it, a reviewer looking at the item three phases later sees the whole shape of the choice: what was picked, what it rested on, and what was rejected. If that turns out to be the wrong call, there is a thread to pull. The skill file puts it more bluntly than I would: a tier-2 decision that is not recorded there is indistinguishable from an invented requirement.

The record turns a defensible-but-not-obvious decision into a defensible-and-visible one. Every tier-2 record you write is a place a future review agent can catch a mistake the current analyst couldn't see. That is exactly the shape the whole workflow is meant to have.

Different pigs, same wolf

The tiers were designed with refinement in mind, but they generalise further than the current skill files acknowledge.

The readiness reviewer is the role the model constrains hardest, and the second place it is written down. Its skill file states the bound directly: it works at tier 1 only — record what the sources already say, rule on whether the item is ready, and send anything that needs choosing rather than looking up back to the analyst. And definition-of-ready makes the mapping explicit — the calibration list of what a reviewer must not block on, re-read from the author's side, is exactly tiers 1 and 2. The reviewer's don't-block list and the analyst's must-answer list are the same list, read from opposite ends.

The developer faces a smaller stream of these questions, because most of the shape has already been chosen. They still arise: the implementation detail that's not in the acceptance criteria, the error case that isn't specified, the small library choice. Tier 1 questions get answered from the codebase and the acceptance criteria. Tier 2 questions get answered from convention, and get recorded (this time in the PR description or the completion comment) so the reviewer can see the choice was made. Tier 3 questions send the item back for refinement: if the developer discovers a scope-shaped question that the analyst missed, the answer is not to decide it in the PR, it's to fire the "the spec is wrong" transition.

The code reviewer — a different role from the readiness reviewer — uses the tiers as a diagnostic rather than as an authority of its own, and its skill file now says so directly: it audits at tier 1 only, the same constraint the readiness reviewer runs one phase earlier in the chain. Its job is to audit whether the developer's decisions are defensible against the acceptance criteria, and whether anything that got built bakes in a reserved, tier-3 call that somebody quietly made on the way past. If the reviewer catches itself starting to decide something the item didn't answer, rather than checking whether the developer was entitled to decide it — that is the tell that it has slipped from auditor to author, and the correct move is to send the item back rather than resolve it.

Writing this article exposed a gap. Fixable, as it turned out, not permanent.

The tiers were already written into the analyst's and readiness reviewer's skill files, and mapped in the readiness bar. But the developer's and code reviewer's files? No tier vocabulary at all. The logic was already there — don't build a guess, audit and never resolve — just never named as tiers.

Adding it in wasn't just a labelling exercise. It surfaced two real gaps: the developer had no way to record a judgement call made to fill a spec gap, and the reviewer had no named check for a reserved decision buried in a diff. Both are explicit now.

By this series' own standard, that's the better outcome. Not naming the gap — closing it.

Every role can use the same tiers. What changes is which tier the role's authority tops out at — and, for now, whether the role's file says so.

Trespassers will be escalated

The tier model applies to every role, but the two roles it applies to most sharply are the requirements analyst and the readiness reviewer — because they sit either side of the one line in the workflow that most needs guarding. From jira-refinement, the skill file itself, and arguably the cleanest single sentence in the project:

The readiness reviewer may only record what the sources already say. You may additionally choose among what the sources permit. Neither of you may invent what the sources don't cover.

Three authorities, one line. The readiness reviewer's is the smallest — audit what's already been said, and rule on it. The analyst's authority is larger — audit and choose, within the range of what precedent permits. And the thing neither of them may do is invent — because inventing is exactly what tier 3 covers, and tier 3 belongs to humans.

Read that sentence in the context of the tiers and the whole model condenses. The readiness reviewer works at tier 1 only — anything that requires choosing rather than recording gets sent back to the analyst. The analyst works at tiers 1 and 2 — anything derivable is silent, anything determinable-with-precedent is recorded. Tier 3 is the line neither crosses.

This is what article 6 will elaborate as the author-vs-auditor split. The tiers are the mechanism by which that split is enforceable. Without the tier model, "reviewer audits the analyst's work" is a stylistic aspiration. With it, it's a rule: the readiness reviewer's authority is bounded to tier 1, and the analyst's is bounded to tiers 1 and 2, and the audit is a check that no tier-3 questions were quietly answered at tier 2.

The pig who cried tier 3

The two failure modes are asymmetric, and that asymmetry is the whole point. 'Just use the tiers' only gets you so far if you can't recognise misapplication when you see it.

Under-escalation — deciding a tier-3 question as if it were tier 2. This is the dangerous one. The classic shape is the question felt small at the time: the agent saw a scope-shaped choice, saw a plausible answer, applied it, recorded it as a determinable decision, and moved on. The item shipped. Six months later someone notices the shape it's been building on all along was wrong. The tier-2 record makes the decision visible; the tier-2 tier makes it look legitimate. Both are misleading. The correct move was to stop.

The guard against it is the "would answering this differently change what the item is?" test, applied liberally. When unsure, treat as tier 3. The cost is a round trip; the alternative is a silently-shifted feature shape.

Over-escalation — treating a tier-1 answer as tier 2, or a tier-2 as tier 3. This is the annoying one, and it's easy to over-correct into if you take "when unsure, escalate" too literally. The agent asks the human every small question rather than looking it up. The refinement queue backs up with items marked NOT READY for reasons that were derivable from a five-minute skim of the codebase.

The guard here is tier 1's requirement that the answer be verifiable from the sources. If the answer really is in the code, or the linked issue, or the item's own text, escalating it is a failure to do the work. The tier is not "do I know it off the top of my head?" — the tier is "is it there for a diligent reader to find?" and, if so, "is what I'd write down really a choice, or just a lookup?"

The right cadence, in practice, is: most questions are tier 1 (found, not decided) — a well-written item and a well-maintained codebase should answer most questions derivably; if they don't, that's a signal the item isn't ready; a meaningful minority are tier 2 (decided, recorded); a small handful are tier 3 (escalated). If the balance is drifting the other way — most questions are being escalated, or most are being recorded as tier 2 — the model is being mis-applied. Usually in the escalation direction; occasionally in the tier-2 direction; the recovery is the same either way, which is to re-read the tests and re-sort the recent items.

	Under-escalation	Over-escalation
What it looks like	Tier-3 question answered as tier 2; decision recorded and looks legitimate	Tier-1 or tier-2 question escalated; human asked something derivable
Why it happens	Question felt small; plausible answer was available	"When unsure, escalate" taken too literally
The cost	Feature shape silently shifted; visible only after it's built	Refinement queue backs up; human round trips for answerable questions
The guard	Apply the what/how test liberally	Check: is the answer actually in the sources?
Danger level	⚠️ Dangerous	😤 Annoying

Before moving on, it's worth making the model concrete.

And they tiered happily ever after

Before the next article, open the last three items your team refined. For each one, find one open question the refinement agent (or the analyst, or you) resolved — a question the item posed and somebody answered.

Then ask, for each of them:

• Which tier was it?

• If tier 1: is the answer verifiable from a source the item points to, or only from someone's memory?

• If tier 2: is there a record of the decision — one that would tell a reviewer three phases later what was chosen and what informed it?

• If tier 3: was the question actually escalated, or was it silently answered at tier 2?

The interesting result of that exercise is not usually the tier-3 slip-ups (they do happen, just less often than you'd expect). It's the tier-1 questions that turned out to be tier 2 in disguise — decisions made from memory that nobody wrote down — and the tier-2 records that turned out to be tier-1 lookups, escalated by an agent that didn't quite trust its own sources.

Both are places the model is doing quiet work. The exercise is how you notice it.

---

Next: Don't mark your own homework. Why the author of a specification cannot also be its auditor, and how the tier model — plus a strict separation of roles — turns "readiness review" from a stylistic aspiration into a workflow guarantee.

---

A note on how this was made

Every idea in my writing comes from real work — built, broken, and figured out before a single word is written. The writing is documentation, not speculation. I start with voice dictation: a raw thought dump of ideas, objectives, and what I've actually been working on. From there, I collaborate with AI to shape that into something readable — structuring drafts and editing through a custom Rovo agent, configured with carefully curated instructions to review and refine work against my preferences, personality, and style. Artwork is a separate creative process — concepts originate from my own ideas and are brought to life using a combination of Google Gemini, ChatGPT, and Photoshop. The ideas, the experience, the creative direction — those are mine. AI is how I move fast and bring them to life.

Before anything is published, every claim and every idea goes through multiple review cycles to make sure it accurately reflects the thoughts and experience I originally set out to convey. If something reads well, that's the process working. If something doesn't, that's on me.