Intent Axes

Purpose

This page defines how system intent is structured in M45.

Axes as semantic structure

System intent is expressed along semantic axes.

Each axis captures one dimension of meaning implied by engineering artifacts.

Intent elements in intent snapshots are organized along these axes. Each intent element has an axisId field that classifies it under a specific axis.

Axes are:

The axes described here represent a default axis set commonly used in safety-critical aerospace systems. They are neither exhaustive nor mandatory.

Default intent axes

Components

Identifiable physical or logical system parts treated as distinct units in engineering artifacts.

Examples:

  • Flight Management System
  • Navigation Sensor

Non-examples:

  • “shall compute”
  • Quality attributes

Not all projects require explicit component-level intent.

Functions

Intended transformations, computations, or actions performed by the system or its components.

Examples:

  • Compute navigation solution
  • Monitor signal integrity

Functions describe what is done, not how it is implemented.

Modes

Operational states that alter system behavior or interpretation of inputs and outputs.

Examples:

  • Normal operation
  • Protected mode

Modes represent persistent states, not transient events.

Some systems may model behavior without explicit modes.

Scenarios

Contextual situations under which specific behavior applies.

Examples:

  • Loss of GNSS signal
  • Degraded sensor availability

Scenarios describe circumstances, not system states.

Interfaces and signals

Identifiable exchanges of information between system elements or with external systems.

Examples:

  • Navigation output
  • Control input command

Abstract information flow without endpoints is not considered an interface.

Safety themes

Recurring intent patterns related to preventing, detecting, or mitigating unsafe behavior.

Examples:

  • Fault detection and isolation
  • Graceful degradation

Safety themes express intent patterns, not hazard analyses.

They may be omitted or replaced depending on organizational practice.

Axis configurability and extension

M45 does not assume a single axis set is sufficient for all contexts.

Axes may be:

  • Enabled or disabled per project (see Project Intent Profile)
  • Extended with domain-specific axes
  • Refined with narrower definitions

Examples of additional axes used by some teams include:

  • Environmental assumptions
  • Performance characteristics
  • Human interaction roles
  • Allocation boundaries

An axis is valid if:

  • Its intent elements can be inferred from artifacts
  • Its intent elements can be reviewed and decided upon by engineers
  • Its semantics are explicitly defined

M45 treats axes as schema elements, not hard-coded concepts. See the Axis Definition Schema for the formal structure.

Relationship to intent snapshots

Axes define the semantic structure under which intent elements are organized in intent snapshots.

Each intent element in a snapshot includes an axisId field that references the axis under which it is classified. The axes enabled for a project are declared in the Project Intent Profile, and each intent snapshot is evaluated relative to a specific profile.

Intent elements also have an intentKind field (such as goal, requirement, hypothesis, pragmatic_assumption, etc.) that is independent of the axis classification. Pre-requirement artifacts (hypotheses, pragmatic assumptions, risk tradeoffs, operational constraints) can be classified along any axis, just like other intent elements.

This ensures that:

  • Intent elements are consistently classified
  • The semantic structure is explicit and auditable
  • Historical snapshots preserve the axis context under which they were created