The standard, on-site

The Spec

The normative text of the SliceOps framework specification, v1.1.0: the 12 canonical principles and the canonical glossary. This page hosts the exact files from the spec repository, byte-synced in CI, so sliceops.org is the standard itself, not a brochure about it.

Rendered verbatim: the only transformation is splitting on section headings for navigation. If this page and the repository ever differ by one byte, the build fails.

Source: spec/v1.1.0 on GitHub

# SliceOps™ Canonical Principles (Layer A) — v1.1.0

SliceOps™ is a **decision-driven framework** constituted by **12 canonical principles (Layer A)**. Without any one of them, the result **is not SliceOps**.

They are presented **Why → How → What**: *why* probabilistic, agentic construction needs disciplined control (**P1–P3**), *how* you build under that discipline (**P4–P10**), and *what* the discipline makes tangible, bound to no vendor (**P11–P12**). **Decision-first**: architecture, specs, plans, and execution are *consequences* of foundations and decisions — never the reverse. Each principle is defined with a statement, rationale, implication, and anti-pattern.

These principles are **non-negotiable**: an implementation that violates any one is not SliceOps-compliant. Amendments to this set require a superseding decision under an elevated human-in-the-loop gate (P3).

Gamification (slice-count badges, streaks, leaderboards, motivation mechanics) is explicitly **out of scope** — the asymmetric risk via Goodhart's law, cobra effect, and quality erosion outweighs the benefit. SliceOps takes no position on gamification at any layer.

---

*Probabilistic, agentic construction needs deterministic, auditable control with human authority — so that AI leverage never costs correctness, accountability, or trust. These three principles are the reason the rest exists.*

---

**Statement**: Decisions emerge from slices. Every DEC traces to a slice (where it was produced) and is reachable from that slice (back-link). Decisions made out-of-band must be backed into a slice retroactively.

**Rationale**: Out-of-band decisions accumulate as tribal knowledge — chat DMs, the founder's head. Six months later nobody knows why X. SliceOps eliminates tribal knowledge by requiring every decision to live in the corpus tied to the slice that produced it. The slice is the unit of work AND the unit of provenance. Without P1, tribal knowledge re-emerges and the audit plane is theater.

**Implication**:
- DEC frontmatter includes slice provenance (`originating_slice:` in the canonical Block-Section-Slice ID format)
- Slice PRs include the DEC list produced
- Retroactive DECs allowed but require a "back-fill slice" with an explicit retro-decision flag
- Architecture-spanning decisions get their own slice (no decision is "free" of slice provenance)

**Anti-pattern**:
- DECs created without slice context
- "We decided this in a meeting" — re-record as a slice
- Decisions in a chat backlog never committed to the corpus
- DECs that supersede priors without explaining what changed in context

**Clarification (decisions emerge from sessions)**: P1's statement is generalized — the **slice** is the DEV Session-Type, but Meta/Audit/Learning sessions also produce decisions with provenance. A governance session that ratifies many DECs without producing a single PR is still anchored by an originating session. The `originating_slice:` field on a DEC therefore reads as **originating session** in the general case (the slice ID being a special case for DEV sessions). This closes the audit-plane hole for governance decisions. See entity catalog entry for Session (#13).

---

**Statement**: Every architectural decision is recorded, traceable, and cross-slice consistent. The audit plane is the layer above code where decisions live as first-class artifacts.

**Rationale**: Code-quality tools audit code. Runtime tools audit behavior. Compliance tools audit post-hoc. **No existing tool audits the decision plane** — what was decided, by whom (human/agent), why, when, with which alternatives considered, with what supersession chain. This layer **is** the SliceOps wedge. Without P2, SliceOps is just another collection of CI rules.

**Implication**:
- DecisionRecord schema mandatory (Layer B catalog)
- DECs date-based or counter-based, with a uniqueness check enforced in CI
- DEC content: context, alternatives considered, rationale, consequences, supersession chain
- Cross-slice DEC consistency check enforced in CI
- Counter discipline pattern (atomic increment per prefix, validate-no-duplicate)
- DECs append-only; supersession explicit, never silent

**Anti-pattern**:
- Decisions in chat/email/meetings without a subsequent DEC
- DECs created post-hoc to justify already-merged code
- DECs contradicting prior DECs without explicit supersession
- DECs without alternatives considered (false-binary thinking)

---

**Statement**: Humans retain final authority over scope, merges, and architectural direction. AI agents propose; humans dispose. Critical decisions (Block-scope DECs, R-rule amendments, repo-level changes) require a human approval gate. Routine slices may auto-approve based on policy and evidence, but an escape hatch to a human always exists.

**Rationale**: AI agents make confident-sounding wrong decisions. Without HITL, errors compound into the corpus, producing poisoned training data, and future agents inherit the poison (P8 backfires without HITL). Regulatory: EU AI Act Article 14 mandates human oversight for high-risk systems. Reputational: AI-only orgs lose trust fast. SliceOps explicitly preserves human authority while maximizing AI leverage.

**Implication**:
- Merge gate is human approval (CODEOWNERS or equivalent)
- Critical DECs require explicit human ratification (≠ auto-merged)
- The DEC schema records the ratifying human in `approver` (recommended on `status: ratified`). In projects with more than one maintainer, `approver` MUST differ from `owner`. Single-maintainer projects MUST record self-ratification explicitly (`approver` == `owner`) — a disclosed limitation, consistent with DISCLOSURE.md, not a silent one.
- Block-scope decisions (what enters/exits) are human authority
- R-rule amendments require human DEC ratification
- AI-generated content disclosed (EU AI Act Art. 50): content, code, decisions
- Provenance metadata distinguishes human-authored vs agent-authored

**Anti-pattern**:
- Auto-merge on green CI without human review in critical scope
- AI agents amending R-rules without a human DEC
- AI agents closing Blocks without a retrospective
- Hidden AI-generated content (no provenance, no disclosure)
- "Agentic auto-merge" for L or XL slices (size disproportionate to human-review risk)

---

*The construction mechanisms that deliver the WHY: atomic units, derived planning, evidence and security by construction, recursive learning, shared-resource pre-flight, and infrastructure continuity.*

---

**Statement**: One chat = one PR = one atomic vertical slice. A slice carries one outcome end-to-end: spec, decision, code, tests, evidence, merge.

**Rationale**: Atomic units of work are a prerequisite for parallelization, audit, and recursive learning (P8). Without atomicity, scope drifts, decisions smear across multiple PRs, evidence fragments, post-hoc reconstruction is impossible. AI agents specifically benefit from bounded scope: a chat session has finite context window, finite attention budget, finite reasoning depth. Atomicity matches the capability envelope of the agent.

**Implication**:
- Slices declare scope upfront (spec block in PR description or DEC)
- Token-band sizing recommended (XS/S/M/L/XL Tk) tied to the capability envelope
- DAG dependencies explicit (`depends_on`)
- Branch naming aligned with slice ID
- Slice ID is the provenance carrier in every artifact produced
- A slice does NOT span multiple architectural concerns; if it must, split it

**Anti-pattern**:
- Catch-all PRs ("misc fixes")
- Slices that grow >2× forecast without a retrospective
- Slices touching unrelated concerns (DI, business logic, DB migration, and UI)
- Slices without explicit scope declaration

