Worked Example: Inference and Alignment

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, but representative of real aerospace systems engineering practice.

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 elements. 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 elements 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 element 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.