Understand one maneuver

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.

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. The retained illustration uses three draft labels: 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.

A maneuver record is a Hoare triple {P} m {Q} — a precondition it requires, a mechanism, a postcondition it yields (§4.1). The record is identified by what it structurally requires (§4.4.2). A class is identified by 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).

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.

Assume a hypothetical control blocks the required live-read mechanism in the stated environment. Under that premise, a record aligned to A cannot reach its effect through that mechanism, whether its implementation uses a userland read or another route. This teaches how a preventive result transfers through a shared requirement. The draft labels B (dump to disk), C (execute inside), and the unmodeled sibling paths — SAM-hive, DCSync, NTDS.dit, LSA secrets — need their own coverage evidence. The example leaves their outcomes open.

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).

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.

Detection health follows each detection’s declared dependencies. Assume the userland-handle detection loses its required trigger, while the separate read and file sensors retain their triggers, collection paths and all other requirements for live status at the stated time. The semantic rules then yield one blind detection and two live detections. This is a dependency calculation under stated premises. The retained MiniDump mapping is described above; the health calculation leaves that classification question open. Zone E lists SAM-hive, DCSync, NTDS.dit, remote LSASS and LSA secrets as paths awaiting their own modeled records.

Each detection face carries a four-valued status, evaluated in order — blind, degraded, uncertain, live — with the first matching condition setting the status (§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).

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.

For the upper row, assume that every required live read produces the modeled signal, that collection delivers it intact, and that the rule evaluates it successfully at the stated time. Under these premises, the core-grounded observable (o1, spanning, L5 in the retained illustration) supports a detection result across aligned records. The lower row retains the draft minidump-file observable (o2, discriminating, L2): its rule observes that file when it is produced and collected. A route producing no such file falls outside that rule’s established detection scope. Grounding describes the reach of the result; testing supplies evidence for a real sensor, rule and environment.

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.