Default Intent Axis Definitions
Normative framing
- Axes define how intent is structured, not what intent must exist
- Axes are independent and optional
- Absence of an axis does not imply missing intent
- Presence of an axis does not imply completeness
Intent elements in intent snapshots are classified under these axes via the axisId field. The axes enabled for a project are declared in the Project Intent Profile.
If project-specific axes are defined, they should follow the same structure and clarity as the defaults below. See the Axis Definition Schema for the formal structure.
Default axis set
The following axes are included by default in M45.
Each axis definition includes:
- A semantic definition
- Inclusion criteria
- Typical artifact sources
- Examples and non-examples (each with a short rationale explaining why it is an example or non-example)
Axis: component
Definition
A component is an identifiable physical or logical system part treated as a distinct unit in engineering artifacts.
Inclusion criteria
- Has a recognizable boundary in artifacts
- Is referenced consistently enough to be disambiguated
- Can participate in relationships with other intent elements (via the intent graph)
Typical sources
- Requirements naming system parts
- Architecture descriptions
- Interface documentation
- Design diagrams
Examples
| text | rationale |
|---|---|
| Flight Management System | Treated as a bounded unit in requirements/architecture artifacts. |
| Navigation Software Module | A named logical subsystem with a stable boundary in design documentation. |
| GNSS Receiver | A distinct hardware element referenced consistently across artifacts. |
| Power Distribution Unit | A physical unit with clear interfaces and responsibilities. |
Non-examples
| text | rationale |
|---|---|
| "shall compute" | Describes an action; it belongs under the function axis. |
| "high availability" | A quality/constraint theme, not a bounded system part. |
Axis: function
Definition
A function is an intended transformation, computation, or action performed by the system or its components.
Inclusion criteria
- Describes what is done, not how it is implemented
- Can be scoped by modes or scenarios
- Can be traced to one or more artifacts
Typical sources
- Functional requirements
- Operational descriptions
- Interface behavior descriptions
- Test intent and procedures
Examples
| text | rationale |
|---|---|
| Compute navigation solution | An intended computation the system performs. |
| Update navigation outputs | An intended transformation of internal state into outputs. |
| Monitor signal integrity | An intended monitoring action performed by the system. |
| Generate alert | An intended system action that produces a notification. |
Non-examples
| text | rationale |
|---|---|
| "shall be reliable" | A quality expectation/constraint theme, not a specific transformation/action. |
| "shall comply with standard X" | A compliance/assurance claim, not a system function. |
Axis: mode
Definition
A mode is a persistent operational state that alters system behavior or interpretation of inputs and outputs.
Inclusion criteria
- Meaningfully distinct from other states
- Persists until exit conditions apply
- Affects functional behavior or constraints
Typical sources
- Requirements referencing operational states
- Mode logic descriptions
- State machine artifacts
- Degraded-operation descriptions
Examples
| text | rationale |
|---|---|
| Normal operation | A persistent operational state with distinct behavior. |
| Initialization mode | A persistent state with different interpretation of inputs/outputs. |
| Protected mode | A persistent state that constrains/changes behavior. |
Non-examples
| text | rationale |
|---|---|
| One-time events | Events do not persist as modes. |
| Failure descriptions without state semantics | A fault description without an operational state definition. |
Axis: scenario
Definition
A scenario is a contextual situation or set of conditions under which specific behavior is intended to apply.
Inclusion criteria
- Describes circumstances, not system state
- Can scope behavior, constraints, or expectations
- May reference modes but is not equivalent to them
Typical sources
- Operational concepts
- Degraded condition descriptions
- Use-case narratives
- Scenario catalogs and operational narratives
- Test procedures and test case catalogs
Examples
| text | rationale |
|---|---|
| Loss of GNSS signal | A contextual condition that scopes behavior/constraints. |
| Transition from ground to flight | An operational context under which behavior changes. |
| Degraded sensor availability | Contextual conditions that scope expected behavior. |
| GNSS signal loss during approach with inertial fallback enabled | A concrete scenario used to exercise and observe hazard-relevant behavior (often used in V&V). |
| Degraded sensor availability with alerting thresholds at nominal limits | A concrete scenario used to validate alerting behavior under defined conditions. |
Non-examples
| text | rationale |
|---|---|
| Persistent operational states | These are modes, not scenarios. |
| Abstract conditions without behavioral impact | Without scoping behavior/constraints, it is not a meaningful scenario axis element. |
Axis: interface
Definition
An interface is an identifiable interaction boundary between system elements or between the system and its environment.
Inclusion criteria
- Has identifiable endpoints
- Supports one or more interactions
- Directionality is known or explicitly undefined
Typical sources
- Interface control documents
- Architecture diagrams
- Integration test descriptions
Examples
| text | rationale |
|---|---|
| FMS to Autopilot interface | A clear interaction boundary between two system elements. |
| External data bus interface | A defined boundary supporting interactions and signals. |
Non-examples
| text | rationale |
|---|---|
| Vague information flow without endpoints | Lacks identifiable endpoints/boundary. |
Axis: signal
Definition
A signal is an identifiable unit of information exchanged over an interface.
Inclusion criteria
- Has a recognizable name or description
- Has an implied producer and consumer
- Can be traced to an interface or interaction
Typical sources
- Interface specifications
- Data dictionaries
- Telemetry definitions
Examples
| text | rationale |
|---|---|
| Position estimate output | A named information item exchanged across an interface. |
| Health status flag | A distinct data item with producer/consumer semantics. |
| Control input command | A discrete information unit sent across an interface boundary. |
Non-examples
| text | rationale |
|---|---|
| Abstract "system data" without defined meaning | Not a distinct signal with clear semantics. |
Axis: hazard
Definition
A hazard is a system-level hazardous state that could lead to unacceptable loss (not a component failure mode).
Inclusion criteria
- Describes an unsafe system state with loss consequences
- Is stated at system level (may involve multiple components)
- Is meaningful independent of a specific root-cause failure
Typical sources
- Safety analyses (STPA/FTA/FHA)
- Hazard logs
- Requirements and operational descriptions
Examples
| text | rationale |
|---|---|
| Loss of navigation capability during approach | An unsafe system condition with safety consequences. |
| Erroneous altitude guidance displayed to crew | A hazardous system state that can lead to unsafe decisions. |
Non-examples
| text | rationale |
|---|---|
| GNSS receiver power supply fails | A component failure mode; it may contribute to a hazard but is not itself the hazardous state. |
| Loss of GNSS signal | A context/scenario; the hazard is the unsafe system state that results if uncontrolled. |
Axis: safetyConstraint
Definition
A safety constraint is a constraint derived from hazards that limits behavior or design to prevent or mitigate unsafe system states.
Inclusion criteria
- Restricts behavior or design in a hazard-relevant way
- Can be traced to one or more hazards it mitigates
- Is actionable enough to be reviewed for adequacy/coverage
Typical sources
- Safety requirements
- Safety analyses
- Requirements and verification plans
Examples
| text | rationale |
|---|---|
| The system shall transition to inertial navigation within 100 ms of GNSS signal loss during approach | Constrains behavior to mitigate loss of navigation capability. |
| The system shall inhibit autopilot engagement when air data validity is unknown | Constrains control to mitigate hazardous states. |
Non-examples
| text | rationale |
|---|---|
| The system shall be safe | Too vague to be an actionable constraint. |
| The system shall compute navigation solution | A function statement, not a hazard-derived constraint. |
Axis: uca
Definition
An unsafe control action (UCA) is a control action that, under certain contexts, can lead to hazards or losses (STPA-style).
Inclusion criteria
- Identifies a control action
- Includes context that makes it unsafe (provided/omitted/too early/too late/too long)
- Can be connected to hazards via reasoning/artifacts
Typical sources
- STPA analyses
- Safety analyses and review notes
Examples
| text | rationale |
|---|---|
| Autopilot engages climb mode when airspeed is below minimum safe threshold | A control action unsafe in a specific context. |
| Navigation system suppresses integrity alert during approach | An omission that can be unsafe in context. |
Non-examples
| text | rationale |
|---|---|
| The autopilot shall have a climb mode | A capability/feature statement, not an unsafe control action. |
| Loss of navigation capability during approach | A hazard, not a control action. |
Axis: verificationObjective
Definition
A verification objective captures verification/validation intent: what must be verified or validated, and (when applicable) the criteria used to judge acceptability.
Inclusion criteria
- States what is to be verified/validated (not the evidence itself)
- Can be linked to intent elements and to planned methods
- Is reviewable for completeness and adequacy
- Includes criteria (thresholds, timing bounds, pass/fail conditions) when those criteria are part of the objective's meaning
Typical sources
- Verification plans
- Test plans and verification matrices
- Certification planning artifacts
- Acceptance criteria documents
- Test specifications
Examples
| text | rationale |
|---|---|
| Verify navigation accuracy constraint is satisfied under approach conditions | States what must be verified and under what context. |
| Validate integrity alert behavior with operational flight test data | States a validation objective and expected evidence class. |
| Horizontal position error shall remain <= 10 m (95%) during nominal approach | A checkable acceptance criterion used to judge whether the navigation accuracy objective is met. |
| Alert shall be issued within 2 seconds of integrity threshold crossing | A measurable pass/fail criterion that makes the objective reviewable and testable. |
Non-examples
| text | rationale |
|---|---|
| Test report TR-123 shows pass | An evidence result, not an objective. |
| Compute navigation solution | A function; it is what the system does, not what must be verified. |
| High performance | Too vague to serve as an objective or as an acceptance criterion. |