Glossary

Last updated 23 August 2026 · clause numbers refer to MC-SPEC 0.4.20

Plain-English readings of the terms the site uses, in the order a newcomer meets them. Each row names where the term is defined formally. The prose on every page is written to survive with these definitions in hand and nothing else.

First contact — the sixteen terms you need before the framework page

Term	Plain reading	Defined
Maneuver	One adversary procedure, modeled as what it needs, what it does, and what it leaves behind. The atomic unit of the calculus.	§4.1
Precondition / postcondition	The state that must hold before a maneuver runs ({P}), and the state it leaves behind after ({Q}).	§4.1, §4.3
Objective	What the maneuver is for — e.g. obtaining credentials. It is carried by the record but does not by itself identify it.	§4.1, §4.4.1
Invariant core	The part of a maneuver that cannot be dropped without abandoning the objective. Fixes identity.	§4.4.3
Implementation variant	One swappable way of realizing the core — a particular tool or route. Many variants, one core.	§5
State variable / value order	A named dimension of world state (access, scope) plus the ordering that says which values satisfy a requirement for which others.	§3.1
Enablement	A computed edge (canUnlock) saying one maneuver's result supplies at least one thing another requires. Never authored by hand.	§6.2
Observable	A signal a mechanism produces that telemetry can actually see. Something that exists but produces no telemetry is not one.	§7.1.1
Robustness	How hard a detection is to evade, decided by what it is keyed on: incidental attributes at the bottom, the invariant core at the top. Graded L1–L5 (Summiting the Pyramid).	§7.1
Spanning / discriminating	A detection keyed on the core fires whichever variant ran (spanning); one keyed on a single variant fires only for that variant (discriminating).	§7.2.1
Detection face	One detection, with its telemetry sources declared and typed. Earlier drafts called this a “detectability”.	§8.1
Detection health	A face's status, four-valued — live, degraded, uncertain, blind — computed from the telemetry beneath it, not read off a control dashboard.	§8.2
Defender grid	The nine ways a defense can be placed: where it acts (precondition, mechanism, postcondition) crossed with what it does (prevent, detect, respond).	§9.1, §9.3
Posture	The asserted current state of your defensive controls — what is deployed, where, configured how.	§4.3.2
Coverage record	The answer to “is this covered”, kept as five separately-derived dimensions rather than one word: break, liveness, grounding, assurance, selectivity. A single verdict is a named projection over the record; the spec publishes one reference projection.	§10.1
Unmodeled	Something the model has no record for. Reported as a gap and escalated — never as covered.	§10.4, §4.3.3

Second tier — met on specific pages

Term	Plain reading	Defined
Analogy register	A retelling of a maneuver in a non-security vocabulary — e.g. the bank-robbery story on Start here — used only to teach the structure. It is an analogy, never a synonym for the fixed vocabulary (maneuver, robustness, defensive control, coverage).	design §1 / start §0.2
Invariant core A / B / C	For LSASS credential dumping, three distinct cores, because they differ in {P} m {Q}: A reads the process memory live; B writes it to disk (yielding a file, not yet a held credential); C executes inside the process. A different triple is a different core, not a variant.	§4.4.3
Structurally breaks	A placement structurally breaks a maneuver when it stops it reaching its effect, not merely observes it. Prevent and respond can break; a detect placement never breaks anything.	§9.2
Transfer	A defensive result transfers to every aligned record exactly when the placement acts on the invariant core; a placement on one record's variation is a result for that record alone.	§4.7.1, §4.7.3
Altitude	Which level of abstraction a statement lives at. Technique labels sit one altitude above maneuvers; type altitude (what could happen) is distinct from occurrence altitude (what did).	§13.1
Derived vs asserted	A derived conclusion is computed from the model and can be audited; an asserted one is somebody's claim. Coverage is always derived.	§2.3
Completeness claim	A deployment's explicit statement of which cells it has modeled; everything outside it is unmodeled.	§4.3.3
Reference projection	The one published way of collapsing a coverage record to a single verdict. One option, not a default.	§10.1.3
Defensive-design profile	A named set of choices about how a deployment projects coverage and what it requires before saying “covered”.	§10.5
Explanation fan / plausibility	Given two observations and the residual between them, the ranked set of maneuver sequences that could close the gap.	§11
Fabricability	How easily an observable can be injected or forged; the injection-resistance half of robustness.	§7.4
Coverage card	The doctrine sheet the calculus derives from the ontology for an environment: the maneuver family a mature shop keeps on hand, the deployed controls, and the coverage relations written as a function of control state. No incident content. The artifact the results page measures.	results §2
Paired-arm tabletop	The test design: the same responder runs the same incident twice with a fresh context — once without the card, once with it — scored per decision point against a key frozen before play.	results §2
Deposit / serial	A frozen, checksummed release of the ontology. Deposits are never edited; fixes bump the serial (0.4.20.1 → 0.4.20.2).	ontology README
Authorship gate	The rule for changing the ontology: quoted clause text, a balloted decision on any underdetermined choice, a signed diff.	CONTRIBUTING

NoteThe machine ontology (mc-core 0.4.20.2) carries 459 terms with a clickable offline inspector; it will be published alongside the deposit. This page is the human on-ramp, not the authority — the specification is.