Applied Volume Glossary

A consolidated list of terms from the second volume of the textbook. Definitions are duplicated here so that chapters do not develop inconsistencies. If a term has already been introduced in the first volume, a production refinement is given here along with a reference to the chapter of the second volume where it is used.

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

The reading rule is simple: a file name or a YAML/JSON key can be left in English, but in the explanation pick one Russian sense. For example, judgment.md is a dispute decision file; tribunal is a file-based arbitration, not a separate product or a built-in Qwen Code command.

The main prose forms recommended by default (the English key only in code blocks and at the 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 captions;
• "Spec CI" or "specification gateway (Spec CI)" — in prose; spec_gate — only as a job name in .github/workflows/spec-ci.yml;
• "file-based arbitration" — in prose; tribunal — only as a 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 second volume prose, we use the Russian equivalent of a term by default and, at the first mention in a chapter, give the English key in parentheses, for example: "evidence reference (evidence_ref)". This table is a working reference: which terms are translated, which remain in English as technical names, which live as a compound Russian-English term. If a chapter uses only the Russian variant, you can return here and check what stands behind it.

The class "technical name" means an identifier in YAML/JSON, a CLI/script name, a status name, or a configuration key — it is left untouched. The class "term with dual spelling" — a borrowed word is used as a compound process marker; in prose we introduce the Russian equivalent, but both spellings are allowed. The class "prose term" — a borrowed word is fully russified, and only the Russian form remains in the main text.

| judgment, judgment.md | dispute decision; file name is left untouched | term with dual spelling | | precedent, precedents.md | precedent; file name is left untouched | term with dual spelling | | audit_trace_coverage | audit trace coverage (metric, keep the key name) | technical name | | shadow specs, shadow spec | shadow specifications; both spellings are allowed in headings | term with dual spelling | | stress spec, stress-spec | stress specification | prose term | | guard metric, guard-metric | paired counter-metric, guard metric | term with dual spelling | | kill switch | kill switch, kill switch | term with dual spelling | | playbook | playbook | prose term (borrowing) | | runbook | runbook | prose term (borrowing) | | readiness gate, readiness | readiness gate, readiness; keep the model item name | term with dual spelling | | rollback, rollback_condition | rollback; keep the rollback_condition key | term with dual spelling | | dry run, dry-run | dry run | prose term | | webhook | webhook | prose term (borrowing) | | auction | auction | prose term (borrowing) |

| tribunal | file-based arbitration of a disputed change; technical name of the example directory and scripts | technical name | | Verifier, Implementor, Safety, Coordinator | Verifier, Implementor, Safety (vote), Coordinator (non-voting protocolist) — in prose; role names in YAML and code remain in English | term with dual spelling | | immunity score | immunity metric (vector) | prose term | | tier (low/mid/high, local-coder, frontier-reviewer) | tier (low/middle/high) in prose; keys and role names in YAML are not translated | term with dual spelling | | 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 | term with dual spelling | | blast radius | blast radius, blast radius | term with dual spelling | | gate, spec gate | gate, specification gate (gate) | term with dual spelling |

| manual_review_floor, manual_review_rate | minimum of manual review, share of manual review; keep the keys | technical name | | genealogy, genealogy.md | genealogy; file name is left untouched | term with dual spelling | | ttl, time to live | time to live (ttl); keep the key | technical name | | few-shot | few-shot example, few-shot | term with dual spelling | | scorebook | scorebook; file name is left untouched | term with dual spelling | | pre-approved actions | pre-approved actions | prose term | | quarantine | quarantine | prose term | | ask_storm, stage_regress, phase_context_loss | antipattern names are kept as is; at the first mention in a chapter give a short Russian comment | technical name | | capstone, dossier | final graded package, evidence package | term with dual spelling |

Technical names that remain as is and are not translated either in prose or in 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 the like), file names (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 the Term Is First Introduced

The map helps you quickly open the chapter in which a term first receives a working definition and an application 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 several parts, the column lists the part where it receives a working definition and a runnable scenario. Production refinements and links between terms are covered in part 12 and part 13.

Relationship with the Glossary of the First Volume

This glossary supplements, and does not replace, the glossary of the first volume. 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 are not repeated here.

Production refinements are layered on top of these basic terms:

• The first volume's validation.md contains merge-gate facts; in the second volume it is supplemented with duel failing cases, anti-Goodhart checks, drift fields, and trace entries.
• The first volume's QWEN.md stores the agent's persistent context; in the second volume it also becomes the place where few-shot examples from the shadow specs auction are placed, with a review deadline.

• The first volume's constitution fixes mission.md + tech-stack.md + roadmap.md; in the second volume it is extended 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 refinement here.

AgentClinic Training Project

The production scenarios of the applied volume are mentally deployed on the AgentClinic training project from the first volume: TypeScript, Hono, server-side JSX, SQLite, Vitest. Python belongs to the runnable examples of 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 correspondence between the training code and production incidents is fixed in the table in Appendix A of the applied volume.

Figurative Names

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

• Specification recovery — recovery of requirements from legacy code, logs, incidents, and the history of decisions; "spec necromancy" is allowed only as an auxiliary label.
• Poisoned specification — a deliberately broken training specification with a single controlled defect.
• Validator vaccination — mutation testing for specifications and checks.
• Shadow specifications auction — evaluation and ranking of informal heuristics before they are included in the working context.
• File-based arbitration of a disputed change — see the "File-Based Arbitration" section below; tribunal in file and directory names remains a technical label for the example.
• Tiered model routing — distribution of tasks among models of different cost and quality.
• Bait metrics — KPIs that are easy to optimize at the expense of the system; the engineering defense is paired counter-metrics (guard metrics).
• Emergency mode (red button) — a formal safety gateway before a dangerous action: deploy, rollback, migration, or auto-remediation; "red button" is a colloquial label.

Agent Roles

Verifier — an agent or session whose only task is to look for violations of invariants, the contract, and facts. It has no right to write code or change artifacts; it only issues an approve / reject / abstain verdict with justification. See part 4 and part 8 for details.

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

Coordinator — a role (a person, a CI job, or an external orchestrator) that makes the final decision based on the results of file-based arbitration, records the precedent, and publishes judgment.md. It does not vote on a par with the Verifier, Implementor, and Safety; it is responsible for procedure, not substance.

Safety — a separate role in governance_protocol that checks blast radius, privacy, backup protection, and rollback conditions. It has a veto on critical_risk: even with two approve votes from the Verifier and the Implementor, a fix is rejected. See part 3 for details.

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

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

Specifications and Artifacts

Shadow specification (shadow spec) — a specification for non-formalizable nuances: intonation, unspoken priorities, historical decisions that did not make it into the main requirements.md. Stored separately, wins in the auction based on the scorebook, does not replace the main specification. See part 6 for details.

Scorebook — a journal of evaluations of shadow specifications: formula, weights, budget, thresholds, and the components mttr_gain, early_signal, coverage, false_escalation for each candidate. A file of the form .specify/memory/shadow-scorebook.json; created or updated by running the auction.

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

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

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

Immutable principle — a rule in the immutable_principles section of constitution.md that cannot be turned off automatically: a ban on restarting a production database without a backup, on deleting backups, on bypassing in a security-critical namespace. It is changed only through an explicit team referendum, not through an agent vote.

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. It evolves through a referendum as unforeseen incidents accumulate.

**proposal.md** — a separate amendment file for constitution.md that goes through as a change to the risk contract. It contains version, parent_version, justification, changes in mutable_rules, the expected effect, and rollback_condition. The template is [examples/templates/proposal.md](examples/templates/proposal.md); the referendum procedure is in part 3.

**precedents.md** — a journal of precedents from file-based arbitration: each resolved disagreement is recorded as a case_ref, the rule that was violated, the final verdict, and a link to judgment.md. Used as the shortest path to a decision on recurring disputes; the format is in part 8.

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

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

Capstone dossier — a set of files from part 13 that shows the full production SDD path for a single incident: the origin of the requirement, the poisoned defect, the fix, the constitution, the check, the verdict, the budget, the anti-Goodhart limiters, the readiness, and the antipattern audit.

Immunity Metrics and Goodhart Defense

Immunity score — a vector of validator scores, not a single aggregate number. It consists of three components: strict_reject_rate, depth_of_diagnostics, recovery_time_p95_ms. Used as a gateway in the validator loop during mutation testing of specifications.

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

**depth_of_diagnostics** — the useful depth of explanation before failure: how many tracing steps the validator went through before returning a verdict. A depth of 1 is "rejected", a depth of 3+ is "rejected, because field X in step Y violates rule Z".

**recovery_time_p95_ms** — p95 of the time (in milliseconds) in which the validator returns a stable verdict and a diagnostic path after a specification change. Exceeding the threshold (e.g., 1200ms) provokes workaround practices and slows down CI.

**silent_p0** — the share of P0 incidents that have passed through automation without human confirmation and without an entry in the audit trail. Anti-Goodhart metric: if MTTR falls and silent_p0 rises, auto-remediation is speeding up at the cost of hidden risks. See part 10 for details.

**manual_review_floor** — the minimum share of decisions that must go through human review, even if automation formally copes. Protection against one-sided optimization: it prohibits the agent from "squeezing" the human out of the loop entirely.

**audit_trace_coverage** — the share of agent actions for which the full evidence chain has been saved: input payload, specification version, constitution version, vote log, decision_hash. The target value is 100%; a drop blocks merge and the red button.

Anti-Goodhart — a general technique for designing metrics in pairs with antibodies. Each target metric (MTTR, edge_drift) is paired with a guard metric (silent_p0, manual_review_floor, audit_trace_coverage), and the CI gateway passes only if 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, an expected_failure, and a halt_before step. See part 5 for details.

Nullify — an operator that nullifies a required field (service_id, owner, timestamp). Expected failure: EMPTY_REQUIRED_FIELD before SLA calculation.

FutureTime — an operator that puts 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 back edge to the escalation routing graph (traffic_sre → edge_oncall when edge_oncall → traffic_sre already exists). Expected failure: CYCLE_ESCALATION with the minimum cycle in the diagnostics.

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

PriorityContradiction — an operator in which one rule lowers P1 to P2, and another returns P2 to P1 without a tie_breaker. Expected failure: PRIORITY_REVERSAL; the defense is a conflict resolution policy, not a routing graph.

File-Based Arbitration

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

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

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

Genealogy — the chain parent_version → version in the constitution's change_log and in the decision log. Allows reconstructing why the agent had the right to a specific action at the time of the incident, and recalculating the decision post hoc.

Execution Control

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

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

Time to live (TTL) — the lifetime of a mutable rule or a temporary exception (override). Without a ttl, an amendment becomes perpetual and turns into a hidden part of the invariant.

Rollback condition — a condition for cancelling a mutable rule: a rise in repeat incidents, a Safety veto, exceeding the silent_p0 threshold. It must be automatically checkable, not remain a text formulation.

Evidence Base

Evidence chain — a structured chain of artifacts attached to the agent's decision: input payload, specification version, active rules of the constitution, arbitration vote log, diff of the applied change, postcondition checks. The minimum requirement for production SDD.

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

Replay — replaying historical incidents through the current validator and the current constitution. Used as a gateway in Goodhart metrics: a new version must not worsen verdicts on already analyzed cases. See part 10 for details.

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

Process Antipatterns

**ask_storm** — a state in which the agent is stuck in a loop of clarifying questions instead of stopping. The control line from part 2: cycle_count > 0 && ask_storm >= 4 && escalation_path_resolved=false. A sign of a poisoned or internally contradictory specification.

**stage_regress** — a rollback to a previous phase of the SDD cycle without an explicit reason: implement returns to plan, plan returns to specify. Treated by tying each phase to facts in validation.md and by fixed transition criteria.

**phase_context_loss** — a loss of context between phases: specify recorded a decision, plan did not inherit it, implement acts on a draft. The defense is explicit references @specs/... 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 the spec gate.

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