Reference · development snapshot

The rules behind the reasoning

The behavioral and defensive model distinguishes maneuver identity, implementation choices, evidence quality and coverage. These rules are the development reference, with known limits kept visible.

Prose reconciled 5 October 2026 · selected development reference: MC-SPEC 0.4.20

Maneuver Calculus supplies behavioral and defensive semantics within the broader Maneuver Calculus reference architecture. That design connects cyber evidence to qualified claims, maintained world revisions and task-specific views. Here the focus is one procedure: P/M/Q — Preconditions, Mechanism and Postconditions — and its relationship to defensive control and coverage. These meanings belong to the semantic contracts; compiling candidate interpretations, admitting a revision and answering a query are separate computational responsibilities.

The reference design does not establish that every responsibility is implemented or validated. The explanatory prose below is checked against the current development reference, MC-SPEC 0.4.20. That reference is not the forthcoming public specification, and it does not establish implementation conformance. The retained worked record and diagrams still need the example reconciliation described below. Start here offers a worked introduction and the glossary expands the terms. Neither is required to understand where this behavioral layer fits.

The unit of account

The atomic modeled unit is a maneuver record: a declared precondition, mechanism, and postcondition, written {P} m {Q}. Its identity is what it structurally requires, rather than an observable effect alone. An invariant core identifies a class through the stripped triple ⟨P*, m*, Q*⟩ of requirements shared by its aligned records. External technique identifiers retain their catalog meanings. The proposed crosswalk relates them to MC content without making them MC identity; the individual mappings remain subject to verification.

A maneuver record is identified by what it structurally requires, and it aligns to every invariant core it satisfies — not by its tradecraft. The objective it serves is carried, not consulted: it names what the behaviour is for, and identifies neither the class nor the record (MC-SPEC §4.4.5). Changing an objective ascription therefore does not change record identity or class membership. Whether an observation is forged is a separate evidence question.

FIG. 1 — THE MANEUVER · { P } m { Q } OBJECTIVE serves { P } m { Q } requires yields PRECONDITION MECHANISM POSTCONDITION via INVARIANT CORE stripped triple — class identity realizes IMPLEMENTATION VARIANT one record · member of this class
Fig. 1 — A maneuver is a Hoare triple: precondition {P}, mechanism m, postcondition {Q}. A record is identified by its required elements; the stripped triple identifies a class. The objective is carried and identifies neither. An implementation variant (red) is the whole record considered as a member of a stated class. This simplified layout does not show every core a record may satisfy.
Example under reconciliationThe retained LSASS record mixes MiniDump detection with a live-read core while the adjacent explanation assigns MiniDump a separate core. Those mappings have not been adjudicated here. Read its layout as an illustration, not as an accepted coverage result or a conformance fixture.

The same anatomy, filled out as a retained illustrative maneuver record. It reads in five zones: identity, the precondition → mechanism → postcondition spine, the defender surface (observables, detection health, the prevent/detect/react grid), a detachable annex (occurrence, attribution, investigation, reconstruction), and a dashed not-yet-modeled zone marking what the calculus is still silent on.

