Archived version.Go to the current version (v0.3.2 · Public alpha)

SPECIFICATION

SLICE Framework v0.3

Revised specification · 16 October 2026

Archived version. Superseded by v0.3.1 (Public Alpha) on 16 October 2026. Reproduced unchanged as published; only this note was added.

0. Status and what changed in v0.3

v0.3 is a pilot-ready working specification, not a public standard. It adopts most of an external critical review of v0.2, adds five amendments of its own, and corrects four errors v0.2 made.

#	Change from v0.2	Reason	Section
1	"Building is cheap" replaced by a sharper thesis and a fixed vocabulary	"Cheap" mixed up speed, effort and cash	1
2	Decision Budget becomes Proportionate Planning: Coordination Budget, Decision Gate, Learning Investment	The old name implied capping decisions, the opposite of the thesis	6
3	Build to decide becomes Experiment to decide (Mode E)	A prototype cannot test willingness to pay	6
4	Capacity-bound becomes Constraint-aware, with verification as the default presumed constraint	The limit differs by team and keeps moving	4, 9
5	Separate delivery and outcome lifecycles	Delivery can finish weeks before an outcome can be judged	5
6	Item types Bet, Obligation and Improvement, with a guard on Improvement	Not all work is an experiment	5
7	Sample minimums are floors, not guarantees; F3 needs back-tested calibration; no P95 for small teams	v0.2 treated an order-statistics result as a forecast guarantee	8
8	Spec rule becomes "one authoritative, versioned source of intent"	Repository-only was too restrictive	7
9	Solo high-risk work: reduce the consequence by design, then buy specialist review	v0.2's independent-review rule was impossible for one person	9
10	Delivery economics added; cost per validated outcome rejected	Cash cost is real; outcome counts are too small to divide by	11
11	Three minimum records: Roadmap item, Slice card, Evidence record	Keeps solo overhead low	10
12	Positioning corrected for Spec Kit, OpenSpec, Kiro and Evidence-Based Management	v0.2 understated the overlap	3

Errors in v0.2, now corrected: Spec Kit is no longer a feature-only tool; the 4% to 6% checkout example needed roughly 1,860 trials per group to detect; the solo independent-review rule could not be met; and "done after outcome review" mixed two lifecycles.

Still open: the public name, statistical acceptance criteria for each forecast model, and whether the combined method outperforms existing approaches at all.

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. v0.2's "building is cheap" is retired: AI can shorten implementation while raising model spend, review, rework or maintenance.

Kind of work	What it is	SLICE stance
Coordination	Estimating, tickets, status, specs written only for other people	Minimise it under a Coordination Budget
Decision	Choosing the user, the problem, the investment, the scope cut and the evidence that counts	Gate it; give it the time the uncertainty needs
Learning	Getting evidence that resolves a decision: interviews, tests, prototypes	Fund it as a Learning Investment
Verification	Showing that an implementation meets its acceptance evidence	Never skipped; sized to risk

1.1 Vocabulary (frozen for v0.3)

Term	Meaning
Generation speed	How fast an agent produces a first implementation; tooling analysis only
Implementation effort	Human attention needed to build or change a solution
Delivery lead time	Request to accepted release
Verification effort	Work to show an implementation meets its acceptance evidence
Total delivery cost	People, AI usage, tooling, testing, infrastructure, rework and release
Cost of learning	Spend to obtain evidence for a product decision
Value delivered	Measured customer, business or operational benefit
Accepted	Delivery done: acceptance evidence passed
Resolved	Outcome judged: validated, invalidated, inconclusive or superseded

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

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.

Source	Finding	Implication for SLICE
DORA 2025, ~5,000 professionals	AI amplifies existing strengths and dysfunctions. Adoption now correlates positively with throughput, but stability remains a problem; 30% report little or no trust in AI output.	AI is an execution resource, not a multiplier. Small batches and quality systems are prerequisites.
METR RCT and Feb 2026 update	Early 2025: experienced developers 19% slower, yet felt 20% faster. The 2026 follow-up could not size newer tools' effect because of selection effects.	No credible universal speedup exists. Forecast only from your own measured delivery.
Faros AI 2025, 10,000+ developers	More tasks and PRs per developer, but review time +91% and PR size +154%; company-level delivery flat.	Gains leak downstream.
Faros AI, Acceleration Whiplash, early 2026, 22,000 developers	Median time in review +441.5%; PRs merged without review +31.3%; incidents per PR +242.7%.	Review was the visible constraint.
Faros AI, Speed Trap, Q3 2026	Unreviewed merges +76%; time in QA roughly tripled; restarts +67%. Checking moved further downstream to QA, SRE and on-call.	The constraint moves. SLICE must find it, not assume it.
Stanford, Denisov-Blanch, ~100,000 developers	Larger gains on simple greenfield work than on complex brownfield work, plus added rework.	Codebase type belongs in every reference class. The percentages are indicative for that population, never multipliers.
Andrew Ng, Stanford CS230	Names a product-management bottleneck; engineer-to-PM ratios trending toward 1:1.	Supports the thesis, as expert testimony rather than measurement.
Shape Up	Appetite: a time budget set before shaping; fixed time, variable scope.	Source of SLICE's appetite.
Order statistics (SEP, ProKanban)	With n comparable past items, the chance the next falls inside their range is (n−1)/(n+1): about 75%, 83% and 90% for 7, 11 and 20.	Useful as a floor for F2, not as proof of calibration (section 8).

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. v0.2 said other AI-native methods only cover execution. That was wrong.

Method	What it already does	Overlap	Where SLICE differs
GitHub Spec Kit	Spec-driven development, bug fixing, and an idea-assessment process ending in go, needs-clarification or kill	Decision gates, living specs	No roadmap, forecasting or post-release outcome review
OpenSpec	Lightweight change proposals and spec deltas reviewed before code	Living agent context	Change-level only
Kiro (AWS)	Spec-driven IDE	Specs and task decomposition	Tool-bound; no portfolio or forecasting
AWS AI-DLC	AI leads execution, humans hold decisions; short "Bolts"; Mob Elaboration	Operating model, persistent context	Ceremony-based; no forecasting or outcome loop
BMAD Method	Agent personas, PRDs and stories; planning tracks scaled to complexity	Proportionate planning	Document-forward; no roadmap or forecast
Shape Up	Appetite, shaping, betting, six-week cycles	Appetite, bets	SLICE runs continuous flow and adds forecasting
Kanban (ProKanban)	Flow metrics, Monte Carlo forecasting	F2–F3, WIP	SLICE adds decision and outcome layers
Evidence-Based Management (Scrum.org)	Four key value areas: Current Value, Unrealized Value, Time to Market, Ability to Innovate	Outcome evidence, experimentation	A measurement lens without delivery mechanics for agents
XB Software Functional Slices	Slice-based planning with multiplier estimates	Same unit and vocabulary	SLICE rejects multiplier estimates

An external review also cited a framework called "SliceOps". We could not find it as an AI development method, so it is excluded until a source exists (section 15).

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:

Proportionate Planning with an explicit Coordination Budget and Experiment-to-decide mode.
Constraint-aware WIP limits, with verification held as a risk floor.
F0–F3 evidence levels tied to Direction, Target and Commitment.
Delivery and outcome lifecycles kept separate in one roadmap.
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.

Letter	v0.1	v0.2	v0.3	Rule it creates
S	Strategic	Strategic	Strategic	Every item traces to an outcome, an improvement or an obligation.
L	Lightweight	Lightweight	Lightweight	Minimise coordination; keep necessary decisions and assurance.
I	Iterative	Iterative	Iterative	Build, test, decide and adapt in small, evidence-generating increments.
C	Confidence-led	Capacity-bound	Constraint-aware	Find the current limit on flow and control work in progress there. Verification is the presumed constraint until measured otherwise.
E	Evidence-driven	Evidence-driven	Evidence-driven	Forecasts, delivery claims and product decisions state their evidence and confidence.

Constraint-aware is more generic than Capacity-bound, so SLICE keeps 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. The hierarchy (Outcome → Initiative → Feature → Slice → Agent work) and the Now/Next/Later horizons stay as in v0.1.

5.1 Item types

Type	Use for	Required fields
Bet	Discretionary investment under uncertainty	Hypothesis, evidence today, appetite, decider, decision criterion, review date
Obligation	Required security, legal, contractual or operational work	Owner, acceptance standard, deadline if any, consequence of missing it
Improvement	Enhancement with an observable benefit and low uncertainty	Expected benefit and how it will be observed

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

