SPECIFICATION

SLICE Framework v0.3.2 · Public alpha

Specification · 17 October 2026 · Milber Ferreira

Public alpha. SLICE is an open framework for planning, estimating and shipping software when AI writes much of the code. It is written for teams of 1–25 and is open for testing, criticism and refinement. It is not a proven framework, an industry standard or a successor to Scrum. Earlier versions, the research behind them and every decision are in the changelog and the decision log.

0. Status

v0.3.2 is the first public release of the alpha. It changes no rule. Version numbering keeps v0.4 for what the alpha teaches. The full history of earlier changes is in the changelog.

1. Thesis and vocabulary

When implementation stops being the slowest step, delivery is limited by deciding and proving. SLICE finds the current limit and manages work to it. AI tools now write much of the code in many teams. That makes building faster, but it does not make reviewing, testing, deciding or waiting faster, and it can add to them: more code to review, more model spend, more rework. SLICE plans and estimates the whole path to accepted delivery, not just the building.

1.1 Vocabulary

Never write "fast", "cheap" or "productive" without naming which of these is meant.

1.2 What AI changes, and what it doesn't

An illustrative estimate for an authentication module (sign-up, sign-in, password reset) in an established product. The numbers are judgment, not measurements; the shape is the point.

AI shortened every part, but unevenly: building shrank to a fraction of its old time, review and decisions only a little, and waiting not at all. The feature as a whole did not shrink in proportion. This is why SLICE never scales an old estimate by an AI factor (8.7): one factor cannot describe parts that AI speeds up by such different amounts. It is also why SLICE estimates verification and decisions separately in every forecast (8.1), and measures how much AI actually helps each part rather than assuming it.

2. Evidence base

The evidence supports a moving constraint more than any fixed speedup. Coding gains are real but uneven, downstream strain shows up consistently, and the decision bottleneck rests mostly on practitioner testimony. All telemetry below is observational association, not proof of cause.

The gap SLICE can fill: we found no published measurement of decision latency or idea-to-evidence time in AI-native teams. SLICE pilots that record them would produce first evidence for or against the thesis.

3. Landscape and positioning

Every individual SLICE practice already exists elsewhere; the claim is the combination, built for small AI-assisted teams.

SliceOps calls itself the decision-first framework for AI-first software engineering. It is open (spec v2.0 under CC BY 4.0, tooling under MIT), works in one-chat, one-PR atomic slices with decision records and evidence gates, and marks SliceOps as a trademark of its author.

The methods can be complementary: SliceOps governs execution evidence inside a slice; SLICE decides which slices deserve investment and whether they paid off. Section 15 covers the shared word.

Positioning claim (a hypothesis, not a proven fact): SLICE connects product investment decisions, proportionate planning, AI-assisted execution, verified delivery and empirical forecasting in one lightweight, tool-independent operating contract, designed first for teams of 1–25. We do not claim it is the first to do so.

What pilots must show is distinctive:

1. Proportionate Planning with an explicit Coordination Budget and Experiment-to-decide mode.
2. Constraint-aware WIP limits, with verification held as a risk floor.
3. F0–F3 evidence levels tied to Direction, Target and Commitment.
4. Delivery and outcome lifecycles kept separate in one roadmap.
5. Decision latency measured as a first-class metric.

Public line: "Use SLICE to decide, forecast and learn. Use any spec tool to execute."

4. Principles

Core line: "Decide deliberately. Build small. Count only what is proven." Five principles; "Execution" is what the framework governs, not a hidden sixth letter.

Constraint-aware comes with two specifics that make it concrete: a default presumption (verification) and a verification floor that applies whatever the constraint is.

5. SLICE Roadmapping

Every roadmap item is a Bet, an Obligation or an Improvement, and delivery and outcome run as two separate lifecycles.

5.0 Hierarchy and horizons

A feature holds several slices, and a slice may hold many agent actions. An estimate for one level is never an estimate for its parent.

Horizons are not fixed calendar periods. Each team sets how far ahead it can meaningfully commit: one or two weeks for a solo founder, four to six for an established team.

5.1 Item types

An Experiment is an activity inside a Bet, not a roadmap item: the least costly credible test of its uncertainty (section 6.3).

Guard: Improvement may not be used to avoid a hypothesis. Customer-facing work whose value is uncertain, or any item above the team's appetite threshold, is a Bet.

5.2 The Bet, with a criterion the team can actually measure

