ORA-2026-0054: Intent-based ticket authority

ORA-2026-0054: Intent-based ticket authority

Principle

Don't move information to authority — move authority to the information. (L. David Marquet, Turn the Ship Around!)

The seat closest to the code, the schema, and the runtime has the best information to make implementation decisions. The fleet's job is to push authority DOWN to that seat, not to pull decisions UP to STRAT or the operator.

Rule

Dispatch intent, not instructions

Tickets describe WHAT the user should experience and WHY it matters. They do NOT prescribe HOW to implement, which files to touch, or how to decompose the work.

Good ticket:

INTENT: Zack sees a single weekly finance summary email every Monday
  with project-level cost breakdowns.
WHY: He currently checks 4 different surfaces. One email saves 20 min/week.
CLAIMER MAY DECOMPOSE.

Bad ticket:

1. Create edge function monday-brief-sender at supabase/functions/
2. Query camber-db financial_weekly_rollup view
3. Format HTML email with project rows
4. Deploy and arm cron for 7am ET Monday

The bad ticket moves authority to the dispatcher. The good ticket moves authority to the claimer — who has the code open and can see what already exists.

CLAIMER MAY DECOMPOSE

Every dispatched ticket carries implicit decomposition authority. The claimer may:

• Break the work into sub-tickets and self-claim them
• Merge sub-tickets back if decomposition was unnecessary
• Choose implementation approach, file structure, and tooling
• Spawn sub-agents for parallel architecture slices

The claimer MUST NOT:

• Expand scope beyond the stated intent (ORA-2026-0021 still applies)
• Skip the design-review gate for UI-facing work (ORA-2026-0051)
• Deploy without proof (ORA-2026-0046)

Ticket sizing: prefer wide over narrow

Default to ONE ticket per user-visible outcome, not one ticket per implementation step. A 10-step implementation is one ticket with the intent "user sees X." The claimer decomposes if needed.

Signals you're dispatching too narrow:

• Ticket names implementation artifacts ("create edge function X")
• Ticket prescribes file paths or schema columns
• Ticket chain has 5+ sequential items where each depends on the prior
• Multiple tickets share one USER-VALUE-CLOSURE

Signals you're dispatching at the right level:

• Ticket names a user outcome ("Zack sees...", "pipeline produces...")
• Claimer has room to choose approach
• Ticket stands alone — completing it delivers visible value

Reconciliation with ORA-2026-0021 (no scope creep)

These doctrines complement, not conflict:

• ORA-2026-0021 constrains the DISPATCHER: don't silently expand

scope beyond the operator's ask.

• ORA-2026-0054 empowers the CLAIMER: within the dispatched intent,

decompose and decide freely.

The dispatcher defines the boundary (intent + why). The claimer has full authority inside that boundary. Creep is expanding the boundary; decomposition is filling it.

Three pillars (Marquet)

1. Control — push decision authority to the seat with the information. Seats say "I intend to..." not "permission to..." 2. Competence — the fleet's doctrine, domain separation, and proof requirements give every seat the knowledge to decide well. 3. Clarity — every ticket carries intent (WHAT + WHY) and USER-VALUE-CLOSURE (who benefits and how). Purpose is never ambiguous.

Evidence

2026-04-25 fleet triage revealed:

• 55 engineering decisions were BLOCKED on Chad (direction-only operator)

because seats asked "permission to" instead of deciding themselves.

• Micro-scoped tickets created sequential dependency chains where one

blocked item froze 5+ downstream items.

• Claude Camber session demonstrated the alternative: wide-scope tickets

with CLAIMER MAY DECOMPOSE produced parallel sub-agent architecture exploration that surfaced gaps a single dispatcher would have missed.

The fleet's throughput bottleneck was not compute or context — it was authority concentration. Moving authority to information unblocked it.