Worked Example: Inference and Alignment
Workflow note
This example illustrates the target semantic flow from inferred meaning to snapshot-oriented interpretation. In the current product, the equivalent user flow is iteration-based and runs through review units, hypotheses, exceptions, and recommendations.
Key terms
Artifact: Any recorded material — such as a requirement, design document, or safety analysis — that expresses, implies, or constrains system meaning. In this example, R1–R3 are the source artifacts.
Intent hypothesis: A structured claim about what the system is intended to achieve, inferred from one or more artifacts. Hypotheses are organized along semantic axes (e.g. functions, modes, safety themes) and carry confidence and criticality levels.
Intent axis: A semantic dimension used to organize inferred intent. M45 defines six default axes: components, functions, modes, scenarios, interfaces/signals, and safety themes. See intent axes.
Intent snapshot: An immutable, versioned record of all inferred intent at a specific point in time. It bundles source artifacts, intent hypotheses, an intent graph, and links to decision records. Snapshots accumulate — they are never overwritten.
Iteration: One pass through the review cycle. An iteration groups the work of analyzing, reviewing, and deciding on intent for a set of requirements.
Review unit: A cluster of requirements selected for joint review. In practice, requirements are grouped along intent axes so that related obligations are analyzed together.
Exception: A problem found during alignment checks — for example, an intent hypothesis with no supporting requirement, contradictory requirements, or an ambiguous obligation.
Recommendation: A proposed change (rewrite, addition, or new requirement) generated to resolve an exception.
Decision record: A record of a human decision made during or after review — such as accepting, editing, or rejecting a hypothesis or recommendation. Decision records preserve the rationale and authority behind each change.
Purpose
This example illustrates how M45 infers system intent from engineering artifacts and identifies semantic misalignment, even when individual artifacts appear reasonable in isolation.
The example is simplified.
Source artifacts
Consider the following requirements from a navigation system specification.
R1
The FMS NAV software shall compute a navigation solution using GNSS inputs.
R2
The FMS NAV software shall update navigation outputs at a rate not less than 10 Hz.
R3
In protected mode, the system shall limit reliance on GNSS signals and prioritize inertial and available radio navigation sources to maintain situational awareness.
Each requirement is syntactically valid and commonly accepted in isolation.
Inferred system intent
From these requirements, M45 infers the following intent hypotheses. These are organized along semantic axes as defined in M45.
Components
- Flight Management System Navigation Software
- GNSS Receiver
- Inertial Navigation Source
- Radio Navigation Source
These components are inferred because they are referenced explicitly or implicitly across the requirements. See the default axis definitions for more on component intent.
Functions
- Compute navigation solution
- Update navigation outputs
- Limit reliance on GNSS
- Prioritize navigation sources
Note that R3 expresses multiple functions in a single requirement. See the default axis definitions for more on function intent.
Modes
- Protected mode
The existence of a distinct operational mode is inferred from R3. See the default axis definitions for more on mode intent.
Scenarios
- Degraded navigation conditions
This scenario is inferred because protected mode implies a contextual condition, even though it is not explicitly named. See the default axis definitions for more on scenario intent.
Interfaces and signals
- GNSS input signals
- Navigation solution output
Inputs and outputs are inferred even though signal definitions are not provided. See the default axis definitions for more on interface and signal intent.
Safety themes
- Graceful degradation
- Fault tolerance through source prioritization
These themes are inferred from the safety-relevant behavior described in R3. See the default axis definitions for more on safety theme intent.
Intent snapshot
At this stage, M45 holds an intent snapshot that can be summarized as:
- Components: FMS NAV software, GNSS receiver, inertial and radio navigation sources
- Functions: navigation computation, output updates, source prioritization
- Modes: protected mode
- Scenarios: degraded navigation conditions
- Safety themes: graceful degradation, fault tolerance
This intent snapshot is immutable, versioned, and linked to the source artifacts (R1–R3). It includes structured intent hypotheses organized by semantic axes, and an intent graph capturing relationships between elements.
Alignment analysis
M45 evaluates how well the requirements support the inferred intent.
Incomplete function support
The function “Prioritize navigation sources” is inferred from R3.
However:
- No requirement defines prioritization rules
- No requirement specifies source precedence beyond GNSS vs others
Result:
- Intent hypothesis present
- Requirement support partial
M45 flags a potential gap for review.
Mode scope ambiguity
The inferred protected mode lacks:
- Entry conditions
- Exit conditions
- Defined behavior outside the mode
This creates ambiguity about system operation and transitions.
M45 flags underspecified mode semantics.
Performance misalignment
The 10 Hz update rate in R2:
- Is not scoped to any mode
- May conflict with degraded operation in protected mode
This introduces a possible contradiction.
M45 flags a potential misalignment between performance expectations and mode-dependent behavior.
What M45 does and does not do
M45 does:
- Make inferred intent explicit
- Highlight semantic gaps and ambiguities
- Preserve traceability to source artifacts
M45 does not:
- Judge correctness of the design
- Decide whether 10 Hz is sufficient
- Resolve ambiguities automatically
Engineer interaction
An engineer may respond by:
- Splitting R3 into atomic requirements
- Adding requirements defining protected mode behavior
- Clarifying update rate expectations per mode
All changes are recorded through new intent snapshots (which are immutable and accumulate) and decision records. See the example of correcting incorrect inference for how this process works.
Key takeaway
Even well-formed requirements can hide misalignment.
M45 surfaces implicit assumptions early, before they harden into downstream documentation and design debt.