What Is System Intent

Purpose

This page defines what M45 means by system intent and establishes the semantic contract used throughout the documentation.

Definition

System intent is a structured, versioned representation of the behaviors, structures, and conditions that engineering artifacts collectively imply a system is intended to exhibit.

In M45, system intent is not authored as a primary engineering artifact.

It is inferred from existing materials and made explicit so it can be reviewed, challenged, corrected, and tracked over time.

Core properties

System intent in M45 has four defining properties.

Inferred

Intent is derived by interpreting engineering artifacts such as requirements, design documents, analyses, and informal records.

Inference produces explicit hypotheses, not authoritative ground truth. See the worked example of inference for how this works in practice.

Structured

Intent is represented as discrete intent elements organized along semantic axes.

Each intent element captures a semantic claim about the system—such as a goal, constraint, hazard, behavior, hypothesis, or pragmatic assumption—and relationships between elements are made explicit through an intent graph.

Intent snapshots make explicit the reasoning, assumptions, and evidence behind why a system was believed to work, and expose where that rationale is missing or implicit. This includes pre-requirement artifacts such as hypotheses, pragmatic assumptions, risk tradeoffs, and operational constraints, which encode, imply, or reveal the absence of the reasoning and operational basis for design decisions. This allows intent to be inspected, compared, versioned, and discussed explicitly.

Versioned

System intent is captured in intent snapshots, each representing the complete interpreted state at a specific point in time.

Each intent snapshot is associated with:

  • a specific set of source artifacts
  • a Project Intent Profile that defines the semantic structure
  • a point in time
  • a recorded change history through decision records
  • evidence with type, direction, and priority (field validation is privileged over formal verification when both are available)
  • operational counter-evidence that challenges or contradicts intent elements

Intent snapshots are immutable and accumulate over time. Past snapshots remain accessible for review and audit. Safety and certification workflows ingest operational counter-evidence rather than ignoring it. See the Intent Snapshot Schema for the complete formal structure.

Contestable

Intent is reviewable by engineers.

Elements may be accepted, modified, rejected, or deferred, with decisions explicitly recorded.

What system intent is not

System intent is not:

  • a requirement
  • a design or architecture
  • a certification claim
  • a guarantee of correctness
  • a replacement for engineering judgment

System intent in M45 reflects what existing artifacts collectively imply, which may differ from the system's actual behavior or the intent engineers ultimately want to assert.

Why intent is modeled explicitly

In most engineering environments, intent exists implicitly:

  • distributed across documents
  • embedded in discussions
  • lost as artifacts evolve

M45 makes inferred intent explicit so it can be: