SPECIFICATION

SLICE Framework v0.2

Revised specification · 16 October 2026

Archived version. Superseded by v0.3 on 16 October 2026. Reproduced unchanged from the doc's revision 18; only this note was added.

0. Verdict and what changed

Agree with the direction; ten changes before it is pilot-ready. v0.1 is a sound delivery and forecasting framework. It is not yet a framework for the bottleneck it names: it treats planning as a cost to cut, while the thesis says deciding what to build is the scarce input. v0.2 fixes that tension and adds what 2025–2026 research shows about where AI gains actually disappear.

Kept from v0.1 unchanged: the five-level hierarchy, Now/Next/Later, the four item types, XS–XL sizing without hour equivalents, AI leverage as a forecast input rather than a discount, F0–F3 evidence labels, Direction/Target/Commitment, the conformance-rule approach and vendor neutrality.

On the research document: it is a good survey, with two corrections. METR's February 2026 update did not report a speedup; it reported that its new data was too biased to estimate one. And its illustrative day ranges and multiplier explorer should stay out of the spec; v0.1 was right to drop them.

1. The thesis, restated

Building is cheap. Deciding and proving are not. The founding claim, that knowing what to build and when is now the bottleneck, is right. But v0.1 answers it with "plan less", which only works once "planning" is split into three different kinds of work.

v0.1 handles coordination well (the Planning Budget) and proof partly (section 5.6). It barely handles decision work, which is the part the thesis is actually about. v0.2 makes all three explicit.

Two consequences follow. First, when building is cheap, building becomes a planning tool: a throwaway prototype is often a cheaper way to resolve a decision than a document or a meeting. Second, the specification stops being paperwork for humans and becomes context for agents, so the right spec is worth more than before, while the wrong kind of planning is worth less.

2. Evidence base

The evidence supports "building is cheaper" only unevenly, strongly supports "proof is a bottleneck", and supports "deciding is the bottleneck" mostly through practitioner testimony. SLICE should say so plainly, and treat the third claim as the hypothesis its pilots must test.

The gap SLICE can fill: nobody has measured decision latency or idea-to-evidence time in AI-native teams. If SLICE pilots record them, the framework produces the first evidence for its own thesis. That is a stronger launch asset than the framework text.

3. Landscape and positioning

SLICE should be the decision and forecasting layer above spec-driven execution tools, not another execution method. Since mid-2025 several AI-native methods have shipped. All of them answer "how do we get agents to build this well". None answers "which slice, why, how much, by when, and did it work".

Not distinctive (credit, do not claim): proportional process, vertical slices, appetite, flow metrics, spec-as-context.

Potentially distinctive (the five things to test):

1. A Decision Budget that treats throwaway builds as a planning instrument.
2. Verification capacity, not agent count, as the work-in-progress limit.
3. Forecast evidence labels (F0–F3) tied to Direction / Target / Commitment for investors.
4. Outcome hypotheses with kill criteria wired into the roadmap.
5. Measuring decision latency and idea-to-evidence time.

Public line: "Use SLICE to decide and forecast. Use any spec tool to execute." Gojko Adzic's warning that spec-driven development could bring back waterfall rigidity is SLICE's opening: SLICE is the discipline that keeps specs small and tied to evidence.

4. Principles (revised)

Core line: "Decide deliberately. Build small. Count only what is proven." It replaces "Shape only what matters. Build in small slices. Forecast from evidence.", which said nothing about the decision bottleneck.

Confidence moves into E, where it belonged. Capacity-bound is the principle the research most clearly supports, and the one most AI-era methods leave out.

5. SLICE Roadmapping (revised)

Every initiative in Now or Next becomes a Bet with a falsifiable outcome and a kill criterion. The hierarchy (Outcome → Initiative → Feature → Slice → Agent work), the Now/Next/Later horizons and the four item types stay as in v0.1.

5.1 The Bet

5.2 Changes to item types

• Experiment now explicitly produces a decision, not software. Throwaway code is expected and is deleted or archived when the decision is made.
• Delivery items are only "done" for the roadmap after their outcome review. Accepted delivery counts for forecasting; reviewed outcome counts for the roadmap.
• Removal is a legitimate result. When building is cheap, unused features pile up faster; an outcome review that ends in removal is a success of the method, not a failure of the team.