Field	Example
Hypothesis	Trial users offered self-serve checkout will pay without a sales call
Evidence today	9 of 12 interviewed trial users asked to pay without a call
Appetite	3 weeks of verified delivery
Decision criterion	Continue if at least 5 of the first 20 trials start checkout and at least 2 pay; stop if fewer than 2 start
Review date	After 20 trials or 8 weeks, whichever comes first

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

Lifecycle	States	Counts toward
Delivery	Ready → Building → Verifying → Accepted	Throughput and forecasting, as soon as a slice is Accepted
Outcome	Proposed → Active → Measuring → Resolved	Roadmap learning; resolved as validated, invalidated, inconclusive or superseded

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

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

6. Proportionate Planning (replaces the Decision Budget)

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

Control	Purpose	Rule
Coordination Budget	Limit admin, status and documentation	Time-boxed by mode; exceeded only with a recorded reason
Decision Gate	What must be known or decided before work moves on	Passes when the stop rule (6.4) is answerable
Learning Investment	Resources to resolve uncertainty	Sized to the cost of being wrong, not capped by the Coordination Budget

6.2 Modes

Mode	Use when	Output	Illustrative coordination time box
0 Direct	Reversible, obvious change	One line of acceptance	5 minutes
1 Slice brief	Bounded feature, known interfaces	A slice card	15–30 minutes
E Experiment to decide	A desirability, usability, price or feasibility question blocks the decision	The least costly credible test and one recorded decision	Set by the Learning Investment
2 Technical shape	Architecture, migrations, dependencies	A decision record and a spike	1–2 hours before the spike
3 Assured design	Money, access control, sensitive data, irreversible migrations, regulation	Reviewed design and test plan	Risk-governed, no ceiling

6.3 Mode E: match the test to the question

Uncertainty	Credible tests	Does not prove
Desirability	Interviews about past behaviour, fake-door test, waitlist conversion	Willingness to pay
Usability	Clickable or working prototype with five or more target users	Desirability
Willingness to pay	Pre-orders, deposits, a real checkout at real prices	Retention
Feasibility	Technical spike, small real implementation	Anything about customers

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.

Layer	Contents	Typical homes
Product context	Target user, outcomes, glossary, constraints, non-negotiables, design-system rules	AGENTS.md, CLAUDE.md, a Spec Kit constitution, or a managed workspace such as a Lovable project
Decision log	One line per decision: what, why, who, date	The repository or the roadmap tool
Slice spec	The slice card plus acceptance evidence, as tests where possible	Beside the branch, an OpenSpec change folder, or the slice card itself

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. Size (XS–XL), AI leverage and risk stay as in v0.1.

8.1 Decision wait is visible

T_{\text{slice}} = T_{\text{active}} + T_{\text{review and queue}} + T_{\text{decision wait}} + T_{\text{external wait}}

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

Level	Definition	Floor (necessary, not sufficient)	May report
F0	Insufficient definition or evidence	—	"Not estimated"
F1	Judgment or analogous work	—	Labelled scenarios; never percentiles
F2	Measured history of comparable work	7+ comparable accepted slices since the last major change	Observed range, sample count, known differences
F3	Probabilistic model with demonstrated calibration	Enough history for the model, plus at least three back-tested forecasts with their hit rate	P50 and P85 with assumptions and hit rate; P95 only with a large, calibrated history

8.4 Why floors are not guarantees

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

P\left(\min(X_1,\ldots,X_n) \le X_{n+1} \le \max(X_1,\ldots,X_n)\right) = \frac{n-1}{n+1}

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.

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.

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

Risk	Minimum verification
Low	Automated tests pass; agent review; human skim of the diff
Medium	Automated tests; full human review of the diff against acceptance evidence
High (Mode 3)	Independent review by someone who did not direct the agent; explicit approval for data, money or security changes

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

Reduce the consequence by design first: provider-hosted payment pages, managed authentication, test modes, feature flags, exposure to a few users at a time.
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.
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.

[Diagram not reproduced in this archived version: SLICE v0.3 loop · 6 steps, 1 constraint gate.]

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

When	What	Time
Continuous	Build, verify, release	—
Weekly	Flow check: work at the constraint, waits, decisions open too long	20 minutes
On each review date	Outcome review: resolve the Bet	15 minutes per Bet
Monthly	Bet review; re-identify the constraint; check reference windows	60 minutes
Quarterly	Strategy and investor update	Half a day

10.2 Minimum records

A solo founder keeps three records, nothing more:

Record	Holds
Roadmap item	Type (Bet, Obligation, Improvement), outcome or reason, Now/Next/Later, owner or decider, appetite, commitment type, outcome state
Slice card	What changes, acceptance evidence, size, risk, AI leverage, planning mode, forecast and evidence level, delivery state
Evidence record	Actual dates, verification result, costs (people, AI, tooling), what was learned

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)

markdown

SLICE CARD · v0.3

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.

Area	Metric	Definition	Status
Flow	Accepted throughput	Slices accepted per week, by reference class	Mandatory
Flow	Cycle time	Start to Accepted	Mandatory
Flow	WIP and item age	Items in progress and how long each has waited	Optional
Decision	Decision latency	Question raised to decision recorded	Mandatory
Decision	Idea-to-evidence time	Bet approved to first decision-relevant evidence	Optional
Constraint	Wait at the constraint	Queue time before the current constraint; review wait by default	Mandatory
Proof	Unreviewed-merge rate	By risk tier	Optional; must be reported if any occur above Low
Proof	Rework, restarts, change failure	As DORA defines change failure	Optional
Outcome	Outcome resolution	Share of Bets resolved by their review date, and how they resolved	Mandatory
Forecast	Calibration	Share of actuals inside the stated range (F2) or P85 (F3)	Mandatory
Economics	Cost per accepted slice	Total delivery cost ÷ accepted slices, within one reference class only	Optional
Economics	Learning spend per Bet	Cost of learning attributed to each Bet	Optional
Economics	AI and tooling spend	Per month and per accepted slice	Optional

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 v0.3 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

Area	Solo / 2–5	6–25
Decision rights	Founder decides; decisions recorded	One decider per Bet
Constraint	Founder re-identifies monthly; verification presumed	Per team; review load shared, never pushed into a separate QA queue
Forecasting	F1 scenarios until F2 floors are met	F2 per reference class; F3 only with back-tested calibration
Reviews	Outcome reviews on their dates; weekly 20-minute flow check	Weekly flow check; monthly Bet review

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

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

13. Conformance rules v0.3

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

A team practising SLICE must:

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.
Choose a planning mode for each slice, and record a reason whenever coordination exceeds its budget.
Name one decider per Bet, and record decisions where the team's people and agents can read them.
Keep one authoritative, accessible, versioned source of intent, constraints and acceptance evidence for every active slice.
Split scheduled work into independently verifiable slices, each reviewable in one sitting; decompose XL before scheduling.
Record size, dominant risk, AI leverage, reference class and forecast evidence level for each slice.
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.
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.
Track delivery state and outcome state separately: a slice counts at Accepted, a Bet closes at Resolved.
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 v0.3 on three genuinely different products for eight weeks, with thresholds written before the pilot starts. 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 (thresholds are proposals)

#	Hypothesis	Passes if
H1	Proportionate Planning shortens decisions	Median decision latency falls 30%+ from the first two weeks to the last two
H2	Less coordination does not cost quality	Coordination minutes per slice fall while rework and change failure do not rise
H3	Forecasts are calibrated	70%+ of F2 actuals fall inside the stated range
H4	The outcome loop runs	80%+ of Bets resolve on or near their review date
H5	The WIP rule protects the constraint	Wait at the constraint stays flat while accepted throughput rises
H6	Overhead stays low	80%+ of Mode 1 slice cards take under 10 minutes and under 10 fields

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. F3 is not used in pilots until its statistical acceptance criteria are defined.

14.2 Red team: how SLICE fails

Measurement burden. Teams will not hand-log latency or coordination time. Mitigation: derive both from timestamps; no timesheets.
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.
The records grow. Three records can still recreate the overhead SLICE fights. Mitigation: H6, and cut fields when it fails.
The wrong constraint gets managed. A team protects review while decisions are the real limit. Mitigation: monthly constraint check from measured waits.
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.

15. Naming and clearance

SLICE stays the working name for pilots; the public name is decided after them. The expansion is now Strategic, Lightweight, Iterative, Constraint-aware, Evidence-driven.

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, marketed as guardrails for AI development.
The SLICE research team at LIRMM, Montpellier, working on AI-enabled software engineering.
"SliceOps", cited in an external review as a decision-first AI framework, could not be found; the only match is an academic paper on ML operations in 6G network slicing. It is not cited until a source exists.

Before public launch: EUIPO and USPTO searches in classes 9, 41 and 42, domain checks, and a check of open-source projects. A web search cannot establish legal availability.