{μ} Maneuver Calculus v0.4.20 — current
Sheet MC-02
Working draft MC-SPEC 0.4.20 · mc-core 0.4.20.2 — specification and ontology prepared; not yet published on this site
Overview/Start here

0Start here

Last updated 23 August 2026 · written against MC-SPEC 0.4.20

This page is the on-ramp. It answers three questions in order — what the calculus is for, what one maneuver looks like worked end to end, and how it sits next to the frameworks you already use — before the framework page states the system formally. Dotted terms link to the glossary.

0.1The thirty-second version

Security teams answer coverage questions from a control inventory: the EDR is deployed, the rule is enabled, so the technique is covered. That inventory cannot tell you that the rule's telemetry died last Tuesday, that the rule keys on a filename the adversary changes for free, or that nobody ever tested whether it fires.

Maneuver Calculus models one adversary procedure at a time — what it needs, what it does, what it leaves behind — and derives the coverage answer from what your detections are actually keyed on and actually receiving, instead of taking anyone's word for it. Where the model cannot derive an answer it returns the gap rather than a verdict: an unmodeled behavior is never reported as covered.

Reading ladder
30 sThis section. The problem and the one idea.
3 min§0.2–0.3 below. One maneuver worked end to end; MC for ATT&CK users.
10 minGlossary · FAQ. The sixteen terms you need first; status, version, citing, contributing.
40 minFrameworkResultsAlignment. How it works, whether it works, how it aligns.
HoursMC-SPEC 0.4.20 · mc-core 0.4.20.2. The normative text and the machine ontology — prepared, not yet published here.

0.2One maneuver, three ways

The same structure, in three vocabularies. Flip the register and every plate below keeps its shape while its words change: a physical analogy (a bank robbery), the cyber case (LSASS credential dumping, T1003.001), and the formal model (spec notation, ontology terms, axioms). If the plain telling and the specification carry the same shape, the notation was never the hard part — the modelling underneath it was. The physical column is an analogy register, a teaching aid, never a synonym for the fixed vocabulary.

Register
Plate 1 · One maneuver, start to finish
Physical · analogy
Fig. A One maneuver · need · do · get The goal Get through the back door serves Before reach · move · turn the lock The move Defeat the lock After the lock is open requires yields precondition mechanism postcondition identifies The part that cannot change all three boxes, taken together realized by pick the lock forge a key
Fig. A — A thief disabling the lock on a bank’s back door. The part that cannot change is all three boxes together; underneath sit swappable ways of doing it.

A thief disabling the lock on a bank’s back door. Before, they must reach the lock, move the pins, and turn it; the move is to defeat the lock; after, the lock is open and the door lets them through. The part that cannot change is all three boxes taken together — change any one and it is no longer the same maneuver. Underneath sit two ways of doing it: pick the lock, or forge a key. A rake pick, a hook pick, this gang’s tools — all still “pick the lock” to us. One entry, not fifty.

Cyber · LSASS
Fig. A One maneuver · { P } m { Q } Objective Credential access · TA0006 serves Precondition process integrity ⊒ system Mechanism read LSASS memory Postcond. credentialHeld ⊇ {admin} requires yields precondition mechanism postcondition identifies Invariant core A · read it live the reading is what cannot be dropped realized by userland read syscall · handle-dup
Fig. A — Reading credential material out of LSASS: precondition {P}, mechanism m, postcondition {Q}. This is invariant core A; the tool used is a swappable variant.

An operator already at SYSTEM integrity reads credential material out of LSASS. That need·do·get is invariant core A — read it live. Underneath are swappable variants: a userland read, a syscall/handle-dup route. LSASS actually carries three cores, not one: A read memory live, B write it to disk (which yields a file, not yet a credential), C execute inside LSASS (A’s ending, reached with write access rather than an outside read). This plate is core A. Which tool ran is tradecraft; the reading itself is what cannot be dropped.

