Authority Cascade

[joshua-temple]

The Proposal

Decisions follow a fixed precedence: Org > Client > Team > Role > Individual. Each layer sets defaults; any layer above it overrides. Personal preference applies only where nothing above has spoken.

The cascade resolves conflicts; it does not generate rules. A layer with no opinion on something delegates it downward by default, so most day-to-day choices still land with the team or the individual.

Why This Matters

• Solved problems stay solved. Once a layer settles a question, layers below stop re-litigating it, and debate energy goes to genuinely open questions.
• Onboarding becomes reading, not archaeology. A new person (or agent) learns the rules by walking the cascade top-down instead of absorbing tribal knowledge.
• Staffing gets flexible. When conventions live at a layer instead of in someone's head, anyone can rotate onto any engagement and know exactly which rules apply.
• Agents get cheaper and more consistent. Each layer's rules are written once and inherited, so agents load the applicable stack instead of rediscovering context every session.

The Layers

• Organization: standards that apply to every engagement, no exceptions (e.g., security baseline, review discipline).
• Client: engagement-specific requirements that override org defaults (their stack, their compliance regime, their conventions).
• Team: conventions this team adopts within org and client constraints (branch strategy, ceremony cadence).
• Role: expectations attached to a function (architect, engineer, reviewer), regardless of who fills it.
• Individual: everything left unspecified above (editor, local tooling, personal workflow).

Open Questions

1. Ownership registry. Where does each rule record which layer owns it: one manifest per repo, front-matter on each standards doc, or a central index? Without a machine-readable answer, agents cannot load the cascade automatically.
2. Conflict escalation. When a client requirement contradicts an org standard (e.g., the client mandates a tool the org prohibits), who decides (engagement lead, org standard owner, or a named tiebreaker), and within what timeframe?
3. Altitude test. What check keeps rules at the right layer? Proposed litmus: an org standard must hold for every engagement or it moves down; a team convention that individuals routinely override gets deleted or promoted. Who runs that audit, and how often?
4. Change process. How does a rule move between layers, and what notice do affected teams get when a layer above them changes?

[joshua-temple]

Accepted. Documented in #13.