Applied Volume Glossary

A consolidated list of terms from the second volume of the textbook. Definitions are duplicated here to prevent divergent interpretations in chapters. If a term was introduced in the first volume, this glossary provides production clarifications and references to the chapter in the second volume where it operates.

Do not read the entire glossary before starting the second volume. For the first pass, it is sufficient to understand capstone/ and the ten mandatory first-pass artifacts (full list in README, "Mandatory First-Pass Artifacts" section). Open other terms only when they help fill a specific file or understand a runnable example.

The reading rule is simple: a filename or YAML/JSON key may remain in English, but in explanations choose one Russian meaning. For example, judgment.md is a dispute resolution file; tribunal is a file arbitration, not a separate product or built-in Qwen Code command.

Primary prose forms recommended for default use (English key only in code blocks and on first mention in parentheses):

• "silent P0" — in prose; silent_p0, silent_p0_cap, silent_p0_ratio — everywhere in code, YAML/JSON keys, commands, and metric labels;
• "Spec CI" or "specification gateway (Spec CI)" — in prose; spec_gate — only as a task name in .github/workflows/spec-ci.yml;
• "file arbitration" — in prose; tribunal — only as the directory name examples/tribunal/ and its scripts;
• "emergency mode" — in prose; "red button" — as a short label; red_button, red_button_mttr_blindness — only as invariant names in YAML.

Key Term Translation Table

In the prose of the second volume, we use the Russian equivalent of a term by default and provide the English key in parentheses on first mention in a chapter, for example: "evidence reference (evidence_ref)". This table is a working reference: which terms are translated, which remain in English as technical names, and which exist as a hybrid Russian-English term. If a chapter uses only the Russian variant, you can return here to verify what stands behind it.

The "technical name" class means an identifier in YAML/JSON, a CLI/script name, a status name, or a configuration key — these are not altered. The "dual-writing term" class means the anglicism is used as a composite process marker; in prose, introduce the Russian equivalent, but allow both forms. The "prose term" class means the anglicism is fully Russified, and only the Russian form remains in the main text.

| judgment, judgment.md | dispute resolution; filename is not altered | dual-writing term | | precedent, precedents.md | precedent; filename is not altered | dual-writing term | | audit_trace_coverage | audit trace coverage (metric, key name preserved) | technical name | | shadow specs, shadow spec | shadow specifications; both forms allowed in headings | dual-writing term | | stress spec, stress-spec | stress specification | prose term | | guard metric, guard-метрика | paired counter-metric, guard metric | dual-writing term | | kill switch | emergency stop, kill switch | dual-writing term | | playbook | playbook | prose term (borrowing) | | runbook | runbook | prose term (borrowing) | | readiness gate, readiness | readiness gate, readiness; model item name preserved | dual-writing term | | rollback, rollback_condition | rollback; rollback_condition key preserved | dual-writing term | | dry run, dry-run | dry run | prose term | | webhook | webhook | prose term (borrowing) | | auction | auction | prose term (borrowing) |

| tribunal | file arbitration of disputed change; technical name of example directory and scripts | technical name | | Verifier, Implementor, Safety, Coordinator | Verifier, Implementor, Safety (voting), Coordinator (non-voting protocolist) — in prose; role names in YAML and code remain English | dual-writing term | | immunity score | immunity metric (vector) | prose term | | tier (low/mid/high, local-coder, frontier-reviewer) | tier (low/mid/high) in prose; keys and role names in YAML — untranslated | dual-writing term | | mutation, mutation testing | mutation, mutation testing | prose term (borrowing) | | coverage, coverage-check | coverage, coverage check | prose term | | scope, scope-check, out-of-scope | scope, scope check, out of scope | prose term | | failover | failover, failover | dual-writing term | | blast radius | blast radius, blast radius | dual-writing term | | gate, spec gate | gate, specification gate (gate) | dual-writing term |