Formal · spec
Fig. A { P } m { Q } mc:Objective carried, not consulted serves { P } ⋀ ConditionPattern m composesPrimitive { Q } yields requires yields precondition mechanism postcondition identifies ⟨ P*, m*, Q* ⟩ what every aligned record requires · §4.4.3 realized by ImplementationVariant one route · §5.2
Fig. A — A maneuver record is a Hoare triple {P} m {Q}; the stripped triple ⟨P*, m*, Q*⟩ it aligns to is the invariant core.
i · spec notation
A maneuver is a Hoare triple {P} m {Q} (§4.1). Identity is the stripped triple ⟨P*, m*, Q*⟩; two cores differing in any component are distinct (§4.4.3). Required = removing it stops the effect (§4.4.3.1).
ii · ontology terms
mc:ManeuverRecord · mc:InvariantCore (disjoint individuals) · mc:ImplementationVariant ⊑ mc:ManeuverRecord. Clauses via mc:hasPreconditionClause/mc:hasPostconditionClause, body mc:composesPrimitive; core via mc:coreRequiresState (P*), mc:invariantComposes (m*), mc:coreRequiresEffect (Q*); mc:alignsToCore derived; mc:serves an mc:Objective.
iii · axioms / rules
A record aligns to every core it satisfies (§4.4.5.3). The objective is carried, not consulted, and MUST NOT identify a class, a record, or membership (§4.4.5). Membership is a test, not a roster (§4.4.5.1).

A maneuver record is a Hoare triple {P} m {Q} — a precondition it requires, a mechanism, a postcondition it yields (§4.1). Its identity is the stripped triple ⟨P*, m*, Q*⟩, what every aligned record structurally requires; two cores differing in any component are distinct (§4.4.3). An element is required exactly when removing it stops the record reaching its effect (§4.4.3.1). A tool realizes the core but is not part of it — the trivial core ⟨∅,∅,∅⟩ is never named (§4.4.5.3).

Plate 2 · One goal, several maneuvers
Physical · analogy
Fig. B One goal · four maneuvers The goal Get through the back door four ways to the same goal Maneuver 1Disablethe lock Maneuver 2Blowthe door Maneuver 3Take thehinges off Maneuver 4Get someoneto open it defence here Stops every way of doing Maneuver 1 — a real win. But the goal still stands: three maneuvers you did not block.
Fig. B — One goal, four genuinely different maneuvers. Blocking Maneuver 1 completely is a real win — and it does nothing to the other three.

One goal, four genuinely different maneuvers: disable the lock, blow the door, take off the hinges, or get a person to open it. You fit a lock whose pins cannot be moved — so Maneuver 1 stops in every way of doing it, including ways nobody has written down. That is a real, honest win; say it that way. But you did not block the goal: three other maneuvers reach it and your lock does nothing about them. And if you had blocked only rake picks, you would not even have blocked Maneuver 1.

Cyber · LSASS
Fig. B One objective · several cores Objective Credential access four ways to the same goal Core Aread LSASSlive Core Bdump todisk Core Cexecuteinside SiblingsSAM · DCSyncNTDS.dit acts on core A Transfers to every A-variant — userland, syscall, uncatalogued. Nothing stops the objective; B, C and the siblings are untouched.
Fig. B — One objective reached by several cores. A control on core A leaves cores B and C and the unmodeled sibling paths untouched.

The objective — credential access — is reached by several maneuvers. RunAsPPL and Credential Guard act on core A (read LSASS live), so they stop every variant of A: userland read, syscall/handle-dup, and any route not yet catalogued. They do nothing to core B (dump to disk), core C (execute inside), or the unmodeled sibling paths — SAM-hive, DCSync, NTDS.dit, LSA secrets. A defence stops a whole maneuver, or one way of doing one maneuver; nothing stops the objective. A control keyed only on minidumps would not even stop core A.

Formal · spec
Fig. B Objective → {records} mc:Objective identifies neither sort · §4.4.5 four aligned records record → core Abreak onP* / m* distinct coreother{ Q } distinct coreother{ P } unmodeledrecords§10.4 breaksManeuver Transfers on the core, class-wide · §4.7.1 Scope is core-relative (§4.7.3); the objective is not a criterion.
Fig. B — An mc:Objective served by several records; a break transfers class-wide only when it acts on the invariant core.
i · spec notation
A placement structurally breaks a maneuver when it stops it reaching its effect; a detect placement never breaks anything (§9.2). Transfer holds iff the placement acts on the core (§4.7.1).
ii · ontology terms
mc:breaksManeuver · mc:alignsToCore · mc:tierAgainstCore · mc:serves / mc:Objective. Distinct cores are distinct mc:InvariantCore individuals.
iii · axioms / rules
Scope lattice (§4.7.3): core → class-wide; several variations → those records; one variation → that record alone. Read against a stated core. Unmodeled MUST NOT be reported as covered (§10.4).