A percentage target must be detectable at the team's volume. Detecting a move from 4% to 6% conversion needs roughly 1,860 trials per group at 80% power and 5% significance, so early products should use count-based or qualitative criteria like the one above.

5.3 Two lifecycles

Invalidated does not mean remove. A hypothesis can be wrong while the feature stays necessary; removal is one possible decision at resolution, not the default.

5.4 Prioritisation

1. Obligations and critical dependencies first.
2. Rank discretionary items by value, urgency and the strength of their evidence.
3. Set an appetite and cut scope to fit it.
4. When two Bets are close, take the one whose evidence arrives sooner.

6. Proportionate Planning

Planning depth follows uncertainty and the cost of reversal, under three controls: cap coordination, gate decisions, fund learning. A hard decision that merits careful investigation is not waste; only coordination is budgeted down.

6.1 Three controls

6.2 Modes

6.3 Mode E: match the test to the question

A prototype answers usability; it rarely answers whether people will pay. This rule follows Lean UX and Teresa Torres's continuous discovery practice, both older than current AI tools.

6.4 The stop rule

Planning stops when the team can answer five questions: the outcome or obligation; the smallest useful slice; the most consequential risk; the evidence of completion; and whether any realistic answer to the next open question would change what gets built. If it would not, start.

6.5 Decision rights

Each Bet names one decider. Every decision gets one recorded line (what, why, who, date) where the team's people and agents can read it.

6.6 Measuring

Record coordination minutes and decision latency per slice, derived from issue and repository timestamps wherever possible, never from timesheets.

7. Specification as agent context

Every active slice has one authoritative, accessible, versioned source of intent, constraints and acceptance evidence, readable by the responsible people and agents. The repository is the preferred home for code-related context, not the only compliant one. An agent copies the patterns it finds, so inaccurate context is a defect.

Rules:

• Spec size follows the planning mode. A longer spec needs a stated reason.
• Acceptance evidence is executable where possible; the test suite is the durable form of the spec.
• Living, not frozen: when implementation contradicts the spec, update the spec first, then continue.
• Context is a defect when it is inaccurate, not when it is old. Each review asks whether the change made any context wrong.
• Any format conforms. SLICE specifies what must be present, not the tool.

8. SLICE Forecasting

Every forecast shows its sample, its assumptions and its track record; sample minimums are floors, never guarantees.

8.0 Size, AI leverage and risk

Sizes have no fixed hour or day equivalents. Teams calibrate them against their own accepted work.

Leverage informs the choice of reference class. It never shrinks a size or scales a number.

Risk is Low, Medium or High overall, with the dominant risk named in plain words. Consider uncertainty, dependencies, consequence and how hard the result is to verify. A high consequence or a hard-to-reverse change cannot be averaged away by low scores elsewhere.

8.1 Decision wait is visible

Separating decision wait lets each forecast show how much delay comes from the bottleneck SLICE claims exists.

8.2 Reference classes

A reference class combines size, work type, planning mode and codebase context (greenfield, established, legacy). History from one context never forecasts another.

8.3 Evidence levels

8.4 Why floors are not guarantees

With n comparable past observations, the chance the next one falls inside their range is:

For 7, 11 and 20 observations that is about 75%, 83% and 90%. It holds only for comparable work from a stable process, and says nothing about one particular slice. Twenty observations cannot support a 1-in-20 tail, so small teams report P50 and P85 only. Statistical acceptance criteria for each F3 model remain an open item, so F3 is unavailable during the public alpha.

8.5 Change resets

A major change in model or tool, team or codebase phase opens a new reference window; old history becomes a prior until the new window meets its floor.

8.6 Two forecasts per Bet

A delivery forecast (F-level) and a separate outcome forecast, usually F0 or F1. Never merged into one confidence figure.

8.7 Non-conformant practice

• Estimates of the form "traditional estimate × AI factor".
• Percentiles derived from judgment.
• A range shown without its sample count.

8.8 Quick estimate (informative)

Teams without measured history can still estimate honestly in about a minute by filling the four parts of the formula in 8.1 with judgment ranges, in working days:

1. Building with AI: hands-on time to build the slice with the team's AI tools.
2. Review and testing, set by the risk tier in 9.3. Starting suggestions: Low 0.25–0.5 days, Medium 0.5–2 days, High 2–5 days.
3. Decisions and design still open. Starting suggestions: none 0–0.5 days, some questions or screens to design 1–3 days. If big questions are open, do not estimate: decide first, or run a Mode E experiment (F0).
4. Waiting on people outside the team. Starting suggestions: none 0 days, one party 1–3 days, several parties or approvals 3–10 days.