{ μ }
Maneuver record
harvest LSASS-cached credentials · T1003.001 · mc:mLSASSCred
record · mLSASSCred
compiled 11 JULY 2026
campaign BB-2026-Q2
type altitude — reference record 13 blocks · 4 zones · read A → B → C → D tiers: core required · declare must-appear · extend detachable
Zone A identity
1 maneuver core
Harvest LSASS-cached credentials
via read credential material from LSASS process memory serves credential access · TA0006 technique T1003.001 status active chain step 3 · Black Basta 3-maneuver arc
2 objective declare
Credential access
served-by mc:mLSASSCred tactic TA0006 · credential access yield actor account credentialHeld subsumes {admin}
Zone B spine precondition → mechanism → postcondition
3 preconditions core
pre.1 adversary process integrity ≥ system
role adversary process var integrity value system op dominates ⊒ grounds obsPrivToken
holds
4 mechanism core
Read credential material from LSASS process memory
manifests as obsLSASSRead · invariant core
implementation variants — evolution ↴
MiniDump
dump-to-disk
→ userland RPM
◂ used · oc1
→ syscall / handle-dup
variant π′ — redline
yields
5 postconditions core
post.1 credentialHeld subsumes {admin}
role actor account var credentialHeld value {admin} op subsumes ⊇ grounds obsLSASSRead
forward 3 → 4 → 5 5 → 3 reverse read
6 state footprint — attached to spine declare
sf1 · @step 3
adversary process
integrity = system
sf2 · @step 3
svc_backup
credentialHeld = {admin}
sf3 · @step 4
Sysmon
controlStatus = impaired
Zone C defender surface
7 observables — keyed o1…o5 · robustness ladder L1–L5 declare
o-ref observable role robustness
o1 non-LSASS context reads LSASS credential memory spanning L5
o2 minidump (MDMP) of lsass written to disk discriminating L2
o3 userland handle to lsass with VM_READ + RPM · evidenced oc1 discriminating L3
o4 lsass read visible only via kernel / ETW-Ti discriminating L4
o5 SeDebugPrivilege / SYSTEM token present discriminating L2
8 detection health — detections · dependency logic · source control declare
faceUserlandHandle · required · Sysmon → o3 blinded
faceKernelRead · required · ETW-Ti → o4 healthy
faceMDMP · required · File/DLP → o2 healthy
faceProcLineage · required · Sysmon degraded
faceScaffolded · trigger-plus-enrichment · trig o3 / enrich lineage degraded
faceComposite · k-of-n k=2 · o3/o4/o2 healthy
faceRedundant · redundant · o3/o4 healthy
note
sf3 impairs Sysmon at step 4 — severing the source of faceUserlandHandle (blinded) and degrading faceProcLineage / faceScaffolded. The k-of-n and redundant detections still resolve on ETW-Ti + File/DLP, so the maneuver stays covered.
9 defender grid — locus × function · columns align to spine 3 · 4 · 5 declare
function ↓ / locus → 3 preconditions 4 mechanism 5 postconditions
prevent
deny local admin / SeDebug
dRemoveAdmin · invalidates pre
RunAsPPL (LSASS as PPL)
dPPL
Credential Guard (VBS)
dCredGuard
detect
absent
Sysmon ProcessAccess (EID 10) ◂ blinded
ETW-Ti / kernel callbacks
minidump-on-disk detection
dSysmon10 · dEtwTi · dMDMPScan
absent
react
absent
absent
post-compromise credential rotation
dCredRotate · evicts post
covered — hatched gap — absent
Zone D annex extend · detachable
10 occurrence — occurrence altitude · 1 card + chain extend
oc1 · step 3 · 2026-05-01T14:22:07Z
uses varUserlandRead target host FILE-SRV-04 actor acct svc_backup requires cs1 · integrity = system yields cs2 · credentialHeld = {admin}
evidence claims
ev1 · o3 · Sysmon EID 10 fab moderate ev2 · o2 · EDR file telemetry fab high ev3 · o4 · ETW-Ti fab low
campaign chain — state progression
oc1 · credential access
integrity=system → {admin}
▸ oc2 · lateral SMB
PsExec → reachable
▸ oc3 · ransomware
encrypt → dataState = encrypted
11 attribution extend
actor Black Basta campaign BB-2026-Q2 conducted-by Black Basta
12 investigation extend
“Did svc_backup obtain admin credential material?”
dfiq Q1003.001 variable credentialHeld answers inv1 · credential-access investigation discriminates hyp1 / hyp2
13 reconstruction — hypotheses bridge obv0 → obv1 extend
obv0 · integrity=system
14:20Z · conf 0.9
──▸ [ oc1 ]
hypothesized step
──▸ obv1 · credentialHeld = {admin}
14:25Z · conf 0.8
hypothesis adv cost prior parsimony consistency hyp1 · LSASS read bridged the residual leading 0.40 0.60 1 0.75 hyp2 · credential reuse (no LSASS read) 0.55 0.30 2 0.50
Zone E not yet modeled silent by design — never inferred as covered
! out of framework — the model is SILENT here; absence is not coverage
sibling paths SAM / registry-hive dump (T1003.002) · DCSync (T1003.006) · NTDS.dit (T1003.003) · remote LSASS · offline crack · LSA secrets — unmodeled, no coverage record prevent / respond no prevent- or respond-locus defensive maneuver authored against this maneuver yet — the Zone C grid reads detection only health values how to represent a signal that fires but looks authorized — unresolved; no fifth normative detection status is selected
core — ink fill declare — hairline extend — depot dash | margin red = attention · adversary · variant empty vocab: unassessed · none-known · not-applicable
mix — stacked zones · ledger buff · mono · tier ink-fill · gap hollow-box · cue order-ticks · glyph status-chips · chip inverse · annex depot-dash · gutter lane-markers · comfortable

Nothing in the not-yet-modeled zone should be read as covered. The intended discipline is to report the gap; this illustration is not benchmark evidence.

Retained draft mappingThe teaching example labels live LSASS reading A, writing memory to disk B, and execution inside the process C. These assignments and their detection mappings remain under reconciliation; this preview does not establish that each is a distinct core. MC-SPEC §4.4.3 distinguishes cores by their stripped triples ⟨P*, m*, Q*⟩, not by every difference between complete record triples. The retained example is shown in plain, cyber and formal registers on Start here §0.2.

Invariant core and implementation variant

An invariant core is the stripped triple of what every aligned record structurally requires: invariant precondition, invariant mechanism and required effect. The objective is not an identity criterion. A record's variation is what that record requires beyond a stated core; incidental details are not variations. An implementation variant is the whole record considered as a member of that class, not a tool. The same record may satisfy several cores (§4.4 and §5.2).