| manual_review_floor, manual_review_rate | manual review minimum, manual review rate; keys preserved | technical name | | genealogy, genealogy.md | genealogy; filename not altered | dual-writing term | | ttl, time to live | time-to-live (ttl); key preserved | technical name | | few-shot | few-shot example, few-shot | dual-writing term | | scorebook | score journal (scorebook); filename not altered | dual-writing term | | pre-approved actions | pre-approved actions | prose term | | quarantine | quarantine | prose term | | ask_storm, stage_regress, phase_context_loss | anti-pattern names preserved as-is; short Russian comment given on first mention in chapter | technical name | | capstone, dossier | capstone package, evidence package | dual-writing term |

Technical names that remain unchanged and are not translated in either prose or tables: YAML/JSON keys (immutable_principles, mutable_rules, governance_protocol, incident_type, pipeline_phase, permitted_actions, max_scope, rollback_condition, decision_hash, parent_version, change_log, audit_trace, prompt_hash, decision_source, next_guard and similar), filenames (QWEN.md, requirements.md, plan.md, validation.md, mission.md, tech-stack.md, roadmap.md, constitution.md, judgment.md, precedents.md, genealogy.md), CLI command and script names (qwen -p, python3 scripts/..., git, npm, rg), custom command names (/sdd:specify, /plan, /review), statuses (Standard / Recommendation / Frontier), block markers ([runnable], [project script]), abbreviations (MCP, CI, LLM, API, KPI, MTTR, SLO, SLA, SRE).

Where a Term Is First Introduced

This map helps quickly open the chapter where a term first receives a working definition and usage scenario. Metrics (silent_p0, audit_trace_coverage, manual_review_floor) and memory keys (shadow-scorebook.json, shadow-candidates.yaml, precedents.md, judgment.md) are listed separately: metrics measure the system, memory keys store its history.

| metric | strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms | 5 | | metric | mttr_gain, early_signal, coverage, false_escalation | 6 | | metric | token_health_min, failover_to_frontier, degraded_queue | 9 | | metric | silent_p0, manual_review_floor, audit_trace_coverage | 10 | | memory key | .specify/memory/shadow-candidates.yaml, .specify/memory/shadow-scorebook.json | 6 | | memory key | precedents.md, change_log | 3, 8 | | mechanism | stress specification, mutation testing | 5 | | mechanism | shadow specification, auction, scorebook | 6 | | mechanism | specification gateway (Spec CI) | 7 | | mechanism | tiered routing, local-coder, frontier-reviewer, budget keeper | 9 | | mechanism | paired counter-metric, anti-Goodhart, emergency mode | 10 |

| mechanism | dry-run, readiness gate, evidence_ref | 11 |

If a term appears in multiple parts, the column indicates the one where it receives a working definition and runnable scenario. Production clarifications and connections between terms are discussed in part 12 and part 13.

Connection to the First Volume Glossary

This glossary supplements, not replaces, the first volume glossary. Basic SDD terms — QWEN.md, mission.md, tech-stack.md, roadmap.md, requirements.md, plan.md, validation.md, Qwen Code skills, MCP, ACP, EARS, Given/When/Then — are defined there and not repeated here.

Production clarifications are layered on top of these basic terms:

• validation.md in the first volume contains merge admission facts; in the second volume, it is supplemented with failing duel cases, anti-Goodhart checks, drift fields, and trace records.
• QWEN.md in the first volume stores the agent's persistent context; in the second volume, it becomes the placement site for few-shots from the shadow specs auction with a review period.

• The first volume constitution fixes mission.md + tech-stack.md + roadmap.md; in the second volume, it is expanded with an explicit constitution.md section containing immutable_principles, mutable_rules, and governance_protocol.

If a term from this glossary seems unfamiliar, start with the basic definition in the first volume and then read the production clarification here.

Study Project AgentClinic

Production scenarios in the applied volume are mentally deployed on the study project AgentClinic from the first volume: TypeScript, Hono, server JSX, SQLite, Vitest. Python pertains to runnable examples in the second volume: these are small stdlib scripts for local checks, not the main application stack. Domain entities — agent-patients, ailments, therapies, appointments, reviews, feedback — are described in Appendix B of the first volume. The mapping between study code and production incidents is recorded in the table of Appendix A of the applied volume.