**Clarification (slice ⊂ session)**: P4's statement is preserved as-is **for the DEV Session-Type** — the slice IS the DEV Session-Type, the one that produces a PR. Other Session-Types (Meta, Audit, Learning, Support, Infra, Artifact, Orchestrate) are valid AI interactions that do not produce a PR (governance decisions, blameless verification, exploration, incident care, infra ops). **Every slice is a session; not every session is a slice.** P4 governs the atomicity of DEV slices; it is not violated by non-DEV sessions. See `../../reference/sessions/` for the Session-Type taxonomy.

**Sizing**: token-band measures throughput (billed-equivalent); **context-band** measures peak context footprint (orthogonal). Both are calibrated, not axiomatic — see `../../reference/sizing/`.

---

**Statement**: A Stage is a computed view of the slice dependency graph, **not** an imperative time-bound grouping. Slices belong to Blocks (logical scope) and depend on each other; Stage = "what is mergeable now given dependencies."

**Rationale**: Sprint-based models assume fixed cadence, predicted velocity, and commitment per sprint. AI-first SDLC has variable velocity per slice (size unknown until decomposed), opportunistic parallelism (depends on DAG topology), and emerging dependencies (discovered during slice execution). Stage-as-DAG-view aligns the planning model to reality: Stage N includes whatever slices are unblocked at time N. This is the most novel SliceOps concept relative to existing SDLC frameworks.

**Implication**:
- DAG explicit in slice metadata (`depends_on`)
- Stage computed by graph traversal, not assigned imperatively
- Forecasting at Block level (which Block costs M tokens), not Stage level
- Retrospectives close a Block, not a Sprint
- Velocity calibrated post-hoc per Block, applied forward as an adjustment

**Anti-pattern**:
- Sprint-based commitment with fixed scope
- Slices assigned to "Sprint 1" / "Sprint 2" without DAG analysis
- Burndown charts (Sprint artifact, not Block artifact)
- "We committed to N slices this stage" — Stage is derived, not committed

---

**Statement**: Every slice produces evidence in **4 mandatory categories**: functional (tests pass), quality (linters/metrics), decision (DECs and InsightRecords), provenance (slice ID, agent, timestamps, commit SHA). Evidence is non-negotiable; un-evidenced slices do not merge.

**Rationale**: Compliance frameworks (ISO 42001, SOC 2, EU AI Act) treat evidence as a periodic burden — collect quarterly, audit annually. SliceOps treats evidence as a per-slice byproduct: if you finished the slice, you have the evidence. Audit becomes trivial: select a date range, filter slices, evidence is present by construction. AI-generated code specifically requires robust evidence because its failure modes are subtle (hallucinated APIs, invalid schemas, drift between runs).