Add the lower bounds and the upper bounds to get a range. The sum assumes the four parts run one after another for this slice; where they overlap the real time is shorter, and where the team splits its attention it is longer. Label it F1, for example "Authentication · Target · F1 · 3.5–9.5 working days". The suggested ranges are the author's judgment, not measurements: replace them with the team's own as soon as it has them. After seven comparable accepted slices, move to F2. The calculator does this arithmetic.

9. Constraint-aware flow and verification

Control work in progress at the team's current constraint, and verify every slice to its risk tier whatever that constraint is. By Little's Law, average cycle time equals work in progress divided by throughput, so starting more work than the constraint can clear only lengthens cycle time.

9.1 Find the constraint

The constraint is the step where comparable slices wait longest: review, QA, a decision, deployment approval, customer access or legal clearance. Re-identify it monthly from wait times. Until measurement says otherwise, presume it is verification: successive Faros reports show the strain moving between review and QA rather than disappearing.

9.2 Work-in-progress rule

No new work enters while the queue in front of the constraint holds more than about one week of its capacity. If decisions are the constraint, stop producing implementation options nobody is ready to evaluate.

9.3 Verification floor

Self-review or a second agent is a check, never independent approval. No unreviewed merges above Low risk.

9.4 High risk without a second person

1. Reduce the consequence by design first: provider-hosted payment pages, managed authentication, test modes, feature flags, exposure to a few users at a time.
2. Buy independent review for what remains before real money, sensitive data or access control go live: a contracted specialist or a provider's security review.
3. Where independence is impossible, record the accepted risk and its limits (number of users, amounts, data involved) and keep exposure within them.

10. Workflow, cadence and minimum records

Decide, shape and forecast, build, verify, learn; new builds start only when the current constraint has room. No ceremony is mandatory.

1. Decide: choose the Bet, Obligation or Improvement and its decider.
2. Shape and forecast: cut slices, choose each slice's planning mode, write acceptance evidence, forecast.
3. Gate: start building only if the queue at the constraint holds less than about a week of work (9.2).
4. Build: people and agents implement the slice.
5. Verify: check it against its acceptance evidence at its risk tier (9.3). The slice is Accepted.
6. Learn: on the review date, resolve the Bet against its decision criterion.

Delivery completes at Accepted; the outcome closes later, at Learn. Proof work is only the default constraint, so the gate moves to wherever measurement puts it.

10.1 Cadence

10.2 Minimum records

A solo founder keeps three records, nothing more:

A team of 25 uses the same three records and adds dependency ownership and portfolio roll-ups. Timestamps and costs are collected automatically wherever possible. A Mode 1 slice card should stay under ten fields.

10.3 Slice card example (Mode 3)

SLICE CARD

Roadmap item: Bet · Self-serve checkout (outcome state: Active)
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
Consequence reduced by design: provider-hosted checkout; test mode until review passes
Verification: contracted specialist reviews webhook and entitlement code before live mode
Forecast: 2-3 weeks · F1 scenario · Target
Delivery state: Building

Evidence record (at Accepted): dates · review result · people hours ·
  AI spend · rework · what was learned

11. Metrics and delivery economics

Six mandatory metrics, one for each part of the system, plus optional economics. Everything else is for teams that need it.

Not used: cost per validated outcome. A small team resolves a handful of dissimilar Bets per quarter, so the ratio is noise.

No metric becomes an individual performance target. Outcome resolution is the one most easily gamed, by writing timid hypotheses, so hypotheses are reviewed for ambition when the Bet is approved.

12. Scaling, commitments and investor communication

SLICE is specified for teams of 1–25, and every external date shows its evidence level. Larger organisations stay in an untested appendix until pilots justify more.

12.1 Scope

12.2 Commitment rules

• Every external date shows commitment type, evidence level and sample count, for example "Self-serve checkout · Target · Q1 · F2 (n=9)".
• A Commitment needs F2 or better, or the decider's written acceptance of F1 risk.
• Delivery dates and outcome forecasts are reported on separate lines.

12.3 Investor update, one page

1. Bets, Obligations and major Improvements in Now and Next, with evidence levels.
2. Delivery: what was accepted against the previous targets.
3. Outcomes: Bets resolved this period, and how.
4. Calibration: how last period's forecasts compared with actuals.
5. Economics: total delivery cost and AI spend.
6. Changes: what moved and why.