A placement structurally breaks a maneuver when it stops it reaching its effect; a detect placement never breaks anything (§9.2). A result transfers to every aligned record exactly when the placement acts on the invariant core; acting on one record’s variation is a result for that record alone (§4.7.1). Scope follows a lattice: core → class-wide; several variations → those records; one variation → that record (§4.7.3). The mc:Objective is carried, not a criterion (§4.4.5).

Plate 3a · Coverage — who is actually watching
Physical · analogy
Fig. C Who is actually watching The back-door job one blind, two watching — still seen Camera on the lock unplugged — blind Strong-room guard watching Delivery ledger recording ! Doors you never drew a plan for a missing door is not a guarded door — a gap, escalated
Fig. C — Coverage is not a colour on a chart. One watcher blind, two still watching — and doors you never drew a plan for are not guarded doors.

Coverage is not a colour on a wall chart. One camera is unplugged — that watcher is blind — but the strong-room guard and the delivery ledger still watch, so this maneuver stays seen. What you never drew a plan for is a different matter: a door missing from your drawings is not a guarded door. Silence there is a gap to escalate, never a tick in the “covered” column.

Cyber · LSASS
Fig. C Detection health · core A Core A read LSASS live core A still seen faceUserlandHandle Sysmon → blind faceKernelRead ETW-Ti → healthy faceMDMP File / DLP → healthy ! Zone E — SAM · DCSync NTDS.dit · LSA secrets — no record at all
Fig. C — Detection health is four-valued and derived from the telemetry beneath each face. Impairing Sysmon blinds one face; two survive. Zone E has no record at all.

Detection health is four-valued and derived from the telemetry underneath, not read off a dashboard. Impairing Sysmon blinds faceUserlandHandle; faceKernelRead (ETW-Ti) and faceMDMP (File/DLP) stay healthy, so core A is still seen. Health is computed, so killing one source moves every verdict resting on it. Separately, the Zone E sibling paths — SAM-hive, DCSync, NTDS.dit, remote LSASS, LSA secrets — have no record at all. Unmodeled is not covered: the honest output is the gap, escalated. Not tested is not covered either.

Formal · spec
Fig. C Coverage record · faces coverage record health computed, not asserted status: blind trigger unmet · §8.2 spanning o1 · L5 core-grounded discriminating o2 variation-grounded ! unmodeled MUST NOT be reported as covered · §10.4
Fig. C — A coverage record carries each face’s status (§8.2). Unmodeled is silence, escalated — never a covered verdict (§10.4).
i · spec notation
Face status is four-valued — live ≻ degraded ≻ uncertain ≻ blind — evaluated in order over grounded telemetry (§8.2). Silence over assumption (§10.4).
ii · ontology terms
Faces ground observables; o1 spanning (L5, core), o2/o3 discriminating (L2/L3, variation). Health flows from control state through the grounding chain.
iii · axioms / rules
A maneuver with no record, a sibling never modeled, a cell never authored are all unmodeled and MUST NOT be reported as covered; absence of a record is not evidence of coverage (§10.4, §4.3.3).

Each detection face carries a four-valued status — live, degraded, uncertain, blind — evaluated over the telemetry it grounds on (§8.2); a face is blind when its trigger requirement is unsatisfied. A maneuver with no record, a sibling path never modeled, and a cell never authored are all unmodeled, and unmodeled MUST NOT be reported as covered; absence of a record is not evidence of coverage (§10.4).

Plate 3b · Coverage — where the win travels
Physical · analogy
Fig. D Where the win travels On the part that cannot change un-pickable pins covers the whole class beats pick, forge & any unwritten way On one way of doing it a sign: “no rake picks” one route not covered stops the rake only — not the hook, not forging
Fig. D — Where the defence lands decides how far the win travels: the part that cannot change beats every way; one particular way beats only itself.