**Implication**:
- Each tech stack defines its test taxonomy (unit/integration/regression/e2e as relevant)
- Hard CI gates: test pass, coverage threshold, lint pass, format check
- AI-specific evidence: hallucination tests (outputs don't invent APIs/imports/types), drift tests (same input → same output), eval suites for agentic outputs
- Provenance metadata mandatory: slice ID, originating chat, agent attribution, commit SHA, timestamps
- Coverage threshold per slice (not just project-wide average)

**Anti-pattern**:
- Tests added in a "follow-up slice" — block merge or fix retroactively
- Coverage skipped for a "small slice" — all slices evidenced regardless of size
- Manual QA only — not evidenced; testing must be CI-enforced
- "We'll add tests later" — never happens; merge with tests or don't merge

---

**Statement**: Security is a per-slice gate, not a periodic audit. Every slice passes security validation before merge: SAST, secrets scan, dependency vulnerability check, SBOM update, supply-chain provenance attestation.

**Rationale**: AI-generated code introduces specific vectors that traditional security gates miss: (a) hallucinated dependencies leading to typosquat attacks via packages the model invents; (b) prompt injection in outputs surfaced to other agents; (c) secrets leakage in agent-generated logs/DECs; (d) supply chain via inflated context windows. Compliance requires a security baseline. Without P7, the compliance wedge is theater and adopters face real attack vectors invisible to status-quo gates.

**Implication**:
- Hard CI gates per slice: SAST, secrets scan, dependency vulnerabilities
- SBOM generated per slice, accumulated at Block level
- Supply-chain provenance attestation for every merged artifact
- AI-specific gates: hallucinated-dependency check (imports vs known-good registry), prompt-injection regression suite, output schema validation
- Secrets policy: never in DECs, InsightRecords, slices, branches, commit messages — enforced by scanning

**Anti-pattern**:
- Quarterly security review without per-slice gates
- Security as "the security team's job" — security is a per-slice concern
- Trusting AI-generated dependency manifests without validation
- Secrets in committed env files (any LLM "helpfully" attempts this)

---

**Statement**: The framework improves itself through capture. Every slice produces InsightRecords (empirical observations); patterns appearing ≥3 times become LearningPatterns; LearningPatterns inform R-rule amendments via DECs; R-rule amendments apply forward to subsequent slices. **The corpus is the training data.**

**Rationale**: ADRs are static — decided once, recorded, archived. Static methodologies have no first-class learning loop. Black-box trajectory replay learns for the vendor, not the adopter. SliceOps is recursive: adopters' own corpora improve their own frameworks. InsightRecords → LearningPatterns → R-rules → DECs → updated corpus. This is probably the principle **most differentiated** from existing approaches.

**Granularity clarification** (does not change the statement): the ≥3 threshold applies to **LearningPattern promotion** (framework-level, deliberate). A complementary finer granularity exists — **artifact-level tuning**: whenever an artifact (reference file / script / template / skill) does not behave as expected, ask "one-off adjustment or permanent?"; if permanent, update the artifact immediately (do not wait for ≥3).

**Implication**:
- InsightRecord schema (Layer B catalog) captures cross-slice empirical observations
- LearningPattern schema captures recurring patterns (threshold ≥3 observations)
- R-rule amendments require DECs referencing LearningPatterns as evidence
- Block Retrospective mandatory sections: "forward forecast adjustments" and "captured insights"
- Postmortem schema for negative outcomes (blameless)
- Public corpora compound: adopters publishing InsightRecords contribute to ecosystem-wide learning

**Anti-pattern**:
- Retrospectives that produce no InsightRecords
- InsightRecords that sit unused (must feed back to R-rules or DECs)
- R-rules amended without LearningPattern evidence
- Postmortems that name names instead of patterns (blameless-culture violation)

---

**Statement**: Before scaling any parallelism lever beyond the baseline calibrated in the last Block Retrospective, enumerate, cap, alert, and telemeter every finite/serialized shared resource that lever consumes. SliceOps's parallel throughput stresses shared resources the framework must protect **proactively** — protection is bootstrap, not reaction.

**Rationale**: Multi-agent parallelism is **constitutive** of SliceOps (Wedge B) — no other SDLC runs 5–13 simultaneous agents as its normal mode. So this failure mode (parallelism stresses an un-enumerated finite/serialized shared resource) is **more intrinsic to SliceOps than to any existing framework**. Operating theorem: *"the success of a parallelism lever is the source of the next bottleneck."* Observed in reference-implementation practice ≥3 times (serialized-counter contention, shared worktree/checkout state, CI-minute exhaustion — same family as API rate limits, branch-protection serialization, DB migration locks). Without systematic pre-flight, the primary wedge silently self-destructs (invisible hard-stop).

**Implication**:
- Pre-Block checklist: enumerate finite/serialized shared resources the Block consumes (CI minutes, counters, API rate limits, branch-protection serialization, DB migration locks, worktree/checkout state, connection pools)
- Each resource: **cap** (hard limit), **alert** (warns BEFORE the limit, not at it), and **telemetry** (continuous visibility)
- Trigger: crossing the baseline calibrated in the last Block Retrospective (tied to P5 and velocity recalibration — NOT a fixed magic number)
- Default for any shared resource = cap and alert, **never silent hard-stop** ("announced degradation" > "invisible hard cutoff")
- Cost-ledger extended to an infra/CI dimension (not just tokens) — Layer B.1
- Guardrails as repo-scaffold bootstrap defaults, NOT post-incident retrofit

**Anti-pattern**:
- A `$0` spending limit / default quota that turns "exhaust resource" into "invisible hard cutoff"
- A cost-ledger that tracks only tokens (infra-cost blindness)
- Scaling parallelism without enumerating the shared resources it consumes
- Guardrails patched post-incident instead of bootstrap defaults
- Treating CI minutes / counters / rate limits / locks as infinite
- Docs/orchestration PRs burning the same finite budget as heavy code PRs without change-gating

**Why P9 ≠ P10**: P10 (Infrastructure Continuity) = "infra changes are slices (atomicity applied to infra)." P9 = "before scaling parallelism, protect the finite shared resources it consumes." An adopter can honor P10 perfectly (migrations as slices) and still exhaust CI minutes by never enumerating that resource. Orthogonal.

---

**Statement**: Code, infrastructure-as-code, database schemas, and environment configuration form one continuum. SliceOps discipline applies uniformly across them: atomic slice, DEC trail, evidence-by-construction, security gates, HITL authority. Infrastructure is not a separate domain.

**Rationale**: Many SDLC frameworks bifurcate code vs infrastructure (a separate ops workflow, separate review, separate tooling). AI-first SDLC **cannot bifurcate** — AI agents can and will modify Terraform, Pulumi, CloudFormation, k8s manifests, DB migrations, env configs. Without P10, infrastructure becomes a "shadow domain" where AI changes happen without slice discipline, leading to audit-plane gaps, then security gaps, then compliance gaps. SOC 2, ISO 27001, and banking-grade compliance require infrastructure change tracking equivalent to code. DB migrations are particularly risky (complex rollback, data-loss potential) — AI generating them without a DEC trail, rollback plan, and evidence is a critical failure vector for regulated ventures.

**Implication**:
- IaC changes are slices with the same atomicity and DEC trail
- DB migrations are slices with a mandatory rollback plan in the spec
- Environment-specific configs versioned; differences declared in a DEC
- Infrastructure DECs (cloud provider, DB type, region, runtime topology) follow P2/P1 like any other DEC
- Multi-environment testing for deploy slices (dev → staging → prod evidence chain)
- Secrets/credentials handled per environment with P7 discipline
- AI-generated IaC requires a human review gate per P3

**Anti-pattern**:
- "Ops team handles infra" — separate workflow from slice discipline
- DB migrations without a DEC and without a rollback plan
- Production hotfixes without slice provenance
- Cross-environment config drift unreviewed
- AI-generated IaC merged without human review (also violates P3)
- Database schema changes that are not slices
- Infrastructure as a "shadow domain" outside the audit plane

---

*The construction discipline materialized: the principles (Layer A), the reference patterns and artifacts (Layer B.1), the toolkit (Layer B.2), and a governed, single-source context substrate (P12 Context Discipline — agents are memoryless, so the corpus is their context; canonical vocabulary is one facet) — platform-agnostic (P11), bound to no AI, model, or runtime. The runtime that executes the discipline is Layer C — a vendor runtime built on these principles, not SliceOps's What.*

---

**Statement**: SliceOps runs on any text-based AI agent, git, atomic-slice scoping, and file-producing capability. Specific platforms add velocity and UX but are NOT a gate of entry. SliceOps is not locked to any vendor.

**Rationale**: Vendor lock-in kills adoption. Frameworks tied to a single tool limit ecosystem growth. The SliceOps wedge **is** the framework, which must run anywhere. Specific platforms unlock additional capability (multi-chat unlocks the parallelism wedge, knowledge-graph integration unlocks substrate features) but adopters get base value (Audit Plane, Decision Integrity) with no specific tool.

**Implication**:
- **Mode S** (single-agent, sequential) and **Mode M** (multi-agent, parallel) — both produce full audit-plane evidence
- Mode M unlocks Wedge B (parallelism); Mode S unlocks Wedge A (audit) without Wedge B
- Minimum declared prerequisites: text-based AI agent, git, file system, atomic-slice scoping capability
- Capability matrix per platform (Layer B pattern): which platforms unlock which features
- **A reference runtime is one runtime, not the runtime.** Substrate options (third-party tool adapters, custom homegrown brains) are valid and are architectural peers

**Anti-pattern**:
- Claiming SliceOps requires a specific AI coding tool
- Documentation assuming specific platform features (e.g., "open a chat" assuming multi-chat exists)
- Tooling that only works with specific platforms
- License terms requiring a specific runtime

---

> Reframed from **"Vocabulary Discipline"**: vocabulary discipline is preserved as **one facet**. The number is unchanged; the scope is widened.

**Statement**: AI agents are memoryless across sessions; the corpus IS their persistent, shared context. Context is therefore engineered as a **single source of truth** — foundations, decisions, architecture, specs, and plans form **one governed substrate** — enriched yet **selectively routed**, so that multiple agents operate coherently within finite windows. Duplicated or drifted context is corruption. **Canonical vocabulary is one facet**: canonical terms have canonical meanings; synonyms drift, SliceOps does not.

**Rationale**: In a classical SDLC, context lives in humans' heads; in AI-first, agents are **memoryless** — the corpus is their only shared memory. Context therefore stops being implicit and becomes a **first-class engineering artifact** — the most AI-native principle (no classical SDLC needs it). Three pressures make it constitutive: (a) **source of truth** — without a single source the corpus turns to junk and adopters cannot interoperate (the vocabulary facet; the ecosystem-compounding effect is adopters speaking one language); (b) **finite windows** — un-routed context blows the context-band (P4) and inflates cost (P9); (c) **multi-agent coherence** — N agents without a shared source diverge. The failure mode is **empirical, not theoretical**: denormalized-reference drift (duplicated counts/refs drift when the source changes) and cross-coordinator collision are this principle predicting its own failure. It is silent corruption of the audit plane (P2): auditing decisions requires consistent term and context semantics.

**Implication**:
- **Single source of truth per fact**: each datum (term, count, reference, decision) lives in ONE place; every other locus derives from or points to it, never copies (anti-denormalization).
- **Foundations-first governed substrate**: foundations → decisions → architecture → specs → plan → execution IS the context architecture (how context is organized to be single-source and routable).
- **Declared selective routing**: each slice loads the relevant context-experts (by topic/dependency), not the whole corpus (Context Router, Layer B.1); the routing is declared in the slice scope.
- **Vocabulary canon (facet)**: canonical glossary + topic taxonomy (`glossary.md`); a DEC is required to add/rename/retire a canonical term; fix-on-touch for drift.
- **Cross-agent coherence enforced**: Consistency Management + cross-coordinator pre-flight (ties to P9) + linters/validators (term-linter, validate-topic-tags, validate-principle-count-coherence — Layer B.2).
- Adopters extend with domain-specific context; SliceOps core terms and structure are reserved.

**Anti-pattern**:
- Context **assumed/implicit** rather than authored (the root AI-first anti-pattern).
- **Denormalized** counts/refs/terms duplicated across N loci that drift.
- Loading the **whole corpus** into every agent (no routing → context bloat → finite-window failure and cost; anti-P4/P9).
- N agents operating **without a shared source of truth**.
- "Slice", "story", and "ticket" used interchangeably; "DEC" and "ADR" as synonyms; new terms without a DEC; non-canonical terms in published content (the vocabulary facet).

**Why vocabulary is a facet, not a separate principle**: vocabulary-canonicity, single-source, routing, and coherence are the same discipline — context as a governed substrate. The core is **binary/auditable**: is single-source declared? is denormalized-drift zero? is context routing declared per slice? The **optimal density** of context is calibration (Context Router / Model Triage — Layer B.1), not part of the binary gate.

---

This set evolves only via a superseding DEC under an elevated HITL gate (P3), with explicit cross-reference impact analysis. The derivation history of these principles is itself corpus produced by the framework operating on itself (P1 and P8) — a recursive demonstration, at a cadence of roughly one principle per intensive operating period, which is a maturity signal, not instability.

# SliceOps™ Canonical Glossary — v1.1.0

Canonical glossary of SliceOps terms. Each term here has a **canonical meaning** (per P12 Context Discipline, vocabulary facet). Terms not listed here are not canonical SliceOps; adopters may extend with domain-specific terms in their own glossaries (extend, never redefine).

**Living document**: new terms emerge via decisions with non-empty `vocabulary-changes`; updates are part of the slice that produces the decision. Major restructure leads to a version bump.

**Per-term structure**: Definition · Origin (principle/concept that canonicalizes it) · Aliases prohibited · Cross-references.

---

### Adopter
- **Definition**: An organization or product that uses the SliceOps framework to develop software or a knowledge corpus. Distinct from a vendor: adopters consume SliceOps; vendors provide runtimes (Layer C.1).
- **Origin**: IP boundary (three-layer)
- **Aliases prohibited**: "customer" (commercial), "user" (ambiguous), "implementer" (overloaded)
- **Cross-references**: Vendor, Layer C.1, Layer C.2

### Acceptance-first slice
- **Definition**: SliceOps's preferred (convention, not mandate) slice-authoring style: each slice declares its **acceptance criteria upfront** — ideally as executable acceptance tests — that simultaneously serve as a **spec-anchor** (P4 scope) and **evidence-gate** (P6 closure). A single artifact bridges the start and the end of the slice. Pairs well with Determinism-over-Regeneration (acceptance tests are deterministic).
- **Origin**: SliceOps development model (Decision 3 — preferred convention)
- **Cross-references**: P4, P6, P8, Determinism-over-Regeneration, Decision-driven, spec-anchored

### Anti-pattern
- **Definition**: A practice explicitly prohibited under SliceOps discipline. Each principle declares anti-patterns; CI gates enforce.
- **Origin**: Layer A principles
- **Cross-references**: Principle, R-rules

### Audit plane
- **Definition**: The layer above code where architectural decisions live as first-class artifacts (DECs). Empty market space pre-SliceOps; the framework's primary wedge.
- **Origin**: P2
- **Aliases prohibited**: "decision log", "ADR system" (DECs are evolved ADRs, not equivalent)
- **Cross-references**: P2, DecisionRecord, Decision Integrity

### Block
- **Definition**: A logical grouping of slices with coherent scope. Closes with a Block Retrospective. Velocity calibrated post-hoc per Block.
- **Origin**: P5
- **Aliases prohibited**: "sprint" (commits velocity ahead, violates P5), "epic" (issue-tracker-flavored), "milestone" (time-based vs scope-based)
- **Cross-references**: Slice, Stage, Block Retrospective

### Block Retrospective
- **Definition**: Mandatory ritual at Block close. Includes velocity recalibration, a Cross-DEC Consistency Check section, and InsightRecord harvesting.
- **Origin**: P5, P8
- **Cross-references**: Block, Velocity, Consistency check

### Brain pack injection
- **Definition**: A mechanism that injects relevant context at the start of each slice (including applicable Layer C.2 stack patterns for the repo in scope).
- **Origin**: Layer C.2 stack-patterns
- **Cross-references**: Layer C.2, Stack pattern, ContextPack

### Layer A — Principles
- **Definition**: Top-level taxonomy layer. The 12 canonical principles (P1–P12) that constitute the SliceOps framework. Immutable except by superseding DEC under an elevated HITL gate.
- **Origin**: Canonical principles
- **Cross-references**: Principle, P1–P12

### Layer B — Reference Patterns
- **Definition**: Top-level taxonomy layer. Reference patterns that materialize the principles. SliceOps IP. Has sub-layers (B.1 Framework Artifacts, B.2 Universal Engineering Patterns).
- **Origin**: IP boundary and hierarchical taxonomy
- **Aliases prohibited**: bare "Layer B" without sub-letter is ambiguous in technical context — always specify B.1 or B.2 when relevant
- **Cross-references**: Layer B.1, Layer B.2

### Layer B.1 — Framework Artifacts
- **Definition**: Sub-layer of Layer B. SliceOps-originated patterns: entity catalog (13 cognitive entities), repo folder structure, R-rules system, counter discipline, frontmatter schemas, file templates, vocabulary discipline mechanism.
- **Origin**: Hierarchical taxonomy
- **Cross-references**: Cognitive entity, Folder structure, R-rules

### Layer B.2 — Universal Engineering Patterns
- **Definition**: Sub-layer of Layer B. Industry-canonical engineering patterns SliceOps reaffirms: SOLID, ACID, Outbox, Fail-Fast, Idempotency, Defense in Depth, CI/Pipeline Cost Economy, Determinism-over-Regeneration. Vendor-agnostic, stack-agnostic.
- **Origin**: Stack-patterns and hierarchical taxonomy
- **Cross-references**: SOLID, ACID, Outbox, Idempotency, CI/Pipeline Cost Economy, Determinism-over-Regeneration

### Layer C — Implementations
- **Definition**: Top-level taxonomy layer. Specific implementations, not canonical SliceOps. Has sub-layers (C.1 Vendor Runtimes, C.2 Adopter Stack Patterns).
- **Origin**: IP boundary and hierarchical taxonomy
- **Aliases prohibited**: bare "Layer C" without sub-letter is ambiguous — specify C.1 or C.2
- **Cross-references**: Layer C.1, Layer C.2

### Layer C.1 — Vendor Runtimes
- **Definition**: Sub-layer of Layer C. Vendor-owned runtime products implementing the SliceOps Layer B catalog — e.g., hosted knowledge-graph products, third-party tool adapters, custom homegrown brains. A reference runtime is one runtime, not the runtime (P11).
- **Origin**: IP boundary and hierarchical taxonomy
- **Cross-references**: Vendor, Adapter, P11

### Layer C.2 — Adopter Stack Patterns
- **Definition**: Sub-layer of Layer C. Adopter-defined patterns instantiable per technology stack — e.g., Repository pattern (.NET), FluentValidation, Riverpod state management (Flutter). Each adopter defines its own Layer C.2 with enforcement tooling (analyzers / lint rules / CI gates).
- **Origin**: Stack-patterns and hierarchical taxonomy
- **Cross-references**: Adopter, Stack pattern, Brain pack injection

### Capability
- **Definition**: Cognitive entity #4 in the Layer B.1 catalog. Capabilities accrued by individuals/agents/teams. **Renamed from "Skill"** ("capabilities accrued" describes Capability, not Skill; the rename improves precision and frees the term "Skill").
- **Origin**: Catalog split (entity #4) and Determinism-over-Regeneration (rename)
- **Aliases prohibited**: "Skill" (former name, now reserved for a distinct concept — do NOT use for this entity)
- **Cross-references**: Cognitive entity, Layer B.1, P8, Skill (reserved — distinct concept)

### CI/Pipeline Cost Economy
- **Definition**: A Layer B.2 Universal Engineering Pattern. Five stack-agnostic levers for pipeline economy: concurrency-cancel-in-progress, change-scoped job gating, aggregation-required-gate, draft-skip of expensive jobs, and dependency-cache. Materializes P9 in the CI domain. The concrete per-CI-provider/stack instance is Layer C.2.
- **Origin**: Shared-Resource Pre-flight (P9)
- **Aliases prohibited**: "CI optimization" (generic), "pipeline tuning" (under-specified)
- **Cross-references**: P9, Layer B.2, aggregation-required-gate, Outbox (sibling B.2)

### aggregation-required-gate
- **Definition**: A CI design pattern within CI/Pipeline Cost Economy (B.2). An `if: always()` job that is THE required check, resolving the "required check skipped, so PR blocked forever" trap introduced by change-scoped job gating. Mandatory when path-gating is used.
- **Origin**: Shared-Resource Pre-flight (P9)
- **Cross-references**: CI/Pipeline Cost Economy, change-scoped job gating

### Cognitive entity
- **Definition**: One of the 13 canonical entity types of SliceOps Layer B.1 (DecisionRecord, InsightRecord, OutcomeRecord, Capability, Goal, LearningPattern, CognitiveFramework, ContextPack, ActivePriority, RelationshipContext, Preference, Value, **Session**). Each has a frontmatter schema and lifecycle.
- **Origin**: Catalog split and Session as first-class unit
- **Aliases prohibited**: "entity type" (ambiguous with database entities), "metadata record" (under-specified)
- **Cross-references**: Layer B.1, Entity catalog, DecisionRecord, InsightRecord, Session

### CognitiveFramework
- **Definition**: Cognitive entity. A mental model or reference structure for reasoning and decision-making (e.g., this glossary, the topic taxonomy).
- **Origin**: Catalog split
- **Cross-references**: Cognitive entity

### consistency-check (frontmatter field)
- **Definition**: Mandatory DEC frontmatter field (Layer 1). A multi-line paragraph declaring how the DEC relates to the existing corpus.
- **Origin**: Consistency-management mechanism
- **Cross-references**: Layer 1, Frontmatter discipline, conflicts-with

### conflicts-with (frontmatter field)
- **Definition**: Mandatory DEC frontmatter field. Lists DEC IDs that could appear to contradict, and a resolution paragraph in the body if non-empty.
- **Origin**: Consistency-management mechanism
- **Cross-references**: Layer 1, consistency-check

### ContextPack
- **Definition**: Cognitive entity. A pre-computed bundle of context loaded at slice/session start. Enables P11 platform-agnosticism (bundles portable cross-tools). **Evolves from static to routed/dynamic** per the Context Router (selection of relevant context-experts by topic/dependency at session start, rather than loading the whole corpus).
- **Origin**: Catalog split and Context Router
- **Cross-references**: Brain pack injection, P11, Context Router, context-expert

### Calibration discipline
- **Definition**: The discipline of deriving the sizing bands (token-band, context-band) from **real data and the vigent model landscape**, NOT axiomatically. Reproducible (a versioned deterministic script parses real session corpus → percentiles → bands), quarterly cadence (hooks into the Quarterly Curation Ritual — Layer 6), and versioned (each calibration records date, script-version, dataset, model landscape, and resulting bands so band drift is auditable over time).
- **Origin**: Bidimensional sizing and Calibration discipline
- **Aliases prohibited**: "ad-hoc calibration" (anti-pattern: not reproducible, not versioned), "axiomatic bands" (rejected)
- **Cross-references**: Token-band, context-band, Model Triage, model landscape, Quarterly Curation, Determinism-over-Regeneration

### Counter discipline
- **Definition**: Layer B.1 pattern. Atomic increment per prefix and a validate-no-duplicate CI check. Prevents counter collision in multi-coordinator parallel work. Originated as empirical practice in reference-implementation context; canonicalized in SliceOps.
- **Origin**: IP boundary (canonicalized)
- **Cross-references**: R-rules, P9, DEC numbering

### DAG (Directed Acyclic Graph)
- **Definition**: The slice dependency graph. Slices have explicit `depends_on:` edges. Stage is a view derived from the DAG (P5).
- **Origin**: P5
- **Cross-references**: P5, Stage, Slice

### DEC (DecisionRecord)
- **Definition**: Cognitive entity. An architectural/strategic decision recorded with lifecycle (proposed → accepted → superseded/deprecated), supersession edges, alternatives considered, consequences. Naming: `DR-YYYY-MM-DD-slug.md` (date-based) or `DEC-NNN-slug.md` (counter-based, per repo convention).
- **Origin**: Catalog split; P2/P1
- **Aliases prohibited**: "ADR" (predecessor, DECs are evolved), "decision doc", "note"
- **Cross-references**: ADR, P2, P1

### Decision Integrity by Construction
- **Definition**: P1. Decisions emerge from slices; every DEC traces to a slice (provenance). Out-of-band decisions must be backed into a slice retroactively.
- **Origin**: P1
- **Cross-references**: P1, Slice provenance, Originating slice

### Decision-driven (development model)
- **Definition**: SliceOps's canonical development model: **decision-driven and evidence-gated**, with **spec-anchoring** per slice. The driver and wedge is the audit/decision plane (P2), NOT the spec. Distinct from spec-driven-first (where the spec is the source of truth, immutable, and divergence is a bug): in SliceOps the source of truth is the corpus of decisions and merged code with evidence; the spec evolves and the decision-of-why-it-changed is itself the valuable artifact (P8).
- **Origin**: SliceOps development model
- **Aliases prohibited**: "spec-driven" (incorrect characterization), "specless" (also incorrect — specs are anchors)
- **Cross-references**: P2, P1, P6, P8, spec-anchored, development-style-agnostic, Acceptance-first slice

### development-style-agnostic
- **Definition**: A characterization of SliceOps (analog to P11 Platform-Agnostic, applied to input/authoring style): SliceOps is a discipline plane that wraps any development input style — spec-first (e.g., Spec Kit), test-first, contract-first, sketch-first. Spec-driven adopters compose SliceOps on top; they don't compete with it. The 12 principles do not prescribe the input style — they prescribe the discipline plane.
- **Origin**: SliceOps development model
- **Cross-references**: P11 (analog), Decision-driven, spec-anchored

### Determinism-over-Regeneration
- **Definition**: A Layer B.2 Universal Engineering Pattern. If a process repeats, materialize it once as a deterministic reusable artifact (script, function, reference file, R-rule); do NOT stochastically regenerate it with AI each time. Deterministic code (same input → same result) is cheaper, faster, repeatable, and auditable vs AI output with drift. Rule: "if you can use code instead of AI, do; have AI write the code once, then reuse it."
- **Origin**: Determinism-over-Regeneration
- **Aliases prohibited**: "DRY for AI" (imprecise), "caching" (under-specified)
- **Cross-references**: Layer B.2, P6, P8, P9, CI/Pipeline Cost Economy (sibling B.2)

### one-off-vs-permanent tuning gate
- **Definition**: A P8 granularity clarification (does not change the statement). Artifact-level: whenever an artifact underperforms, ask "one-off adjustment or permanent?"; if permanent, update the artifact immediately (don't wait for ≥3). LearningPattern-level: a pattern observed ≥3 times leads to canonical promotion. Two complementary granularities.
- **Origin**: Determinism-over-Regeneration
- **Cross-references**: P8, LearningPattern, InsightRecord

### Evidence-by-Construction
- **Definition**: P6. Each slice produces evidence in 4 categories (functional, quality, decision, provenance) plus security (P7). Hard gates enforce; slices without complete evidence don't merge. Canonical record format: evidence.v1 (`reference/evidence/`).
- **Origin**: P6
- **Cross-references**: P6, P7, Evidence categories

### evidence.v1
- **Definition**: The canonical Layer B.1 evidence record format (JSON Schema draft 2020-12, `$id` `https://sliceops.org/schemas/evidence/evidence.v1.schema.json`). One machine-validatable record per slice merge (mandatory — P6 completeness is machine-enforced) or per gated operation (recommended). Carries the four P6 evidence categories plus the P7 security gate. Records carry no embedded signature — signing is a detached attestation over the artifact bundle containing them. Published in `reference/evidence/`.
- **Origin**: DR-2026-07-02-evidence-v1-canonical-schema
- **Cross-references**: P6, P7, Evidence-by-Construction, Layer B.1, OutcomeRecord

### Entity catalog
- **Definition**: The canonical set of 13 cognitive entity types of SliceOps Layer B.1. Each entity has a frontmatter schema, lifecycle, cross-reference patterns, and anti-patterns. Published in `reference/entity-catalog/`.
- **Origin**: Catalog split and Session as first-class unit
- **Cross-references**: Cognitive entity, Layer B.1, Session

### Finite/serialized shared resource
- **Definition**: A consumable or serialized resource, shared cross-slice/cross-coordinator, with a hard limit: CI minutes, counters, API rate limits, branch-protection serialization, DB migration locks, worktree/checkout state, connection pools. The resource class P9 mandates enumerating, capping, alerting, and telemetering before scaling parallelism.
- **Origin**: Shared-Resource Pre-flight (P9)
- **Aliases prohibited**: generic "shared resource" without "finite/serialized" (loses the key property)
- **Cross-references**: P9, infra-cost-ledger

### infra-cost-ledger
- **Definition**: A Layer B.1 extension of the cost-ledger. Tracks the infra/CI cost dimension alongside token cost. The pre-Block checklist verifies infra/CI budget headroom. Closes the "infra-cost blindness" failure (a token-only ledger).
- **Origin**: Shared-Resource Pre-flight (P9)
- **Cross-references**: P9, Layer B.1, cost-ledger, token-band

### Fix-on-touch
- **Definition**: A P12 Context Discipline policy (vocabulary facet). Any slice that detects vocabulary drift in a file it touches updates it forward (no separate cleanup slice).
- **Origin**: P12
- **Cross-references**: P12, Context discipline, Vocabulary discipline, Glossary

### Frontmatter discipline (Layer 1)
- **Definition**: The Layer 1 mandatory frontmatter spec for all DECs. Includes consistency-check, conflicts-with, topics, vocabulary-changes fields.
- **Origin**: Consistency-management mechanism
- **Cross-references**: Layer 1, consistency-check, conflicts-with

### Glossary
- **Definition**: This document. The canonical glossary of SliceOps terms. Living document; updated by every decision with non-empty `vocabulary-changes`.
- **Origin**: P12; consistency-management mechanism
- **Cross-references**: P12, Vocabulary discipline, Layer 1

### Hierarchical Layer Taxonomy
- **Definition**: The meta-decision on the naming structure of Layer A/B/C. Top-level Layer A/B/C are stable; sub-numbering (B.1, B.2, C.1, C.2) accommodates new dimensions without renaming.
- **Origin**: Hierarchical taxonomy
- **Cross-references**: Layer A/B/C, Scalability

### HITL (Human-In-The-Loop)
- **Definition**: P3. Humans retain final authority over scope, merges, architectural direction. AI agents propose; humans dispose.
- **Origin**: P3
- **Cross-references**: P3, Merge gate, CODEOWNERS

### Idempotency
- **Definition**: A Layer B.2 universal engineering pattern. The same operation invoked multiple times produces the same result. Implemented via Idempotency-Key headers, deduplication tables, etc.
- **Origin**: Stack-patterns
- **Cross-references**: Layer B.2, ACID, Defense in Depth

### Infrastructure Continuity
- **Definition**: P10. Code, IaC, DB schemas, env configs form one continuum. SliceOps discipline applies uniformly.
- **Origin**: P10
- **Cross-references**: P10, Stack pattern, IaC

### InsightRecord
- **Definition**: Cognitive entity. An empirical observation captured from a slice. Append-only. Raw material for LearningPatterns. Naming: `INS-NNN-slug.md`.
- **Origin**: Catalog split; P8
- **Cross-references**: P8, LearningPattern, Recursive Learning

### LLM-Inference-Cost-Economy
- **Definition**: A Layer B.2 **sub-domain pattern** specialized within CI/Pipeline Cost Economy. Applies when a CI/CD workflow calls a paid LLM API (audit, code-review, QA, codegen). Adds three genuinely-new levers (prompt-caching discipline, model-tier discipline, diff-only context windowing) and refines two parent levers (trigger-set minimalism LLM-aware, LLM-aware draft gate green-not-skipped). Extends the cost-ledger to a third dimension: LLM-API-in-CI cost (independent of token and infra dimensions).
- **Origin**: LLM-Inference-Cost-Economy
- **Aliases prohibited**: "LLM cost optimization" (generic), "CI LLM tuning" (under-specified)
- **Cross-references**: P9, Layer B.2, CI/Pipeline Cost Economy (parent), Determinism-over-Regeneration, model-tier discipline, prompt-caching discipline

### LearningPattern
- **Definition**: Cognitive entity. A pattern observed ≥3 times across InsightRecords; promoted as a canonical pattern. Naming: `LP-NNN-slug.md`. Triggers a DEC for R-rule amendments.
- **Origin**: Catalog split; P8
- **Cross-references**: P8, InsightRecord, R-rules

### Mode S / Mode M
- **Definition**: P11 operation modes. Mode S = single-agent sequential (one slice at a time, Wedge A only); Mode M = multi-agent parallel (N simultaneous slices with a coordinator, both wedges).
- **Origin**: P11
- **Cross-references**: P11, Wedge A, Wedge B, Coordinator

### Model Triage
- **Definition**: A Layer B.1 artifact. Routes each slice/session to a **(model and execution-mode)** recommendation according to five axes, in filter order: (1) **context-band** as primary filter — which models have a window ≥ footprint? (2) **sensitivity → locality** — can it leave to an external API or must it be local? (3) **complexity** — token-band and slice-type → reasoning tier. (4) **latency** — speed need. (5) **cost** — economic tier. Plus a **synthesis efficiency** axis with the consuming/producing distinction. Recommends; the human disposes (P3). The choice (`model_used`, `execution_mode`, `triage_rationale`) is recorded in Session provenance (P2 audit plane).
- **Origin**: Bidimensional sizing and Model Triage
- **Aliases prohibited**: "model selection" (under-specified), "routing" (ambiguous — distinct from Context Router)
- **Cross-references**: context-band, Token-band, Session, synthesis efficiency, P3, P9, execution-mode, model landscape

### model landscape
- **Definition**: A snapshot of the model classes / context windows available at the time of a calibration. Recalibration is triggered when the landscape changes materially (e.g., local models reaching mainstream 128K, frontier crossing 2M). Versioned as part of the Calibration discipline.
- **Origin**: Bidimensional sizing and Calibration discipline
- **Cross-references**: Model Triage, Calibration discipline, Quarterly Curation

### execution-mode
- **Definition**: How a slice/session is executed against a model: `frontier-API`, `local-via-API`, `account-with-plan` (fixed-cost subscription already paid), or `local-in-IDE`. A Model Triage axis tied to sensitivity → locality (P7) and cost (P9).
- **Origin**: Model Triage
- **Cross-references**: Model Triage, P7, P9

### Orchestrate
- **Definition**: A canonical Session-Type. A session that coordinates other sessions (does not produce direct work output). **Renamed from the abbreviated "COORD"** — the convention is full words, not opaque abbreviations (P12). Examples: a coordinator session managing parallel slice execution, a meta-session orchestrating a multi-session research program.
- **Origin**: Session as first-class unit
- **Aliases prohibited**: "COORD" (deprecated abbreviation), "coordinator" (role, not Session-Type)
- **Cross-references**: Session-Type, Session, P12

### Principle
- **Definition**: One of the 12 canonical SliceOps principles (P1–P12). Layer A. Immutable except by superseding DEC under an elevated HITL gate.
- **Origin**: Canonical principles
- **Cross-references**: Layer A, P1–P12

### Provenance
- **Definition**: Origin-tracking metadata. Slice ID, agent attribution, timestamps, and commit SHA. An evidence category per P6.
- **Origin**: P6
- **Cross-references**: P6, Slice ID, Evidence categories

### R-rules (R1–R14+)
- **Definition**: Enforced merge gates in CI that validate framework metadata (and, per adopter, Layer C.2 stack patterns). A Layer B.1 pattern; specific Rs are adopter-instantiable (R1–R14 starter, R15+ adopter-specific).
- **Origin**: Positioning; canonicalized in IP boundary
- **Aliases prohibited**: "linter rules" (broader category), "validators" (ambiguous with runtime validation)
- **Cross-references**: Layer B.1, CI gates, Counter discipline

### Recursive Learning by Capture
- **Definition**: P8. The framework improves itself through capture. InsightRecords and LearningPatterns inform R-rule amendments via DECs. The corpus is training data.
- **Origin**: P8
- **Cross-references**: P8, InsightRecord, LearningPattern, R-rules

### Reconciliation ritual
- **Definition**: Layer 5–6 mechanisms — Block Retrospective consistency review and Quarterly Curation. Periodic drift detection and reconciliation DECs.
- **Origin**: Consistency-management mechanism
- **Cross-references**: Block Retrospective, Quarterly Curation

### Shared-Resource Pre-flight (P9)
- **Definition**: The 12th canonical principle (Layer A). Before scaling any parallelism lever beyond the baseline calibrated in the last Block Retrospective, enumerate, cap, alert, and telemeter every finite/serialized shared resource that lever consumes. Operating theorem: "the success of a parallelism lever is the source of the next bottleneck."
- **Origin**: Shared-Resource Pre-flight
- **Aliases prohibited**: "resource management" (generic), "P10" (Infrastructure Continuity — distinct), "10x rule" (rejected — trigger is calibrated baseline, not a magic number)
- **Cross-references**: P10 (orthogonal — see "Why P9 ≠ P10"), Finite/serialized shared resource, CI/Pipeline Cost Economy, P5, P8

### announced degradation vs invisible hard cutoff
- **Definition**: The anti-pattern framing of P9. The default for any finite shared resource must be cap and alert ("announced degradation"), never a silent hard-stop ("invisible hard cutoff"). A `$0` default spending limit is the paradigmatic anti-pattern.
- **Origin**: Shared-Resource Pre-flight (P9)
- **Cross-references**: P9, Finite/serialized shared resource

### Session
- **Definition**: Cognitive entity #13 in the Layer B.1 catalog. The unit of human–AI interaction (one conversation/chat with an AI agent). Every AI interaction is a Session, identifiable and auditable. **The Slice is the DEV Session-Type** — every slice is a session; not every session is a slice (Meta, Audit, Learning, Support, Infra, Artifact, Orchestrate are valid Session-Types that do not produce a PR). Decisions emerge from sessions (P1 generalized).
- **Origin**: Session as first-class unit
- **Aliases prohibited**: "chat" (under-specified), "conversation" (informal), "interaction" (ambiguous)
- **Cross-references**: Slice, Session-Type, P2, P1, P6, Cognitive entity

### Session-Type
- **Definition**: A canonical classification of a Session (level 1). Eight universal types: **Slice** (development → PR), **Artifact** (bounded output), **Support** (incidents/care), **Infra** (infra/deploy/ops), **Meta** (governance), **Audit** (verification/control), **Learning** (exploration/research), **Orchestrate** (coordinates other sessions). Vendor-neutral; adopter-specific sub-variants are Layer C.2.
- **Origin**: Session as first-class unit
- **Aliases prohibited**: "category" (too broad), "kind" (informal)
- **Cross-references**: Session, Slice-Type, Orchestrate

### Slice-Type
- **Definition**: A level-2 classification, only when Session-Type=Slice. Three canonical: **Dev** (feature, typically SemVer minor), **Refactor** (no functional change, SemVer patch), **Fix** (bugfix, SemVer patch). Adopters may add stack-specific Slice-Types (Layer C.2).
- **Origin**: Session as first-class unit
- **Cross-references**: Session-Type, Slice

### Slice
- **Definition**: An atomic, vertical, end-to-end unit of work. One AI-agent chat, one PR, one cohesive outcome. Spec, decision, code, tests, evidence, and merge in one unit. **Clarification (slice ⊂ session)**: the Slice is the DEV Session-Type — there are other valid Session-Types (Meta, Audit, Learning, etc.) that do not produce a PR; P4 governs the atomicity of DEV slices specifically.
- **Origin**: P4; clarified by Session as first-class unit
- **Aliases prohibited**: "story", "ticket", "task", "work item"
- **Cross-references**: P4, Session, Session-Type, Slice-Type, Token-band

### synthesis efficiency
- **Definition**: A calibrable model attribute = the **semantic density** with which a model creates context (information preserved per output token). "Says the same thing without losing the idea." Varies across models (a language skill, like code-golf for code: 1 line vs 70). An **axis of Model Triage** (priority for context-producing slices). Proxy measurement: output-tokens to pass fixed acceptance criteria. Caveat: density ≠ terseness; optimum is maximum density that still passes the acceptance gate (P6) and remains auditable (P2).
- **Origin**: Context Router and synthesis efficiency
- **Cross-references**: Model Triage, context-consuming vs context-producing slice, P6, Determinism-over-Regeneration

### Slice ID
- **Definition**: The canonical identifier in `BL-XX.SEC-XX.SL-XXX` (Block-Section-Slice) format. A provenance carrier in branch names, commit messages, PR titles, DEC frontmatter (`originating_slice:`).
- **Origin**: P1
- **Cross-references**: P1, Provenance, Block, Slice

### Stage
- **Definition**: A computed view of the dependency DAG — which slices are mergeable now. NOT an imperative time-bound grouping (per P5).
- **Origin**: P5
- **Aliases prohibited**: "sprint" (commits velocity ahead), "phase" (linear), "milestone" (time-based)
- **Cross-references**: P5, DAG, Block

### Stack pattern
- **Definition**: A Layer C.2 pattern. An architectural pattern concrete to a technology stack, instantiable, enforced via tooling (analyzer / lint rule / CI gate), documented in the adopter's own cross-cutting architecture docs.
- **Origin**: Stack-patterns
- **Cross-references**: Layer C.2, Brain pack injection, Adopter

### spec-anchored
- **Definition**: How SliceOps uses specs: the spec **anchors** the slice scope (prevents drift, declares the outcome upfront) but is **co-equal** with decision and evidence, NOT sovereign. Distinct from "spec-driven" (where the spec is the driver and source of truth). The framework itself has a versioned spec (this document and siblings) — but that is the spec of the framework, not spec-driven-development per project.
- **Origin**: SliceOps development model
- **Aliases prohibited**: "spec-driven" (different concept), "specless" (incorrect)
- **Cross-references**: Decision-driven, Acceptance-first slice, P4

### Supersession
- **Definition**: An edge between DECs declaring that a new DEC replaces an earlier one. Bidirectional frontmatter: the new one has `supersedes: [old]`; the old has `superseded-by: <new>`. The graph must be acyclic.
- **Origin**: P2
- **Cross-references**: P2, Frontmatter, Bidirectional cross-reference

### Token-band
- **Definition**: Slice/session size classification (XS/S/M/L/XL) for **throughput** — measured in **billed-equivalent** tokens (input + cache_creation×1.25 + cache_read×0.1 + output), NOT total-with-cache (which inflates ~5×). Calibrated bands (baseline 2026-06-15): XS<2M · S 2–5M · M 5–10M · L 10–20M · XL>20M. Governs cost (P9) and forecast.
- **Origin**: P4 and Bidimensional sizing
- **Aliases prohibited**: "total-with-cache" as the band unit (inflates the measurement; not the canonical unit)
- **Cross-references**: P4, P9, Slice, Session, context-band, Sizing, Calibration discipline

### context-band
- **Definition**: Slice/session size classification (XS/S/M/L/XL) for **peak context footprint** — the maximum `input + cache_creation + cache_read` loaded in a single turn. Orthogonal to token-band. Calibrated bands (baseline 2026-06-15): XS<32K · S 32–128K · M 128–200K · L 200–512K · XL>512K. Governs **model viability** (the primary filter in Model Triage — a model whose window is smaller than the footprint cannot run the slice).
- **Origin**: Bidimensional sizing
- **Cross-references**: P4, Sizing, Model Triage, Calibration discipline, Context Router

### Context Router
- **Definition**: A Layer B.1 artifact. Routes context selectively to each slice/session — instead of loading the whole corpus, activates only the relevant **context-experts** (DECs/entities/code-modules grouped by topic/dependency). Three mechanisms: (1) routing, (2) compression (coordinator summaries, handoff contracts), (3) sparse working set. Reduces the context-band footprint that Model Triage filters on. MoE-inspired (gating-network analog at the orchestration level, NOT a claim about the transformer's internal architecture).
- **Origin**: Context Router and synthesis efficiency
- **Cross-references**: ContextPack, context-band, context-expert, Model Triage

### context-expert
- **Definition**: A specialized context module (a cluster of DECs / entities / code modules grouped by topic or dependency) that can be activated selectively by the Context Router. The "expert" analog from MoE applied to context selection, not to model weights.
- **Origin**: Context Router
- **Cross-references**: Context Router, ContextPack

### context-consuming vs context-producing slice
- **Definition**: A triage distinction. A **context-consuming** slice reads a lot (analysis over existing code/corpus), so Model Triage prioritizes a large window. A **context-producing** slice writes a lot (specs/docs/code/refactor), so Model Triage prioritizes synthesis efficiency (density). A model optimal for consuming is not necessarily optimal for producing.
- **Origin**: Context Router and synthesis efficiency
- **Cross-references**: Model Triage, synthesis efficiency, Context Router

### Topic (canonical)
- **Definition**: A tag from the canonical topic taxonomy used in DEC frontmatter `topics:`. Enables corpus indexing by theme and topic-related search.
- **Origin**: Consistency-management mechanism
- **Cross-references**: Topic taxonomy, Layer 1

### Topic taxonomy
- **Definition**: The canonical taxonomy of SliceOps topics. Living document; new topics emerge via DEC. Documented in `topics.md`.
- **Origin**: Consistency-management mechanism
- **Cross-references**: Topic, Layer 1, Vocabulary discipline

### Vendor
- **Definition**: An organization that provides a runtime implementation (Layer C.1). Distinct from an adopter.
- **Origin**: IP boundary (three-layer)
- **Cross-references**: Adopter, Layer C.1

### Context Discipline
- **Definition**: P12. AI agents are memoryless across sessions; the corpus IS their persistent, shared context, engineered as a **single source of truth** (foundations → decisions → architecture → specs → plan) — enriched yet **selectively routed** so multiple agents stay coherent within finite windows. Duplicated or drifted context is corruption. Reframed from "Vocabulary Discipline"; canonical vocabulary is one facet.
- **Origin**: P12 (reframed from Vocabulary Discipline; vocabulary = facet)
- **Cross-references**: P12, Vocabulary Discipline (facet), Context Router, Consistency management, Glossary

### Vocabulary Discipline
- **Definition**: A **facet of P12 Context Discipline**. Canonical terms have canonical meanings; synonyms drift, SliceOps does not. Fix-on-touch policy applies.
- **Origin**: P12 (Context Discipline, vocabulary facet)
- **Cross-references**: P12, Context Discipline, Glossary, Fix-on-touch

### vocabulary-changes (frontmatter field)
- **Definition**: Mandatory DEC frontmatter field. Lists canonical terms introduced or modified by the DEC. Triggers a glossary update.
- **Origin**: Consistency-management mechanism
- **Cross-references**: Layer 1, Glossary, Vocabulary discipline

### Wedge
- **Definition**: A competitive positioning differentiator. SliceOps has three: Wedge A (Audit Plane), Wedge B (DAG-driven multi-agent parallelism), Wedge C (AI-readable engineering — every artifact is training data).
- **Origin**: Positioning
- **Cross-references**: Wedge A, Wedge B, Wedge C

---

Adopters may extend this glossary with domain-specific terms in their own glossaries. Canonical SliceOps terms here are reserved — do not redefine; only extend.

- DEC with non-empty `vocabulary-changes` triggers an update here (same slice).
- Quarterly Curation ritual — drift detection and reconciliation.
- Fix-on-touch per P12 — slices touching stale references update forward.

Major restructure leads to a version bump (`glossary` under a new spec version directory).