The SliceOps framework
Twelve canonical principles, one atomic unit of work, and an audit plane enforced in CI. Here is how it fits together.
The canonical model
Work is organized into three structural levels, plus one view computed from the dependency graph.
A logical grouping of slices with coherent scope. It closes with a retrospective and calibrates velocity afterward — not a sprint, epic, or milestone.
A functional domain inside a block — the SEC segment of a slice's identifier. Stable across blocks: domain is structural, not temporal.
The atomic, vertical, end-to-end unit of work: one agent chat, one PR, one cohesive outcome. Not a story, ticket, or task.
A computed view of the dependency graph — which slices are mergeable now. Derived, never committed to in a ceremony. Not a sprint or phase.
BL-XX.SEC-XX.SL-XXXEvery slice carries this identifier through its branch, commits, PR title, and decision records — the provenance thread that ties the whole system together.
Anatomy of a slice
A slice is the smallest unit that is independent, testable, and useful — and it carries its whole outcome with it.
Mergeable without breaking what exists. One architectural concern only — if it spans more, split it.
Validated by at least one test before it can merge.
Adds incremental value, not refactoring for its own sake.
Scope · decision · code · tests · evidence · merge — one chat, one PR.
Sized in tokens, not story points
Slices are sized by expected token consumption — deterministic and cross-model, unlike team-relative estimates. Recommended defaults:
Evidence by construction
Every slice produces evidence in four mandatory categories, plus a security gate. Un-evidenced slices do not merge.
Tests pass.
Linters and metrics — coverage, format, complexity.
Decision Records and insight records.
Slice ID, agent, timestamps, commit SHA.
Security is its own per-slice gate: secrets scan, SAST, dependency and supply-chain checks — not a periodic audit.
The audit plane: Decision Records
No code-quality tool, runtime monitor, or compliance platform audits the decision plane — what was decided, by whom, why, and with what supersession chain. That layer is the SliceOps wedge.
- 01Every architectural decision is a Decision Record with frontmatter that maps to a cognitive entity model agents can reason over.
- 02Records are append-only — never deleted, never silently rewritten. Supersession is a bidirectional, acyclic edge: the new record declares what it replaces, the old one points forward.
- 03Each record traces back to the slice that produced it and stays reachable from it.
- 04CI rejects any PR that breaks the schema, orphans a decision, or leaves a supersession chain inconsistent.
proposed → accepted → superseded / deprecatedStage as a DAG-derived view
Slices declare their dependencies with explicit edges. A Stage is computed by traversing that graph — Stage N is whatever is unblocked at step N. Parallelism falls out of the topology, not out of a planning meeting. Forecasting and retrospectives happen at the block level; there are no burndown charts and no “we committed to N slices this sprint.”
Fourteen merge gates
The canonical R-rules (R1–R14) are hard CI gates — each one traces back to a principle. Adopters add their own from R15 onward.
Three wedges
The architectural-decision layer no existing tool audits.
DAG-driven — five to thirteen simultaneous agents as a normal operating mode.
Every artifact is structured so the next agent can learn from it.
The 12 canonical principles
Remove any one and the result is no longer SliceOps. They hold across any runtime, any language, any team size.