Where the defence lands decides how far the win travels. Un-pickable pins act on the part that cannot change, so they beat every way of picking — and ways nobody has written down. A sign reading “no rake picks” acts on one particular way; it stops the rake and nothing else — not the hook pick, not forging. Same door, two very different claims, with very different lifetimes.

Cyber · LSASS
Fig. D Transfer · core vs variation On the core ETW-Ti: any non-LSASS read of LSASS (o1, L5) covers the whole class fires for userland, syscall & uncatalogued On a variation minidump-on-disk file rule (o2, L2) one route not covered stops the MiniDump route only — swap and it is silent
Fig. D — A detection keyed on the core (spanning, L5) fires for every variant; one keyed on a variation (discriminating, L2) covers only that route.

A detection keyed on the invariant core — “a non-LSASS context reads LSASS credential memory,” visible via ETW-Ti (o1, spanning, L5) — fires whichever variant of core A ran: userland read, syscall/handle-dup, or a route not yet catalogued. That result transfers across the whole class. A detection keyed on a variation — the minidump written to disk (o2, discriminating, L2) — covers only that route; swap to a userland read and it is silent. Grounding fixes the scope.

Formal · spec
Fig. D Scope of a placement placement on m* (the core) covers the whole class transfers to every aligned record · §4.7.1 placement on one record’s variation one route not covered result for that record alone · §4.7.3
Fig. D — A placement on m* has class-wide scope; a placement on one record’s variation has single-record scope (§4.7).
i · spec notation
Transfer (§4.7.1): a result against one aligned record transfers to all iff the placement acts on the invariant core; a variation-placement is that record alone.
ii · ontology terms
mc:alignsToCore (derived) · mc:tierAgainstCore · mc:ImplementationVariant. Core-grounded ⇒ spanning; variation-grounded ⇒ discriminating.
iii · axioms / rules
Scope lattice (§4.7.3): core → class-wide; one variation → that record. Grounding fixes role (§7.2.1): the core buys class-wide coverage, a variation buys one record.

The transfer rule (§4.7.1): a defensive result established against one aligned record transfers to every aligned record exactly when the placement acts on the invariant core. A placement on a record’s variation establishes a result for that record alone. Grounding fixes role — core-grounded is spanning, variation-grounded is discriminating (§7.2.1) — and the scope lattice (§4.7.3) reads the reach off where the placement lands.

Why this mattersIn the paired-arm tests, the arm without the calculus asserted "covered, high robustness" for behaviours it could not see — DCSync, a cloud domain outside the model. The arm with it returned the gap. That difference is the whole point; see Results §2.3.

0.3If you already use ATT&CK

Maneuver Calculus does not replace ATT&CK and does not fork it. Tactics and technique IDs stay exactly where they are: objectives map to tactics, technique IDs live on the technique and are carried, never redefined. Alignment is by SKOS mapping — exactMatch, closeMatch, relatedMatch — never by subclassing into another taxonomy.

What differs is altitude. ATT&CK names what a behaviour is; the calculus works one level below, at the individual procedure, where a maneuver is defined by what it requires and what it yields rather than by its label. Many procedures implement one technique, so the relation is many-to-many.

What that buys you is three things a coverage matrix does not attempt. Pre- and postconditions link into a computed graph of what a step makes possible next. Each detection carries a four-valued health derived from the telemetry beneath it, so killing one control moves every verdict that rested on it. And "covered" stops being a colour on a matrix and becomes a record of five separately-derived dimensions — is something breaking this, is anything still watching, what is it keyed on, has it been shown to work, does it fire on benign activity too. Where the model can't answer, it says unmodeled and escalates. The full matrices are on the alignment page.

0.4What you can do today

0.5Where to go next

Next is the framework — the shape of the system in seven parts. It assumes you have read §0.2 above. If a paragraph there is doing too much work, the glossary carries the plain reading of every term.

Apache-2.0 · © The Maneuver Calculus contributors · Glossary · FAQ · Governance