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.
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.
{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.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.
dump-to-disk → userland RPM
◂ used · oc1 → syscall / handle-dup
variant π′ — redline
integrity=system → {admin} ▸ oc2 · lateral SMB
PsExec → reachable ▸ oc3 · ransomware
encrypt → dataState = encrypted
14:20Z · conf 0.9 ──▸ [ oc1 ]
hypothesized step ──▸ obv1 · credentialHeld = {admin}
14:25Z · conf 0.8
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.
⟨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).
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.
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.
attackTechniqueId or
dfiqId as current core properties; the separate binding definition remains
unverified.