Figurative Names

Chapters sometimes use figurative names. They serve as auxiliary labels, not as primary process names. The engineering equivalents are:

• Specification recovery — recovering requirements from legacy code, logs, incidents, and decision history; "Spec necromancy" is only acceptable as an auxiliary label.
• Poisoned specification — an intentionally broken study specification with one controlled defect.
• Validator vaccination — mutation testing for specifications and checks.
• Shadow specs auction — evaluation and ranking of informal heuristics before inclusion in working context.
• File arbitration of disputed change — see the "File Arbitration" section below; tribunal in filenames and directories remains a technical example label.
• Tiered model routing — distributing tasks between models of different cost and quality.
• Bait metrics — KPIs that are easy to optimize at the system's expense; engineering defense is paired counter-metrics (guard metrics).
• Emergency mode (red button) — a formal safety gateway before a dangerous action: deployment, rollback, migration, or auto-remediation; "red button" is a colloquial label.

Agent Roles

Verifier — an agent or session whose sole task is to find violations of invariants, contracts, and facts. Has no right to write code or change artifacts, only renders a verdict of approve / reject / abstain with justification. Details in part 4 and part 8.

Implementor — an agent that executes a plan in auto-edit mode after approved specification. In file arbitration, votes on the applicability of a playbook patch, but has no right to bypass the Verifier's verdict or the Safety role.

Coordinator — a role (human, CI job, or external orchestrator) that makes the final decision based on file arbitration results, records the precedent, and publishes judgment.md. Does not vote equally with Verifier, Implementor, and Safety; is responsible for procedure, not content.

Safety — a separate role in governance_protocol that checks blast radius, privacy, backup protection, and rollback conditions. Has veto at critical_risk: even with two approve votes from Verifier and Implementor, the patch is rejected. Details in part 3.

**Model tier (tier, local-coder / frontier-reviewer)** — a model level in tiered routing. local-coder — a cheap local model for code generation and drafts; frontier-reviewer — an expensive frontier model used only for critical reviews, disputed verdicts, and red button checks. Details in part 9.

Budget keeper — an external service or script that monitors daily token quotas by tiers and blocks frontier model requests when the limit is exceeded. Qwen Code does not manage the budget itself.

Specifications and Artifacts

Shadow specification (shadow spec) — a specification for unformalizable nuances: intonation, unwritten priorities, historical decisions that did not make it into the main requirements.md. Stored separately, wins at auction based on the score journal, does not replace the main specification. Details in part 6.

Score journal (scorebook) — a journal of shadow specification scores: formula, weights, budget, thresholds, and components of mttr_gain, early_signal, coverage, false_escalation for each candidate. File of the form .specify/memory/shadow-scorebook.json; created or updated by an auction run.

Poisoned specification (poisoned spec) — a study specification into which one defect has been deliberately introduced: an escalation cycle, a priority conflict, or a hidden out-of-scope. Used to train the Verifier and validators. Details in part 2.

Hidden out-of-scope — an action that the specification does not formally prohibit but also does not describe, and which the agent tends to perform "along the way". Example: the specification asks to change alert routing, and the agent additionally edits the SLA policy. Defense — an explicit "Out of Scope" section and a Spec CI gateway.

Override rule — a mutable norm in constitution.md that allows an agent to bypass standard behavior in a narrow context: for a specific incident_type, at a specific pipeline_phase, with limited max_scope and mandatory ttl. Without these restrictions, the rule begins competing with invariants.

Immutable principle — a rule in the immutable_principles section of constitution.md that cannot be automatically disabled: prohibition on restarting a production DB without backup, on deleting backups, on bypassing in a security-critical namespace. Changed only through an explicit team referendum, not through agent voting.