Spanning and discriminating describe an observable's grounding role, not the implementation variant itself. The word chokepoint, where retained in the development specification, labels invariant-core grounding; it does not replace the stripped-triple definition of class identity.

Robustness

Robustness describes a detection's resistance to evasion, using the aligned L1–L5 scale. In the development specification, grounding supports a derived grade and fixes the observable's role: core-grounded is spanning; grounded in a record's variation is discriminating. The grounding names its component and the core being considered. A missing component supplies no default grade (§7.2.1).

An empirical test may establish a separate attested grade. It is measured evidence, carried alongside the derived grade, and never overwrites it. Where the values disagree, both values and the disagreement travel with the result. The model does not establish empirical resistance merely by deriving a grounding role. A discriminating grade also carries the core's support, so a known evading sibling is distinguished from an unexamined possibility (§7.2.3).

Fabricability is a second, independent axis: how cheaply a signal can be forged. A chain relying on high-fabricability or low-robustness evidence is flagged rather than trusted (§7.4).

FIG. 2 — GROUNDING FIXES THE ROBUSTNESS ROLE (L1–L5) ROBUSTNESS L1 L2 L3 L4 L5 SPANNING core-grounded · every variant fires it A SIBLING VARIANT CLEARS THIS RUNG DISCRIMINATING · variant-grounded
Fig. 2 — Grounding supports the derived role and grade; an empirically attested grade remains a separate measured value. A core-grounded observable is spanning; one grounded in a record's variation is discriminating. The red sibling illustrates a known alternative; without a known sibling, the grade must carry that limitation. A disagreement between derived and attested grades is retained as a finding. Fabricability is independent.

Defensive control and detection health

A defensive control is the defender unit: it sources telemetry, and a maneuver's mechanism is watched through a detection. Each detection carries a four-valued health, evaluated in order: blind, degraded, uncertain, live. The first matching condition sets the status (§8.2), using a dependency logic over what it rests on (required, redundant, trigger-plus-enrichment, k-of-n). In this semantic model, a recorded loss of telemetry changes dependent health values: an unsatisfied trigger requirement makes a detection blind, while lost enrichment with a satisfied trigger makes it degraded. Dependent coverage conclusions must be recomputed; implementation of that propagation requires separate verification.

FIG. 3 — KILL A CONTROL AND THE DEPENDENCY TREE MOVES EDR ENDPOINT TELEMETRY CONTROL KILLED triggerDependsOn enrichmentDependsOn LSASS ACCESS BLIND MASS-ENCRYPTION BLIND EXFIL DEGRADED own source: network monitor EVALUATE: blind · degraded · uncertain · live
Fig. 3 — A semantic-model example of telemetry dependencies. With the EDR source down (red), the two detections whose required trigger it supplies evaluate to blind. The detection with its own network-monitor trigger loses only enrichment and evaluates to degraded. Health and dependent coverage are evaluated for a stated time; this diagram is not evidence that an implementation has verified that propagation.

Coverage

Coverage is the relation between a defensive control and a maneuver. Its constitutive discipline is that coverage MUST be derived — from declared telemetry sourcing, detection health, and robustness grounding — and MUST NOT be asserted. Where the derivation cannot be made, the calculus is silent: the honest output is "unmodeled — escalate," never an assumed verdict.

This is a semantic requirement, not an observed performance claim. Evidence that an implementation follows it must come from a scoped evaluation with an adequate methodology.

Composition and reconstruction

In the semantic model, a maneuver's postcondition can establish at least one clause another maneuver requires. The derived canUnlock edge records that partial contribution; it does not establish availability or reachability on its own (§6.2). The enablement graph may contain cycles, including self-unlock (§6.2.1). This is distinct from the acyclic detection dependency graph. At the occurrence altitude, records ground incident steps to concrete entities and their states.

The specified reconstruction model reads partial evidence: start constraints, required end conditions and observed intermediates. It enumerates consistent maneuver sequences within a declared depth bound. Every conclusion carries that bound, and a forced conclusion also carries its library scope (§11.1–§11.3).

Plausibility is a read-only ranking over the surviving fan. Its declared weighted quantities include cost, prior likelihood, parsimony, observation consistency and fabricability. It may order candidates but cannot eliminate one or turn the top-ranked candidate into a finding. Hard evidence, with the required observability conditions, supplies elimination; only what every survivor shares is forced.

Alignment

The calculus is framework-neutral. Its intended alignment to ATT&CK, D3FEND, Summiting the Pyramid, and DFIQ uses crosswalks rather than import or subclassing. The proposed mappings retain external catalog definitions and state an MC subject, external target, relation and catalog version. These explanatory proposals do not establish that a concrete binding has been implemented or verified.

NoteThe full specification, ontology, and worked examples are still in development. This page explains the inspected development reference; it neither publishes a new normative release nor claims full conformance. The inspected mc-core 0.4.20.2 package did not establish attackTechniqueId or dfiqId as current core properties; the separate binding definition remains unverified.