# Paper 09: The Craft of Slicing **Series:** Aigile deep dives, paper 09 of 09. Elaborates working paper Section 8 step 2 and the sizing rule of Paper 04. Depends on Papers 04, 05, 06. ## Abstract Slicing is the step that sets the clock speed of the entire loop. Every downstream protocol inherits its properties from slice shape: review honesty depends on slice size (Paper 04), agent coherence depends on slice fitting one session, validation cadence depends on every slice being demoable (Paper 06), and the blast radius of a wrong decision is bounded by one slice (Paper 05). A methodology can state all of those protocols correctly and still fail in practice if teams slice by layer, by component, or by convenience, because each of those shapes silently disables a downstream protocol. This paper treats slicing as a craft with teachable rules: the unit of slicing (the user question answered), the two-sided binary sizing test, ordering by discovery value, the embedded-infrastructure rule, a catalog of split patterns, and the calibration loop that keeps the sizing parameters honest as agents and teams change. It contributes rules R33 through R36 and a full worked slicing session. ## 1. Position in the framework The sizing rule itself (one human sitting to review, one agent session to implement) is defined in Paper 04 as R12. This paper supplies what R12 presupposes: how to produce candidate slices worth sizing, how to order them, and how to keep the rule's two parameters calibrated. The walking-skeleton requirement (R20, Paper 06) is restated here from the slicing side, because the skeleton is a slicing decision before it is a validation decision. ## 2. The problem in full ### 2.1 Why slice shape is load-bearing Consider what each protocol assumes. Review economics assumes a change reviewable in one sitting; an oversized slice converts honest review into rubber-stamping regardless of reviewer discipline. Agent coherence assumes work fitting one session; a slice that spills over forces context reconstruction, and reconstruction is where constraints silently drop (Paper 02). The validation architecture assumes every slice can be demoed; a slice that cannot run end to end pushes validation to the end of the feature, which reconstructs mini-waterfall inside a nominally iterative process. The deviation protocol assumes a wrong slice costs one slice; a big slice raises the price of every andon decision and thereby discourages pulling the cord. Slicing is therefore not a preparatory chore before the method starts. It is the parameter block of the method. ### 2.2 Why the economics differ from classic story splitting Story splitting is an old agile craft, and its accumulated heuristics (vertical slices, INVEST, splitting by scenario and data variation) remain sound. Two economic facts shift the optimum, however. First, the agent session boundary is a cliff, not a slope: a human carries partial context overnight, an agent carries none, so the upper size bound is harder than the old "a story fits a few days" guidance. Second, the transaction cost per slice has collapsed, because the ceremony that made tiny stories uneconomical (estimation, board management, standup traffic) is gone or automated, and agents absorb per-slice boilerplate. When batch overhead falls, the optimal batch size falls with it. Classic teams stopped splitting at two or three days of work; aigile slices are typically hours, and the limiting factor becomes human demo attention rather than process overhead. ## 3. The mechanism ### 3.1 The unit: a user question answered A slice is defined by the question a user can answer after it ships that they could not answer before. This definition does three jobs at once. It forces verticality, because answering a question requires the whole path from input to visible output. It makes the slice demoable by construction, which feeds the validation architecture. And it generates acceptance criteria naturally, because "which orders are still pending?" converts directly into given/when/then scenarios. The classic INVEST checklist survives in adapted form: Independent becomes "builds only on validated slices"; Valuable becomes "answers a question"; Estimable is replaced by the binary sizing test; Small and Testable are absorbed by R12 and R13. ### 3.2 The sizing test, applied R12 is a binary test, not an estimate: one human sitting to review, one agent session to implement. Both capacities are empirical and measurable (median honest-review duration; session context ceiling for the agent generation in use), and both move over time, which Section 3.6 addresses. At slicing time the test is applied per candidate, and doubt resolves toward splitting: a slice kept on optimism costs a mid-build overrun, which is strictly worse than a split decided while attention is on the whole feature. A borderline slice may be kept with a flag; the flag obliges the spec step to confirm or split before build starts. ### 3.3 Ordering: skeleton first, then by discovery value Slice 1 is the walking skeleton (R20): the thinnest end-to-end cut, whose purpose is to expose misread intent at the cost of one slice. After the skeleton, slices are ordered by discovery value rather than convenience: slices touching constitution clauses, unknown integrations, or drift-prone areas come early, because their failures are the expensive ones and early failure is the cheap kind. Convenience ordering (easy slices first) produces a pleasant burn-down and a brutal ending, which is the pipeline failure mode reappearing inside the loop. ### 3.4 Infrastructure and spikes Infrastructure is built inside the first slice that needs it, sized to that slice's need. A queue needed for asynchronous import appears in the import skeleton as the smallest queue that carries one file, not as a preceding "messaging infrastructure" slice. The rule exists because horizontal setup slices are undemoable (disabling validation), invite gold-plating (building for imagined future slices), and defer the integration learning that vertical slices exist to force. Open technical questions are not slices either: they become timeboxed spikes whose deliverable is a written answer (a decision record or a spec input), never code that ships. The distinguishing test is simple: a slice always has acceptance criteria; a spike never does. ### 3.5 The split catalog When a candidate fails the sizing test, it is split along one of a small number of seams, listed roughly in order of preference: 1. **By scenario:** happy path first, then error and edge cases as their own slices (unknown address, expired link). 2. **By data variation:** one currency before multi-currency; one file format before its dialects. 3. **By population scope:** one entity before all entities; one pilot customer before the fleet. 4. **By operation:** read before write; view before edit; detect before repair. 5. **By rule depth:** flat calculation before tiered; single validation rule before the rule set. 6. **By fidelity:** the ugly-but-correct rendering first; refinement as a later slice only when the demo demands it. Two seams are inadmissible: by layer (frontend/backend/database) and by activity (design/build/test/integrate), because both produce undemoable increments. Constitutional criteria are not deferrable along any seam: a clause applies from the first slice in which it becomes meaningful, which is why the latency budget appears in the reconciliation skeleton (Paper 04 example) rather than in a final hardening slice. ### 3.6 Calibration The sizing test has two parameters, and both drift. Review sittings inflate quietly ("one sitting" grows to three hours), and agent session capacity changes with every model generation, usually upward, which moves the optimal slice size. Both are therefore measured: review minutes per slice as a distribution, and sessions actually consumed per slice against the target of one. The retrospective recalibrates the parameters and records them in the collaboration corpus, where the next slicing session, human or agent, reads them. Slicing skill itself compounds through the same corpus: rejected slicings and their reasons become norms, which is why an agent's first draft improves over time. ## 4. Normative protocol > **R33 (Vertical slicing).** Every slice answers a user question end to end and is demoable on the real data path. Slices by layer, by activity, or of pure setup are inadmissible. > **R34 (Discovery ordering).** Slice 1 is the walking skeleton. Subsequent slices are ordered by discovery value (constitution contact, unknown integrations, drift-prone areas early), and the ordering rationale is recorded with the slice list. > **R35 (Embedded infrastructure).** Infrastructure is built inside the first slice that needs it, sized to that slice's need. Open questions become timeboxed spikes whose deliverable is a written answer; a spike never ships code and never carries acceptance criteria. > **R36 (Slice calibration).** The sizing test's two capacities are measured (review-minute distribution, sessions per slice) and recalibrated at retrospectives; the current parameters and rejected-slicing norms live in the collaboration corpus. ## 5. Orderly worked example: slicing "order import" The feature: Orderly's pilot customer wants to upload order files exported from her ERP instead of entering orders manually. The intent names success as "she uploads yesterday's export and sees the orders in Orderly, with a clear report of anything that could not be imported." Relevant law: C-11 (idempotent ingestion) and C-03 (integer cents). **Draft 1 (rejected, by activity and layer):** file parser; validation engine; import queue and workers; upload UI; error report UI; integration. Nothing in this list is demoable, the queue is speculative infrastructure, and C-11 would be tested only at integration, which is where idempotency bugs are most expensive. **Draft 2 (rejected, oversized):** "upload a file and see imported orders with errors reported" as one slice. It answers a question, but the sizing test fails on both sides: parsing, validation, persistence, and reporting exceed one session, and the diff would exceed one sitting. **Accepted slicing, with the seams named:** ```text S1 Skeleton: upload one well-formed file with 3 orders; orders appear; re-uploading the same file changes nothing (C-11 from the first meaningful slice). Queue: none yet, synchronous is the smallest thing that works. [skeleton demo] S2 Malformed rows: the report names each rejected row and the reason; good rows still import. (split by scenario) S3 Currency and amount rules: C-03 enforced, mixed-currency files handled per the entity's bookkeeping. (split by rule depth) S4 Large files: import runs asynchronously with progress visible; the queue enters here, sized to this need. (population scope; infrastructure embedded, R35) S5 Second ERP dialect from the customer's subsidiary. (split by data variation) SPIKE (before S5, timeboxed half a day): the subsidiary's export encoding is undocumented; deliverable is a one-page decision record, not code. ``` Ordering rationale recorded per R34: C-11 contact puts idempotency in S1; the unknown dialect is late only because the spike de-risks it, and the spike is scheduled before S5, not discovered during it. At the skeleton demo, the customer's ops lead uploaded a real file and immediately asked why order references were truncated; the export uses 24-character references and the spec assumed 12. The deviation was behavioral (a test moves), cost one andon decision, and every later slice inherited the fix. Under draft 1, the same discovery would have arrived at integration, after the parser, the validator, and the persistence layer had each hard-coded the wrong length. ## 6. Failure modes - **Layer relapse:** slices by component reappear under schedule pressure. Detection: any slice whose demo requires "imagine the UI on top of this" (R33). - **The trailing polish slice:** unfinished criteria hidden in a final "cleanup" slice. Counter: criteria belong to the slice that introduced them; a polish slice may refine fidelity (seam 6) but never carry another slice's debt. - **Slice inflation:** the sitting and the session quietly grow. Detection: the R36 metrics; rising review-minute medians are the early signal. - **Confetti slicing:** slices so small that demo attention becomes the bottleneck and dependency management dominates. Counter: the lower bound is a question worth a human's demo minute; merge below it. - **Dependency braids:** parallel slices touching the same aggregate, producing merge conflicts and context collisions. Counter: slices form a chain or shallow tree on validated ground; parallelism is taken across features before within one. - **Spike creep:** spikes that quietly ship code. Counter: R35's deliverable test; spike output is a document. ## 7. Metrics Slices per feature (distribution); split rate at spec time (a healthy nonzero, since zero means borderline flags are being ignored); review minutes per slice; sessions per slice against a target of one; skeleton catch rate (share of misalignments caught at slice 1, which Paper 06's example put at 60 percent); slice rework fraction, which should be bounded by slice size. ## 8. Open questions Whether optimal slice size can be predicted from feature type rather than discovered per team; how the calibration parameters transfer across agent generations; whether agents can learn discovery ordering (R34) from corpus examples alone or need explicit risk models; the interaction of dependency-braid avoidance with multi-agent parallel execution, which grows more pressing as autonomy increases (Paper 07). ## 9. Derivative artifacts A slicing chapter for the practitioner playbook with the two rejected drafts as teaching material; the split catalog as a card or checklist; slice-list template with ordering rationale and risk flags; corpus starter entries (calibration parameters, rejected-slicing norms); training exercise sets (features to slice, with model answers).