Mutable rule — a rule in the mutable_rules section of constitution.md with mandatory fields incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition. Evolves through referendum upon accumulation of unpredicted incidents.

**proposal.md** — a separate amendment file to constitution.md that passes as a risk contract change. Contains version, parent_version, rationale, changes to mutable_rules, expected effect, and rollback_condition. Template at [examples/templates/proposal.md](examples/templates/proposal.md); referendum procedure in part 3.

**precedents.md** — a journal of file arbitration precedents: each resolved disagreement is recorded as a case_ref entry, violated rule, final verdict, and reference to judgment.md. Used as the shortest path to resolving recurring disputes; format in part 8.

**genealogy.md** — provenance of a recovered specification: for each requirement — a list of sources, confidence level (confirmed, inferred, hypothesis), and open question. Created when recovering a specification from legacy context; details in part 1.

Specification gateway (spec gate) — a CI check that blocks merge if the specification is not covered by a plan, the plan — by tasks, or the tasks — by facts in validation.md. A concrete example is spec_gate in part 7.

Capstone dossier — a set of files from part 13 that demonstrates the full production SDD path for one incident: requirement origin, poisoned defect, fix, constitution, verification, verdict, budget, anti-Goodhart constraints, readiness, and anti-pattern audit.

Immunity Metrics and Goodhart Defense

Immunity metric (immunity score) — a vector of validator scores, not a single final number. Consists of three components: strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms. Used as a gateway in the validator loop during specification mutation testing.

**strict_reject_rate** — the proportion of degenerate cases (mutants) that are strictly rejected at the expected Given/When/Then step. Growth of this metric with a drop in depth_of_diagnostics means the validator has become stricter but "blinder".

**depth_of_diagnostics** — useful explanation depth before rejection: how many trace steps the validator passed before returning a verdict. Depth 1 is "rejected"; depth 3+ is "rejected because field X in step Y violates rule Z".

**recovery_time_p95_ms** — p95 time (in milliseconds) for the validator to return a stable verdict and diagnostic route after a specification change. Exceeding the threshold (e.g., 1200ms) provokes workaround practices and slows CI.

**silent_p0** — the proportion of P0-level incidents that passed through automation without human confirmation and without an audit trail record. An anti-Goodhart metric: if MTTR drops while silent_p0 rises, auto-remediation is accelerating at the expense of hidden risks. Details in part 10.

**manual_review_floor** — the minimum proportion of decisions that must pass through human review, even if automation formally handles them. Defense against one-sided optimization: prohibits the agent from "squeezing" the human out of the loop entirely.

**audit_trace_coverage** — the proportion of agent actions for which a full evidence chain is preserved: input payload, specification version, constitution version, vote log, decision_hash. Target value — 100%; a drop blocks merge and red button.

Anti-Goodhart — a general metric design practice using paired antibodies. Each target metric (MTTR, edge_drift) is matched with a guard metric (silent_p0, manual_review_floor, audit_trace_coverage), and the CI gateway passes only when both are satisfied simultaneously.

Mutations and Stress Testing

Mutation operator — a function that takes a correct specification and introduces exactly one defect of a known class. Each mutation is assigned a mutation_id, expected expected_failure, and halt_before step. Details in part 5.

Nullify — an operator that zeroes out a mandatory field (service_id, owner, timestamp). Expected rejection — EMPTY_REQUIRED_FIELD before SLA calculation.

FutureTime — an operator that sets response_timestamp in the future or creates a negative response lag. Expected codes — INVALID_TIME_ANCHOR, NEGATIVE_RESPONSE_LAG, STALE_INCIDENT_WINDOW.

EscalationCycle — an operator that adds a reverse edge to the escalation route graph (traffic_sre → edge_oncall when edge_oncall → traffic_sre already exists). Expected rejection — CYCLE_ESCALATION with minimal cycle in diagnostics.

RecursiveDependency — an operator that creates indirect recursion between computed fields: owner depends on priority, priority — on blast_radius, blast_radius — again on owner. Expected rejection — RECURSION_LIMIT with field chain. Not implemented in the runnable example examples/stress-mutator/ — described as a future extension in part 5.

