Reference · development snapshot
A shared vocabulary
Plain readings for the behavioral model and reference architecture. The specification retains authority; these definitions are an on-ramp to the development snapshot.
Preview updated 5 October 2026 · clause numbers refer to the current development reference, MC-SPEC 0.4.20
Plain-English readings of the terms the site uses, in the order a newcomer meets them. The first two groups explain the inspected MC development reference. The architecture group describes intended Maneuver Calculus responsibilities and keeps them distinct from implemented capabilities. The forthcoming public specification will be a later version.
First contact — the sixteen terms you need before MC semantics
| 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 as a label and does not determine record identity, class identity or membership. | §4.1, §4.4.5 |
| Invariant core | The class-sort object identified by the stripped triple ⟨P*, m*, Q*⟩: what every aligned record structurally requires of state, mechanism and effect. The objective is not part of that identity. | §4.4.3 |
| Implementation variant | A whole maneuver record considered as a member of a stated class, with its own required elements. It is a route, not a tool; the record may satisfy several cores. | §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 | An observable grounded in a component of a stated core is spanning across its aligned records; one grounded in a record’s variation is discriminating. The latter carries the core’s support, distinguishing a known evading sibling from an unexamined possibility. | §7.2.1 |
| Detection | One detection, with its telemetry sources and dependency logic declared. Its health is derived from those dependencies. | §8.1 |
| Detection health | A detection’s status, computed through its telemetry dependencies. Evaluate blind, degraded, uncertain, then live; the first matching condition sets the status. This is an evaluation order, not a quality ranking. | §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). | Start here §0.2 |
| Invariant core A / B / C | Labels used in the retained LSASS teaching example: A reads process memory live; B writes it to disk; C executes inside the process. Their grounded record and detection mappings remain under reconciliation, so these labels are not an accepted semantic ruling. | §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 |
| Asserted, derived and measured | Asserted facts are seeded or authored; derived facts are computed by a reasoner; measured facts are established by a test against the world and carry that test. The three provenance kinds remain distinguishable. Coverage conclusions are 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 development specification’s named reference projection for collapsing a five-dimensional coverage record to a verdict. It is an option, not a default, and is distinct from an architecture query’s task-qualified view of a world revision. | §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 | The maneuver sequences consistent with partial evidence within a declared depth bound. Conclusions carry that bound and their library scope. Plausibility may order the surviving fan but cannot eliminate a member or make the preferred explanation a fact. | §11 |
| Fabricability | How cheaply a signal can be injected or forged. It is independent of robustness, which concerns evasion. High fabricability or low robustness is sufficient to flag a chain of evidence. | §7.4 |
| Coverage card | An environment-oriented summary of maneuver families, defensive controls and coverage relations. Earlier tests used cards of this kind, but those results were withdrawn for flawed methodology; the artifact format is not evidence of effectiveness. | Historical terminology |
| Paired-arm tabletop | The historical test design used paired runs with and without a card. Those results were withdrawn because the methodology was flawed. A later benchmark needs a sound comparison and evaluation design. | Historical terminology |
| 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 · not yet published on this site |
| Authorship gate | The rule for changing the ontology: quoted clause text, a balloted decision on any underdetermined choice, a signed diff. | CONTRIBUTING · not yet published on this site |
Maneuver Calculus architecture terms
These terms orient the reference architecture. They describe intended responsibilities; they do not imply that every capability is implemented or validated.
| Term | Plain reading | Where it fits |
|---|---|---|
| Maintained world-state system | The broader intended system for interpreting source material, preserving qualified claims, maintaining explicit world revisions and producing task-specific outputs. MC contributes behavioral and defensive semantics within it. | Architecture |
| Claim | A source-linked proposition with its context and qualifications. A claim being recorded or admitted does not make it universally true. | C2 · C3 · C4 |
| Support environment | The premises and dependencies supporting a conclusion together. Separate best values for trust or freshness do not establish that one complete support path has all of them. | C4 · C5 |
| Admission | A decision, under selected contracts and policy, about what may enter a world revision. Producing a compilation receipt is a separate step and does not itself grant admission. | C4 → C5 |
| World revision | An explicit version of maintained claims, support and history. Later evidence can change what a view reports without silently rewriting the provenance of earlier revisions. | C5 |
| Task-qualified projection | A query view of a stated world revision for a stated task and scope, carrying its limits. It is not a universal truth verdict, a confidentiality guarantee, or the coverage reference projection defined in MC. | C6 · C8 |
| Compilation receipt | A record of an interpretation or compilation step and the qualifications it produced. It does not prove admission, external execution or end-to-end correctness. | C4 |
| Withdrawal | A recorded change removing support or an admitted claim from the applicable current state, while preserving relevant history. Correct propagation remains a capability to verify within each implementation’s scope. | C4 · C5 |
NoteThe machine ontology (mc-core 0.4.20.2) carries
459 registry terms with an offline inspector. Its deposit stamp and archival publication
remain pending; this preview does not select the forthcoming public release.
This page is the human on-ramp, not the authority — the specification is.