5.3 Prioritisation: a fourth rule

v0.1's three rules stay (obligations first, rank by value, urgency and evidence, then set an appetite). Add: when two bets are close, take the one whose evidence arrives sooner. In an AI-native team, time to evidence is usually a better tiebreaker than effort, because effort differences have shrunk.

6. The Decision Budget (replaces the Planning Budget)

Cap coordination time; size decision time to the cost of being wrong; and when the open question is about value, build instead of debating. This is the mechanism that answers the founding thesis directly.

6.1 Modes

The time boxes remain starting policy, not established standards.

6.2 Choosing the mode

1. Is the uncertainty about value (should we, which one) or about feasibility and risk (can we, safely)? Value → Mode B. Feasibility → Mode 2.
2. How costly is reversal? If a mistake reaches customer money, data or trust, Mode 3 overrides everything.
3. Otherwise use the lightest mode that leaves the stop rule answerable.

6.3 The stop rule (extended)

v0.1's four questions stay: the outcome or obligation, the smallest useful slice, the most consequential risk, and the evidence of completion. Add a fifth, a plain value-of-information test: would any realistic answer to the next open question change what we build? If not, stop planning and start.

6.4 Decision rights

Each Bet names one decider. Most decision latency comes from unclear decision rights, not missing information. Every decision is recorded in one line (what, why, who, date) in the repo, so humans and agents read the same record.

6.5 Measuring it

v0.1's Planning Overhead Ratio needs everyone to log planning effort, which few teams will do accurately. Replace it with two fields per slice: coordination minutes (estimated at close) and decision latency (time from a question being raised to its decision being recorded). The ratio can still be derived where data exists.

7. Specification as agent context (new)

Planning output must be readable by agents, not only by people, and it lives in the repository in three layers. An agent reads the repo and copies the patterns it finds, so stale or missing context becomes a defect, not a documentation gap.

Rules:

• Spec size follows the mode: Mode 0 none; Mode 1 the card; Modes 2 and 3 add a decision record and test plan. A longer spec needs a stated reason.
• Acceptance evidence is executable where possible. The test suite is the durable, machine-checkable form of the spec.
• Living, not frozen: when implementation contradicts the spec, update the spec first, then continue. This is the line between spec-driven work and waterfall in markdown.
• Every context file has an owner. Context older than the code it describes is flagged in review.
• Any format conforms: Spec Kit, BMAD stories, plain markdown. SLICE specifies what must be present, not the tool.

8. SLICE Forecasting (revised)

Keep v0.1's model; add decision waiting time to the formula, codebase type to the reference class, and minimum evidence to each forecast level. Size, AI leverage, risk, F0–F3 and P50/P85/P95 stay as defined in v0.1.

8.1 Decision wait becomes visible

v0.1 hid decision waiting inside "queue" or "external". Separating it lets every forecast show how much of the delay is the bottleneck SLICE claims exists.

8.2 Reference classes

A reference class is the combination of size, work type, Decision Budget mode and codebase context (greenfield, established, legacy). The Stanford data shows gains several times larger on simple greenfield work than on complex brownfield work, so history from one context never forecasts another.

8.3 Minimum evidence per level

Thresholds follow Magennis's sampling guidance and ProKanban's history window.

8.4 Change resets

A major change in model or tool, team or codebase phase opens a new reference window. Old history becomes a prior, not a forecast basis, until the new window meets its level's minimum. AI tooling changes often enough that this rule will fire several times a year.

8.5 Two forecasts per Bet

Each Bet carries a delivery forecast (F-level) and a separate outcome forecast, which is usually F0 or F1. They are never merged into one confidence figure.

8.6 Non-conformant practice

Any estimate of the form "traditional estimate × AI efficiency factor" is non-conformant. Leverage informs the choice of reference class; it never scales a number.

9. Verification capacity is the WIP limit (new)

New agent work starts only when the verification queue has room. By Little's Law, average cycle time equals work in progress divided by throughput. If review caps throughput, launching more agents only raises WIP and lengthens cycle time, which is what the Faros telemetry shows.