PriorityContradiction — an operator where one rule lowers P1 to P2, and another returns P2 to P1 without a tie_breaker. Expected rejection — PRIORITY_REVERSAL; defense is a conflict resolution policy, not a route graph.

File Arbitration

**File arbitration of disputed change (tribunal in example names)** — a collegial decision procedure for a disputed patch or incident: Verifier, Implementor, and Safety vote by fixed protocol, Coordinator formalizes judgment.md. Not a built-in Qwen Code command; implemented as a combination of /review, scripts, and rules.

Precedent — a record in precedents.md about a recurring conflict type and accepted resolution. Used as a latest_matching_precedent tie-breaker in governance_protocol and reduces the cost of the next arbitration.

**Dispute resolution (judgment.md)** — the final artifact of file arbitration: vote log, decision_hash, references to specification, constitution, and incident, active ttl and rollback_condition. Stored in the repository as an immutable trace.

Genealogy — the parent_version → version chain in the constitution's change_log and in the resolution journal. Allows recovery of why an agent at the moment of the incident had the right to a specific action, and recalculation of the decision post-factum.

Execution Control

Emergency mode (red button) — a formal gateway before a potentially dangerous action in production: rollback, migration, mass configuration update. In colloquial text may be called "red button", but in artifacts record the mode activation conditions. Triggers only when all anti-Goodhart metrics are satisfied; example from part 10 — red_button = BLOCKED (MTTR=4:50, silent_p0=18%, manual_review_rate=12%).

Blast radius — the maximum possible impact zone of a single agent action: number of nodes, namespaces, users, data volume. Specified in mutable_rules as max_scope and checked by a gateway before execution.

Time-to-live (TTL) — the lifespan of a mutable rule or temporary exception (override). Without ttl, a patch becomes indefinite and turns into a hidden part of the invariant.

Rollback condition — the condition for canceling a mutable rule: growth of repeated incidents, Safety veto, silent_p0 threshold exceeded. Must be automatically verifiable, not remain a textual formulation.

Evidence Base

Evidence chain — a structured chain of artifacts attached to an agent's decision: input payload, specification version, active constitution rules, arbitration vote log, diff of applied change, post-condition checks. Minimum requirement for production SDD.

Provenance — the origin of a disputed requirement or rule: author, source (ticket, incident, regulatory document), date, uncertainty level. Allows distinguishing "the team agreed" from "the requirement came from an audit".

Replay — re-running historical incidents through the current validator and current constitution. Used as a gateway in Goodhart metrics: a new version must not worsen verdicts on already analyzed cases. Details in part 10.

Drift — divergence between specification, implementation, and what the agent actually does in production. In the applied volume, three types are distinguished: spec_drift (specification outdated), code_drift (implementation diverged from plan), edge_drift (validator began reacting differently to edge cases).

Process Anti-Patterns

**ask_storm** — a state where the agent asks clarifying questions in a loop instead of stopping. Control string from part 2: cycle_count > 0 && ask_storm >= 4 && escalation_path_resolved=false. A sign of a poisoned or internally contradictory specification.

**stage_regress** — rollback to a previous SDD cycle phase without explicit cause: implement returns to plan, plan — to specify. Cured by binding each phase to facts in validation.md and fixed transition criteria.

**phase_context_loss** — loss of context between phases: specify fixed a decision, plan did not inherit it, implement acts on a draft. Defense — explicit @specs/... references and a project skill that checks inheritance between phases.

External SDD Frameworks

GitHub Spec Kit — an open framework with a standard cycle /constitution → /specify → /clarify → /plan → /tasks → /analyze → /implement. Used in the second volume as a reference for Spec CI and spec gate.

AWS Kiro — an IDE with its own SDD model: specs (requirements.md + design.md + tasks.md), steering files, agent hooks. Mapping with the textbook in Appendix A of the first volume.