13. Conformance rules

Ten rules; a team that follows all ten practises SLICE, whatever its tools.

A team practising SLICE must:

1. Keep an outcome-connected roadmap with Now, Next and Later, classifying each item as a Bet, Obligation or Improvement with that type's required fields.
2. Choose a planning mode for each slice, and record a reason whenever coordination exceeds its budget.
3. Name one decider per Bet, and record decisions where the team's people and agents can read them.
4. Keep one authoritative, accessible, versioned source of intent, constraints and acceptance evidence for every active slice.
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. Identify the current constraint and limit work in progress there; verify every slice to its risk tier, and never present self-review as independent approval.
8. Label every date with its commitment type, evidence level and sample count; never present judgment as percentiles; never scale an estimate by an AI factor.
9. Track delivery state and outcome state separately: a slice counts at Accepted, a Bet closes at Resolved.
10. Track the six mandatory metrics and use them to change plans.

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

14. Validation plan and how SLICE could fail

Pilot SLICE with 5–10 teams building genuinely different products for eight weeks, with thresholds written before the pilot starts (see the pilot protocol). The biggest open question is whether the method improves decisions, cost or forecasts at all, not whether its text is complete.

14.1 Pilot hypotheses (exploratory thresholds)

The thresholds are exploratory. With 5–10 teams and no control group, passing or failing one shows a direction, not a cause. Teams compare against two to four weeks of their own previous delivery data where it exists; teams without it still join. F3 forecasting is unavailable during the alpha until its statistical acceptance criteria are defined.

14.2 Red team: how SLICE fails

1. Measurement burden. Teams will not hand-log latency or coordination time. Mitigation: derive both from timestamps; no timesheets.
2. Outcome reviews get skipped once shipping feels good. Mitigation: the review date is set when the Bet is approved, and a Bet cannot close without resolution.
3. The records grow. Three records can still recreate the overhead SLICE fights. Mitigation: H6, and cut fields when it fails.
4. The wrong constraint gets managed. A team protects review while decisions are the real limit. Mitigation: monthly constraint check from measured waits.
5. No moat in ideas. Every mechanism overlaps Spec Kit, BMAD, Shape Up, Kanban or Evidence-Based Management. Durable value comes from published pilot evidence and templates inside the tools teams already use.

14.3 Alpha principle

If a team needs hours of explanation before it can use SLICE, the alpha has reproduced the planning overhead SLICE exists to remove. Count that as an H6 failure, and fix the onboarding before touching the method.

15. Name

The public name is SLICE Framework, SLICE for short. The expansion is Strategic, Lightweight, Iterative, Constraint-aware, Evidence-driven. "Slice" also stays the generic name of the delivery unit, as in vertical slicing, and SLICE makes no trademark claim to the word.

The word is used elsewhere in this space. SLICE is not affiliated with any of these:

• SliceOps, an open, decision-first framework for AI-first software engineering built on atomic slices. It governs execution evidence inside a slice; SLICE decides which slices deserve investment and whether they paid off (section 3).
• XB Software's Functional Slices, slice-based planning with multiplier estimates, which SLICE rejects.
• Vertical Slice Architecture, a code-organisation pattern.
• The SLICE research team at LIRMM, Montpellier, working on AI-enabled software engineering.

The naming research and the alternatives considered are in Research.

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: changing the developer productivity experiment design (via Conffab)
• ScienceBlog on the METR randomised trial
• Rob Bowley on Faros AI 2025
• HackerNoon on Faros AI, Acceleration Whiplash
• Faros AI, The Speed Trap
• Sirris on the Stanford 100k-developer study
• Andrew Ng, Stanford CS230 lecture 8 (Fall 2025)
• Shape Up, chapter 3
• SEP: Monte Carlo forecasting process
• ProKanban Flow Forecasting Pocket Guide
• Spec Kit on PyPI
• Spec Kit idea assessment quickstart
• OpenSpec project summary
• Allstacks: spec-driven development isn't waterfall (Kiro)
• Jellyfish: What is AI-DLC
• Nitor Infotech: BMAD Method guide 2026
• Charter Global: BMAD trade-offs
• Scrum.org: Evidence-Based Management key value areas
• XB Software: project management for AI-driven development
• Jimmy Bogard: Vertical Slice Architecture for AI development
• LIRMM SLICE team
• SliceOps