# Aigile Practitioner Guide: One Feature, Two Workforces **Status:** Practitioner guide v0.1, July 2026 **Foundation:** Applies the aigile working paper v0.1 and deep-dive papers 01 through 08. Rule references (R1 through R36) cite the series rulebook. **Audience:** Teams who want to see what aigile looks like in practice, hour by hour and artifact by artifact, before adopting it. --- ## 1. How to read this guide This guide walks one real-shaped feature through the full aigile loop twice: - **Option A: the human-AI collaborative workforce.** Humans and agents both work the system actively. Humans hold defining authority on every check, supported by AI input. This is the left side of the authority matrix (Paper 07) and the recommended starting state for every team. - **Option B: the human expert with an agentic workforce.** Agents hold the operational roles. Humans contribute innovation input (feature intent), technical expertise (the constitutional mandate and lead architecture), and validation with brains, eyes, and hands. This is the right side of the matrix, reached through graduated autonomy, never adopted as a starting identity. The two options are not two methodologies. They are two states of the same authority matrix, and this guide is built to prove it: the feature, the artifacts, the protocols, and the human-owned intent layer are identical in both walkthroughs. Only the owner of each check changes. Read Option A fully first; Option B is written as a diff against it, which is itself an aigile habit (R14: review the change, not the corpus). Everything in fixed-width blocks is a literal artifact you can copy as a template. ![The aigile loop: forward flow, first-class backward edges](figures/fig1-aigile-loop.svg) *Figure 1: the loop both options run. Purple steps are human-owned at every autonomy level; dashed edges are the backward channels (R1) that keep the loop agile rather than waterfall.* --- ## 2. The scenario **Team Orderly** builds a B2B order-management SaaS. Four humans: Mira (product and domain), Jonas (lead architect), Priya and Sam (engineers). A set of coding agents. The system runs under constitution v2.5.0 (24 clauses after the last gardening session). **The feature.** At the last feature demo, the pilot customer's operations lead discovered, hands on the running software, that month-end reconciliation was harder than it should be. The verdict was **intent evolved** (R23), and it produced this backlog entry: ```text FEATURE INTENT: Reconciliation view Weight: FULL (new user-facing surface; ~5 slices expected) Origin: intent-evolved verdict, feature demo 2026-06-12 Owner: Mira A billing administrator closing the month needs to see, per billing entity, every order in the period, which invoice line it landed on, and every order that did NOT land on any invoice, with the reason. Success means the pilot's ops lead can complete her month-end close without exporting to Excel. Out of scope: corrections/write operations. Read only. Primary scenario (owner-written): Anna (billing admin, entity Nordwind AG) opens Reconciliation and selects March 2026. She sees every March order in one table: invoiced orders show their invoice line, unmatched orders show one of three reasons. She sorts unmatched by age, works the list top down, and finishes the close without opening Excel. Behavior decisions (made): - read only; corrections happen in the order module - unmatched reasons are exactly: pending, disputed, ingestion-failed - period = calendar month in the entity's timezone Deferred decisions (named, each with its deciding demo): - row granularity for split invoices (one row per order, or per invoice line): decide at the skeleton demo Sketch: sketches/reconciliation-01.png (owner-drawn table layout; binding for structure, not pixels) Known requirements (facts, not guesses): - amounts shown must equal invoice line amounts to the cent (C-03) Domain references: domain/invoicing.md ``` This is a full-weight intent, and its structure answers a question the method takes seriously: with building this cheap, what stops half-thought features from flooding in? The old filter was cost, and agents removed it, so the filter moves here. It works by testing thought rather than length. The primary scenario is the core of that test: Mira cannot write Anna's walkthrough without deciding how the feature behaves, yet unlike a classical requirements document, a scenario never pressures her to invent answers she does not have. Decisions she has made are listed as made. Decisions she has not made are listed as deferred, each with the demo that will decide it, and the split-invoice deferral above is exactly the question the skeleton demo later answered. The sketch does the same work for layout, which words underdetermine. Known requirements keep their provenance rule: facts at any length, nothing invented. Before slicing starts, the intent passes a short adversarial readiness check (who exactly is this for, what does it replace, walk the scenario); a full-weight intent whose owner cannot walk the scenario goes back at the cost of a conversation instead of a feature. Small internal features skip the full sections and keep the light form, because forcing ceremony onto small things recreates the disease this method treats. The division of labor stays constant across weights: the human authors decisions and scenarios, the machine drafts decompositions and formalizations, and agents may interview and challenge the owner but never invent behavior in her place. Whatever the loop discovers later becomes acceptance criteria, which is where requirements are cheapest to verify. ![The three-layer artifact model](figures/fig3-artifact-layers.svg) *Figure 2: where every artifact in this guide lives. The intent above and the specs below are Layer 2; the constitution excerpt is Layer 1; nothing in this guide hand-maintains a Layer 3 document.* **Relevant constitution clauses (excerpt, v2.5.0):** ```text C-03 Monetary amounts are integer cents. Floating point money is inadmissible anywhere. [v1.0.0] C-07 Billing entity is the invoice grouping key. [v1.1.0, origin: misalignment finding 2026-03] C-11 Order ingestion is idempotent. Duplicate submission of an order event MUST NOT create duplicate state. [v1.0.0] C-14 Order store is event-sourced; read paths go through read models, never through event replay at request time. [v2.0.0] C-19 p95 latency budget on all order-read paths: 300 ms. [v1.2.0] C-22 AUTHORITY MATRIX: see section 5 of this constitution. Current state recorded per row with track records. [v2.4.0] ``` **Where the rest of the technical rules live.** The constitution above mixes domain law (C-07) and technical law (C-03, C-11, C-14, C-19) on purpose: the admission test is enforcement, not subject matter. What it deliberately excludes is the larger body of technical conventions: error-handling patterns, API and naming conventions, test structure, logging, library choices. That material fails the andon test (violating a naming convention earns a review comment, not a stopped line), and it is too large for a document every agent loads every session. Orderly keeps it as scoped standards files: ```text .aigile/constitution.md law, ~1 page loaded every session .aigile/standards/ persistence.md conventions per area, loaded only when the api.md each <= 1 screen slice spec names them testing.md frontend.md .aigile/domain/ invoicing.md business knowledge per loaded only when the vat-rules.md topic, human-authored, slice spec names them each <= 1 screen on its Domain: line .aigile/decisions/ ADRs (the why behind loaded on demand: constitution clauses) amendments, conflicts ``` The wiring is one line in each slice spec, `Standards: `, filled in during slicing from the same knowledge that produces the risk flags. A build agent loads the constitution plus exactly the named files. The token effect is large: a monolithic engineering handbook of several thousand tokens, loaded across the dozens of agent sessions a feature consumes, costs more context than all slice specs combined, and it buries the hard constraints in convention noise. Scoped loading keeps the always-on layer at one page and pays for conventions only where they apply. Enforcement follows the same split: a constitution violation pulls the andon cord; a standards violation is a review finding, fixed in the PR. Both feed the drift statistics, so a constantly violated standard becomes a promotion candidate at gardening, and a standards file no slice ever loads becomes a deletion candidate. --- ## 3. Option A: the human-AI collaborative workforce Matrix state: every row left. Humans review every atomic PR, conformance is a retro ritual, Jonas decides amendments, Mira owns intent and validation. ### 3.1 Day 1 morning: intent and slicing Mira, Jonas, and an agent hold a thirty-minute slicing session. Slicing is the step most teams get wrong first, so this section shows the full exchange, including the drafts that were rejected. **The agent's first draft** slices by technical layer: ```text DRAFT 1 (rejected) S1 Backend: reconciliation API endpoints S2 Read model queries and indexing S3 Frontend: results table component S4 Frontend: filters and period picker S5 Integration, styling, polish ``` This looks orderly, and it is the most common mistake. No slice in this list can be shown to a user. The ops lead cannot react to "API endpoints", so validation is pushed to slice 5, and any misread intent survives until then. A feature sliced by layer is a small waterfall: build everything, integrate, then find out. **The corrected approach** slices by user question answered. Each slice cuts through every layer thinly (a vertical slice) and produces something a person can operate: ```text SLICES: reconciliation-view (accepted) S1 Walking skeleton: one entity, one period, matched orders only, ugly table, real data path end to end. [skeleton demo] S2 Unmatched orders with reason = pending. S3 Reason = disputed and reason = ingestion-failed. S4 Period selection and entity switching. S5 Totals row with match-rate percentage. [feature demo after] ``` Read the list as questions the user can now answer: S1 "which orders were invoiced?", S2 "which are still pending?", S3 "which failed, and why?", S4 "can I look at other months and entities?", S5 "how complete is my month?". Every slice earns a demo. The infrastructure each slice needs (a query, an index, a route) is built inside the slice that needs it; there is no "setup" slice. **Applying the sizing test.** The sizing rule (R12) is a binary test per slice, not an estimate: can one human review the change in one sitting, and can one agent implement it in one session's context? The team walks the list: ```text S1 one sitting? yes (thin table, one query) one session? yes OK S2 yes / yes OK S3 disputed + ingestion-failed + reason codes: review yes, but two data sources in one session? borderline -> keep, flag for a possible split during spec S4 yes / yes OK S5 yes / yes OK ``` A borderline slice is kept but flagged; if the spec confirms the doubt, it is split before the build starts, not apologized for after. (S3 later did get split in this project; see 3.6.) **Risk flags** are recorded now, while attention is on the whole feature: S4 touches period-boundary logic near the idempotency clause C-11, so it is marked as a candidate for a risk-pulled demo (R22). **A second example, for the pattern.** The same approach on a different feature, "password reset", to show that the shape generalizes: ```text By layer (wrong): token service / email templates / reset form / rate limiting / integration By user question (right): S1 Skeleton: request a reset for one known address, receive a plain email with a working link, set a new password. Ugly, end to end. [skeleton demo] S2 Unknown or unverified addresses: what does the user see? S3 Expired and reused links. S4 Rate limiting and lockout behavior. ``` **Slicing heuristics, in one place:** 1. Slice by user question answered, never by layer or component. 2. Every slice is vertical: it runs end to end and can be demoed. 3. Slice 1 is always the walking skeleton (R20). 4. The sizing test is binary: one sitting, one session. Split on doubt. 5. No setup, infrastructure, or research slices. Infrastructure lives inside the slice that needs it; open questions become a timeboxed spike with a written answer, not a slice. 6. Record risk flags (constitution contact, drift-prone areas) per slice at slicing time; they drive the demo pull signal later. The corrected slicing norm ("slice by user question answered, demoable end to end") came out of an earlier retrospective and lives in the collaboration corpus, which is why the agent's drafts improve over time: in Option B below, the first draft is already vertical. ### 3.2 Day 1 midday: the one-screen spec for S1 Priya writes the S1 spec with agent assistance, under the spec detail budget (Paper 05: what must be true, never what happens to be true): ```text SPEC S1: reconciliation skeleton constitution: v2.5.0 Standards: persistence, api Domain: invoicing Reviewer-comprehensible summary: a billing admin selects one entity and one closed month and sees a table of that entity's orders with the invoice line each landed on. Data comes from the real read models (C-14), not fixtures. ACCEPTANCE CRITERIA (executable unless justified): A1 [test] Given entity E with 3 orders in period P, all invoiced, the view lists exactly 3 rows, each with order id, amount (integer cents, C-03), invoice id, and invoice line id. A2 [test] Orders of other entities or periods never appear. A3 [test] Amounts shown equal the invoice line amounts to the cent. A4 [test] View renders from read models; no event replay on the request path (assert via instrumentation hook, C-14). A5 [test] p95 under 300 ms at 10k orders/entity synthetic load (C-19). A6 [prose, R13 justification: visual acceptability is validated at the skeleton demo by human eyes] Table is readable enough for the ops lead to orient herself. ``` Five of six criteria are executable; the sixth carries its justification and routes to the demo. The spec is 19 lines. Mira reads it in four minutes and confirms it matches her intent, which is the entire review (R4). ### 3.3 Day 1 afternoon: build, and an andon pull An agent implements S1 in one session. Mid-implementation it reports through the deviation protocol: ```text DEVIATION REPORT (agent, S1, 14:32) The spec assumes every invoiced order maps to exactly one invoice line. The read model contains orders split across two lines (partial-quantity invoicing, introduced in increment 2026-05-19). Accommodating this changes A1 and A3 (acceptance tests must move). Classification: BEHAVIORAL (R15, observable: tests must change). Work stopped. Options attached: (a) one row per order-line pair, (b) one row per order with expandable lines, (c) exclude split orders from S1 and slice separately. ``` The consortium is Mira plus Jonas, latency budget one hour (R16). They decide in twenty minutes: option (a) for the skeleton (simplest true representation). The intent had already named this question as a deferred decision for the skeleton demo, so the demo script gets a line probing whether the ops lead thinks in orders or in lines. The agent resumes; the spec-diff amending A1 and A3 ships in the same PR as the code (R17). ### 3.4 Day 2 morning: the atomic PR and human review ```text PR #412: S1 reconciliation skeleton stamps: constitution v2.5.0 code-diff: read-model query, view, instrumentation hook (+310) test-diff: A1..A5 executable, incl. split-order cases (+180) spec-diff: A1, A3 amended per deviation 14:32 (rationale attached), A6 unchanged (+9/-4) deviation log: 1 behavioral (resolved, see above), 2 implementation details (logged for retro) ``` Sam reviews the whole unit in one sitting, 25 minutes. Because the spec-diff sits next to the code-diff, he verifies not just that the code works but that the amended criteria still express Mira's intent. He flags one thing: the split-order test asserts row count but not line-amount summation; the agent adds the assertion. Merge. ### 3.5 Day 2 midday: the skeleton demo (R20) Fifteen minutes. Mira drives, hands on keyboard, real read models, brains-eyes-hands (R21 applies to every demo). Two findings within five minutes: the ops lead (joining remotely, also driving for ten minutes) confirms she thinks in orders, not lines, so option (a)'s line-pair rows feel wrong at scale. Verdict: ```text VERDICT S1: MISALIGNED (partial) 2026-07-01 Scribe-drafted spec-diffs (approved in session by Mira): SD-1: S1 display changes to one row per order with inline line breakdown; A1 amended accordingly. Becomes rework story S1b (est. half session). SD-2: New criterion A7 [test]: split orders visually flagged. Validated: data path, entity/period scoping, latency, amounts. ``` Half a session of rework at slice one, instead of the same discovery after five slices. This is the backward edge doing its job (R1), and it is the whole economic argument of the framework in one line item. ### 3.6 Days 3 to 6: the middle slices S1b, S2, S3, S4 proceed through the identical rhythm: one-screen spec, session build, atomic PR, one-sitting review. One implementation-detail deviation on S3 (the agent chose a different enum representation than the spec sketch; no tests move, logged, work continues, R15). S4 pulls a risk demo (R22): it touched the period-boundary logic adjacent to C-11 idempotency, and the pull signal fired. Jonas spends eight minutes with hands on the running view confirming boundary behavior at month edges. Sealed. ### 3.7 Day 7: feature demo and retro **Feature demo (R21).** The ops lead drives the full flow against a copy of her real data and completes a simulated month-end close in 22 minutes without Excel. One verdict line is misaligned (unmatched-order reasons need sorting by age), producing one scribe-drafted spec-diff and one small story. Everything else: validated. Feature seals under v2.5.0 stamps. **Retrospective (R29 through R32).** Three-output routing, thirty minutes: - *System learnings:* partial-quantity invoicing is now load-bearing enough that its absence from any durable artifact caused a mid-slice andon; a decision record is written (it fails the R7 andon-admission test for the constitution itself, and the team resists stockpiling). - *Collaboration learnings:* the agent's original UI-component slicing repeats a pattern from two features ago; the slicing prompt norm in the durable layer gains one line ("slice by user question answered, demoable end to end"). Written, merged (R30). - *Drift sweep (ritual, Paper 05):* two descriptive findings, batch-approved. Sweep took eleven minutes. The graduation trigger has not fired. - *Comprehension audit (R32):* all four humans had hands-on contact this cycle. Two minutes, no flags. **Option A totals for the feature:** roughly 9 human-hours across four people (slicing 2.0, spec review 0.7, PR reviews 2.5, andon 0.7, demos 1.6, retro 2.0) against six agent build sessions. Every human hour was spent on intent, judgment, or unmediated contact; none on typing boilerplate or re-reading corpora. --- ## 4. Option B: the human expert with an agentic workforce ![The authority matrix: Option A and Option B positions](figures/fig2-authority-matrix.svg) *Figure 3: the two options as matrix states. Teal markers are Option A, coral markers are Option B; the purple band is the fixed row that never moves.* Same company, fourteen months later. Orderly has **earned** this matrix state row by row (R26); it did not declare it. Constitution v3.2.0, section 5 records the current state and the track records behind it: ```text C-22 AUTHORITY MATRIX (v3.2.0) row state track record constitution amendments ARCH-AGENT within granted v3.0.0; mandate human mandate M-1 below; Jonas holds appointment + revocation feature intent+validation HUMAN (Mira) fixed row, R27 spec conformance STANDING AGENT graduated v2.8.0 after ritual trigger fired behavioral verification AGENT REVIEW + graduated v2.9.0, 30-incr 12% human sampling record; 1 revocation and re-grant in history mechanical verification AUTOMATED since v1.0.0 M-1 LEAD-ARCHITECT MANDATE (excerpt) Holder: arch-agent (model family B; builders run family A, R28) Scope: decide amendments classified patch or minor; propose but never decide major amendments; classify deviations escalated as constitutional; run impact census after majors. Excluded: anything touching C-22 itself, latency budgets, or the validation architecture. Excluded matters route to Jonas. Revocation: immediate on any incident; by Jonas at any time. ``` The humans' standing roles are now exactly the working paper's formula: Mira supplies innovation as feature intent and validates with brains, eyes, and hands; Jonas supplies technical expertise as the mandate holder, major-amendment authority, and sampling calibrator. Priya and Sam have moved to a second product; their comprehension budget on Orderly is deliberately maintained at sampling level because they remain the incident-response bench. ### 4.1 The same feature, replayed Assume reconciliation view arrives now. What changes, step by step: **Intent (unchanged).** Mira writes the identical intent paragraph. The fixed row does not move (R27), and nothing about agent capability makes it move: the intent is the input the whole system exists to serve. **Slicing (owner changes, correction survives).** A planning agent produces the decomposition. Because the collaboration corpus now contains the slicing norm written at the Option A retro ("slice by user question answered, demoable end to end"), the agent's first draft is already sliced correctly. This is the compounding the durable layer exists for: the Option A correction cost one retro line and has been free ever since. Mira approves the slices in five minutes. **Spec (owner changes, form identical).** A spec agent drafts S1 in the same 19-line form under the same detail budget; the prompt norms from the corpus shape the phrasing (scenario-form criteria, per a Paper 08 learning). Mira's review is unchanged: four minutes, does this match my intent. **Build and the same andon.** The builder agent hits the identical partial-quantity deviation and classifies it behavioral by the same observable test (R15). The difference is the consortium: the escalation first reaches the arch-agent, which determines this is not constitutional (no clause moves), attaches the same three options with consequence analysis, and, because acceptance tests must move and test changes sit on the behavioral row where intent is implicated, routes the decision to Mira under the same one-hour budget. She picks option (a) from her phone with the analysis attached; twenty minutes elapsed. The protocol is identical; two of its participants changed species. **Review (owner changes, tripwire persists).** PR #per-slice is reviewed by the reviewer agent: model family B, adversarially framed ("find the ways this violates the spec and constitution," R28). The 12 percent human sampling lottery selects S3 this feature; Sam reviews it exactly as he would have in Option A, and his findings (none, this time) feed the calibration record. Sampling never reaches zero, both as tripwire (Paper 07) and as comprehension spend (Paper 08). **Conformance (standing).** The conformance agent runs continuously rather than at retro cadence. During S4 it flags, within hours, that the period-boundary spec text has fallen out of date with a hotfix from the previous week: descriptive drift, spec-diff proposed, queued for human batch approval (R18: findings, not fixes). Median descriptive half-life at this matrix state: under 2 days, versus 6 in Option A. **Demos (unchanged, and non-negotiable).** Skeleton demo: Mira, hands on keyboard, same fifteen minutes, same class of discovery. Risk-pulled demo on the C-11-adjacent slice: the pull signal computes identically; Jonas drives for eight minutes. Feature demo: the ops lead drives. Any proposal to substitute recordings or agent summaries is not a rejected idea; it is an inadmissible one (R21, R27). In Option B these demos are not a residual human chore. They are the fitness function of everything else. **Retro (the circle, anchored).** The retrospective is now largely agent-run: agents assemble the three-output routing, draft the artifacts, and propose process improvements. This cycle the self-improvement circle proposes raising builder session scope, citing cycle-time projections. Under R24 the proposal must be evaluated against verdict-derived outcomes; the verdict history shows increments near the current session ceiling already correlate with higher misalignment rates. Rejected, with the rejection recorded. Mira and Jonas attend the retro as learners and as the audit: the comprehension worksheet (R32) shows Mira's contact concentrated in demos and Jonas's in sampling plus amendments, both above floor. The uncomfortable question is asked by a facilitator agent reading from the card, which the team reports makes it slightly more uncomfortable, and therefore better. **Option B totals for the feature:** roughly 3.5 human-hours (intent 0.5, slice and spec approvals 0.4, andon 0.3, sampling 0.5, demos 1.6, retro attendance 0.2), all concentrated on intent, law, and validation. The demo time is the one line that did not shrink from Option A, and that is by design: it is the anchor (Paper 06), and it is the number to protect, not to optimize. ### 4.2 An incident, because honesty requires one Two features later, sampling catches the reviewer agent approving a PR whose spec-diff silently weakened an idempotency criterion adjacent to C-11. Incident. The behavioral-verification row moves left the same day (amendment v3.3.0, R26): full human review resumes, the track record restarts, and the retro traces the cause to reviewer-prompt drift toward confirmation framing, which becomes a collaboration-corpus rule with a standing check. Thirty increments later the row re-graduates at 15 percent sampling. This round trip is not a failure of Option B. It is Option B working: autonomy as a license with points, trust as a paper trail, and the tripwire proving it is connected to something. --- ## 5. Side by side: who does what | Loop step | Option A (collaborative) | Option B (agentic workforce) | Invariant | |---|---|---|---| | Feature intent | Human writes | Human writes | Fixed row (R27) | | Slicing | Agent drafts, humans correct | Agent drafts from corpus, human approves | Sizing rule (R12) | | One-screen spec | Human writes, agent assists | Agent drafts, human confirms intent match | Detail budget, R4 | | Build | Agent, human pairing available | Agent | Deviation protocol (R15-R17) | | Andon decision | Human consortium | Arch-agent triages within mandate; behavioral intent decisions still reach the human | Latency budget (R16) | | PR review | Human, every PR | Agent (diverse model, adversarial) + human sampling >0 | Atomic PR (R11), R28 | | Conformance | Retro ritual, agent-assisted | Standing conformance agent | Findings not fixes (R18) | | Skeleton/feature/risk demos | Human drives | Human drives | Brains-eyes-hands (R20-R22) | | Verdict capture | Human + scribe agent | Human + scribe agent | Verdict routing (R23) | | Retro and gardening | Humans lead, agents report | Agents run, humans audit and anchor | R24, R29-R32 | | Constitution amendments | Human decides | Agent within mandate; majors and mandate itself human | R8, R25 | Read the last column top to bottom: that list is aigile. Everything in the middle two columns is configuration. ## 6. Choosing, and moving between the options - **Every team starts in Option A.** Option B is a destination reached row by row on evidence (R26), and the guide's incident section shows the road runs both directions. A team that cannot yet run Option A's rituals has no business granting Option B's licenses, because the licenses are defined in terms of those rituals' evidence. - **The migration order that has worked:** mechanical verification (day one), then conformance (on the Paper 05 graduation trigger), then behavioral review (on track record, with diversity and sampling from the first day of the grant), then amendment authority within a narrow mandate (last, if ever; a permanent Option A posture on this row is legitimate). - **The numbers to watch during migration:** sampling catch rate (calibration), misalignment rate by demo trigger (the anchor's health), drift half-life (the map's health), and human validation hours per feature, which should fall everywhere except the demo line. - **The one-way doors that do not exist:** every grant is revocable by amendment, and revocation latency is itself measured. If revoking feels organizationally unthinkable, the matrix has become a mode, and the team should read Paper 07's failure-mode section before proceeding. ## 7. Starter checklist (both options) ```text [ ] Constitution exists, one page, every clause passes the andon admission test (R7); version v1.0.0 tagged [ ] Repo layout: /constitution /decisions /specs/ /corpus (collaboration norms) + regeneration prompts for derived docs (R5) [ ] PR template enforces atomic unit: code + tests + spec-diff + deviation log + constitution stamp (R11, R9) [ ] Sizing rule adopted; "one sitting / one session" calibrated to your team and agents, recorded in the corpus (R12) [ ] Deviation report template with observable classification and the consortium's latency budget agreed (R15, R16) [ ] Demo runbooks for skeleton, feature, risk-pull; verdict artifact schema; scribe prompt ready (R20-R23) [ ] Retro agenda: three outputs + drift sweep + gardening cadence + comprehension worksheet (R29-R32) [ ] Authority matrix section in the constitution, all rows left, movement rules written before anyone asks to move one (R25, R26) ``` --- *End of practitioner guide v0.1. Derivative artifacts this guide feeds: onboarding workshop material, the repository template, demo and retro runbooks, and the migration playbook from Option A to Option B. Terminology and rule numbers follow the working paper and deep-dive series, which remain canonical.*