1. Declare capacity. State the human hours per week available for review, testing, acceptance and release decisions. Recalibrate monthly.
2. Pull, not push. Slices awaiting or under verification may not exceed what that capacity clears in about one week. Above the limit, stop starting and finish.
3. Reviewable slices. A slice must be reviewable in one sitting. Oversized diffs are split before review, not after. The 2025 data tied a 154% rise in PR size to a 91% rise in review time.
4. Verification tier follows risk.

5. Self-review is never independent. An agent's or author's own review counts as a check, not as assurance.
6. No unreviewed merges above Low risk. The unreviewed-merge rate is reported every cycle (section 11).

10. Workflow, cadence and the Slice Card

The loop now starts and ends with decisions, and verification capacity gates every new build. v0.1's six steps (Strategy, Shaping, Forecasting, Execution, Acceptance, Learning) become the loop below.

[Diagram not reproduced in this archived version: SLICE v0.2 workflow · 6 steps, 1 WIP gate.]

Three of six steps are decision work and two are proof work; only Build got cheap, which is why it is the one step SLICE does not try to optimise.

10.1 Cadence

No ceremony is mandatory; these are defaults for a team of up to about 25.

10.2 Slice Card v0.2

The v0.1 card gains a Bet link, the Decision Budget mode, the decider, the reference class, the verification tier and a close-out block. The close-out block is what turns daily work into forecasting history.

SLICE CARD · v0.2

Bet: Self-serve checkout (trial-to-paid 4% -> 6% within 8 weeks)
Slice: Test-mode checkout creates the correct entitlement after a confirmed payment
Mode: 3 (money)            Decider: founder
Size: L    Risk: High (consequence)    AI leverage: High
Reference class: L / integration / Mode 3 / established codebase
Acceptance evidence (as tests): successful, failed, delayed-webhook
  and duplicate-webhook payments
Primary uncertainty: webhook ordering and entitlement consistency
Verification: independent human review of payment and data changes
Forecast: 2-3 weeks · F1 scenario · Target
Open decisions: [question · owner · due]

Close-out (at acceptance): coordination minutes · decision latency ·
  cycle time · review wait · rework

11. Metrics (revised)

Measure each of the three bottlenecks, not only flow. v0.1 measured delivery well and decisions not at all. The six metrics marked mandatory are the minimum for a solo founder; the rest are for teams that need them.

The v0.1 rule stands: none of these becomes an individual performance target. Validated-outcome rate is the one most likely to be gamed, by writing timid hypotheses, so hypotheses are reviewed for ambition at the betting step.

12. Scaling, commitments and investor communication

Narrow the scaling claim to teams of 1–25 until pilots show otherwise, and print the evidence level beside every date. v0.1's "solo founder to hundreds of engineers" is untested and invites the wrong first customers.

12.1 Scope of the v0.2 claim

SLICE v0.2 is specified for solo founders and teams up to about 25. The 25+ column from v0.1 moves to an appendix marked "untested". Enterprise programmes bring governance that a v0.2 framework cannot credibly specify yet.

12.2 Commitment rules (tightened)

• Every external date shows its commitment type and evidence level, for example "Self-serve checkout · Target · Q1 · F1".
• A Commitment requires F2 or better, or the decider's written acceptance of F1 risk.
• Delivery dates and outcome forecasts are reported on separate lines, as in v0.1.

12.3 Investor update, one page

1. Bets in Now and Next, each with its hypothesis and evidence level.
2. Delivery: what was accepted, against the last update's targets.
3. Outcomes: reviews completed this period, validated-outcome rate, removals.
4. Forecast calibration: how the last period's targets compared with actuals.
5. Changes: what moved and why.

13. Conformance rules v0.2

Ten rules; a team that follows all ten practises SLICE, whatever its tools. v0.1 had seven; the three additions cover decisions, verification capacity and outcomes.

A team practising SLICE must:

1. Keep an outcome-connected roadmap with Now, Next and Later. Every Now and Next initiative is a Bet with a hypothesis, appetite, kill criterion and review date.
2. Choose a Decision Budget mode for each slice, and record coordination minutes and decision latency.
3. Name one decider per Bet, and log decisions in the repository.
4. Keep product context, decision log and slice specs in the repository, each with an owner and current with the code.
5. Split scheduled work into independently verifiable slices, each reviewable in one sitting; decompose XL before scheduling.
6. Record size, dominant risk, AI leverage, reference class and forecast evidence level for each slice.
7. Limit work in progress by declared verification capacity, with no unreviewed merges above Low risk.
8. Label every date with its commitment type and evidence level. Never present judgment as percentiles; never scale an estimate by an AI factor.
9. Count a slice as delivered only when its acceptance evidence passes, and a Bet as done only after its outcome review.
10. Track the six mandatory metrics and use them to change plans.

Optional: tools, AI models, cadence, sprints, role names and prioritisation formula.

14. Validation plan and how SLICE could fail

Pilot it on three genuinely different products for eight weeks, with pass/fail thresholds written before the pilot starts. v0.1's three stages stay; v0.2 adds the hypotheses and the red team.

14.1 Pilot hypotheses (thresholds are proposals)

A solo pilot has no control group, so results are before/after evidence only. External pilots (5–10 teams of 1–25 people, 8–12 weeks) should compare against two to four weeks of each team's previous process.

14.2 Red team: how SLICE fails

1. Measurement burden. Teams will not hand-log decision latency or coordination minutes. Mitigation: derive both from issue and repository timestamps; never require a timesheet.
2. Outcome reviews get skipped once shipping feels good, the classic failure of OKR-style systems. Mitigation: the review date is set at release and a Bet cannot close without it.
3. The card grows. Bet, Slice Card and reference class can recreate the overhead SLICE fights. Mitigation: if a Mode 1 card regularly takes over 30 minutes, cut fields.
4. The bottleneck moves again. If AI review becomes trustworthy, verification capacity rises and decisions dominate even more. SLICE must measure capacity, never assume it.
5. No moat in ideas. Every mechanism is copyable and overlaps BMAD, Shape Up and Kanban. Durable value comes from published pilot evidence, templates that live inside the tools teams already use, and a reputation for calibrated numbers.

15. Naming and clearance

Keep SLICE as the working name for pilots, but expect it to be hard to own; decide the public name after the pilots. The expansion becomes Strategic, Lightweight, Iterative, Capacity-bound, Evidence-driven Execution.

A web check found no existing methodology called "SLICE Framework", but the word is crowded in this exact space:

• XB Software's Functional Slices, an AI-era planning framework built on slices (June 2026).
• Vertical Slice Architecture, actively marketed as guardrails for AI development.
• The SLICE research team at LIRMM, Montpellier, working on AI-enabled software engineering.

A common English word that also describes the core unit is weak as a trademark and poor in search. Before public launch: run EUIPO and USPTO searches in classes 9, 41 and 42, check domains, and test whether "SLICE" plus a distinctive qualifier is enough. The decision does not block pilots.

Sources

• DORA 2025 State of AI-assisted Software Development (Google Research)
• InfoQ on the DORA 2025 report
• Splunk review of DORA 2025
• CGNET summary of DORA 2025 adoption and trust
• METR: We are changing our developer productivity experiment design (via Conffab)
• Particula: METR did not reverse its finding
• ScienceBlog on the METR randomised trial
• Rob Bowley on Faros AI 2025
• HackerNoon on Faros AI Engineering Report 2026
• Sirris on the Stanford 100k-developer study
• Andrew Ng, Stanford CS230 lecture 8 (Fall 2025)
• Allstacks: rethinking the PM-to-engineer ratio
• Shape Up, chapter 3: Set boundaries
• SEP: Monte Carlo forecasting process (Magennis sampling)
• ProKanban Flow Forecasting Pocket Guide
• Jellyfish: What is AI-DLC
• Nitor Infotech: BMAD Method guide 2026
• Charter Global: BMAD trade-offs
• Visual Studio Magazine: GitHub Spec Kit
• Spec-driven development notes, incl. Adzic's waterfall warning
• Augment: spec-driven development vs waterfall
• Glukhov: spec-driven development vs vibe coding
• XB Software: reinventing project management for AI-driven development
• Jimmy Bogard: Vertical Slice Architecture for AI development
• LIRMM SLICE team