Intent Snapshot Schema

Purpose

The intent snapshot is the central record unit in M45.

It exists to:

• Capture interpreted system intent explicitly
• Preserve intent across abstraction levels
• Bind meaning to a stable semantic structure
• Preserve historical interpretation and rationale
• Enable traceability, audit, and safety review

Intent snapshots do not overwrite one another.

They accumulate.

Normative principles

• An intent snapshot is immutable
• Each snapshot is evaluated under exactly one Project Intent Profile
• Each snapshot references the artifacts that informed interpretation
• Changes in meaning result in new snapshots
• Decisions explain transitions between snapshots
• Intent is recorded independently of implementation, workflow state, or certification outcomes

What system intent means in M45

System intent is the structured explanation of:

• Why a system exists
• What goals it must achieve
• What hazards must be controlled
• What constraints, assumptions, and limitations shape the design space
• How that intent is realized across levels of abstraction

M45’s notion of system intent:

• Intent is expressed across multiple abstraction levels, from system purpose to physical realization
• Higher-level intent explains why lower-level decisions exist
• Safety intent is expressed as constraints derived from hazards
• Assumptions and limitations are first-class intent elements
• Intent must remain reviewable as systems, environments, and operations evolve

An intent snapshot captures this intent as interpreted at a specific moment, not as an objective or final truth.

What an intent snapshot contains

An intent snapshot includes:

• Metadata and identity
• Project context and semantic profile
• Project intent axis packages (via the referenced Project Intent Profile)
• Source artifact references
• Intent baseline layer — foundational intent elements (losses, hazards, top-level goals) that exist independently of requirement evidence
• Structured intent elements, including pre-requirement artifacts (hypotheses, pragmatic assumptions, risk tradeoffs, operational constraints)
• Requirement projections — normalized extractions from raw requirements, distinct from raw requirement artifacts
• Belief rationale for intent elements (why something was believed to work)
• Evidence with type, direction, and priority (supporting or counter-evidence, field validation vs formal verification)
• Hazard and safety intent with explicit loss-to-hazard-to-constraint chains
• An intent graph capturing relationships
• Decision record references
• Supersession relationships

It does not include:

• Inference algorithms
• Workflow or review state
• Certification conclusions
• Execution or allocation details

Alignment with intent specifications

An intent snapshot is compatible with intent specifications in the following ways:

Vertical intent levels

Intent elements may correspond to different intent levels, such as:

• System purpose
• System design principles
• Blackbox behavior
• Design representation
• Physical representation

These levels form a means–ends hierarchy.

Higher levels explain why.
Lower levels explain how.

Horizontal concerns

At each intent level, intent elements may address different concerns:

• Environment constraints and assumptions
• Operator interactions and responsibilities
• System behavior and structure
• Verification and validation intent

Explicit relationships

Relationships between intent elements are made explicit through:

• The intent graph
• Decision records
• Snapshot supersession

M45 does not impose a fixed document structure.

Intent structure is represented semantically.

Project intent axis packages

Intent in M45 is structured through intent axes.

Intent axes define the semantic dimensions along which system intent is expressed, reviewed, and evolved.

Axes are grouped into Project Intent Axis Packages.

An axis package represents a coherent semantic lens on system intent, such as:

• Functional and behavioral intent
• Safety and hazard-related intent
• Operational and environmental intent
• Verification and assurance intent

Axis packages are not universal.

They are selected and configured per project through the Project Intent Profile.

Important: Axes are views, not ontology. Axis tagging (axisId) on intent elements is optional metadata used for organization and filtering. Graph relationships (like refines, mitigates, verifies) must not be derived from axis tags. Relationships are defined explicitly through the intent graph edges, independent of axis classification.

Why axis packages exist

Complex systems do not have a single notion of intent.

Different stakeholders reason about the same system using different abstractions and concerns.

Axis packages allow M45 to:

• Represent multiple views of system intent without duplication
• Keep intent snapshots stable as semantic needs evolve
• Support safety-critical reasoning alongside functional reasoning
• Avoid collapsing intent into a single flattened taxonomy

This mirrors intent specifications, where intent is distributed across abstraction levels and concerns, but makes that structure explicit and configurable.

See Project Intent Axis Packages for detailed information.

Intent Snapshot schema

Formal JSON representation

{
  "intentSnapshotId": "string",
  "projectId": "string",
  "profileId": "string",
  "profileVersion": "string",
  "status": "active | superseded",

  "sourceArtifacts": [
    {
      "artifactId": "string",
      "artifactType": "requirement | requirement_projection | designDocument | safetyAnalysis | other",
      "reference": "string"
    }
  ],

  "intentBaseline": {
    "losses": [
      {
        "intentId": "string",
        "label": "string",
        "description": "string | null",
        "status": "proposed | accepted | modified | rejected"
      }
    ],
    "hazards": [
      {
        "intentId": "string",
        "label": "string",
        "description": "string | null",
        "status": "proposed | accepted | modified | rejected"
      }
    ],
    "topLevelGoals": [
      {
        "intentId": "string",
        "label": "string",
        "description": "string | null",
        "status": "proposed | accepted | modified | rejected"
      }
    ]
  },

  "intentElements": [
    {
      "intentId": "string",
      "axisId": "string | null",

      "intentLevel": "system_purpose | design_principle | blackbox_behavior | design_representation | physical_representation",
      "concern": "environment | operator | system | verification",

      "intentKind": "goal | constraint | assumption | limitation | hazard | behavior | design_principle | vnv_intent | hypothesis | pragmatic_assumption | risk_tradeoff | operational_constraint",

      "label": "string",
      "description": "string | null",
      "beliefRationale": "string | null",

      "status": "proposed | accepted | modified | rejected",

      "supportingArtifacts": [
        {
          "artifactId": "string",
          "reference": "string",
          "evidenceType": "formal_verification | field_validation | operational_counter_evidence | analysis | test | simulation | review | other",
          "evidenceDirection": "supporting | counter",
          "evidencePriority": "low | medium | high"
        }
      ],

      "constraintCriticality": "safety | mission | regulatory | other | null",
      "preservation": "required | best_effort | null",
      "encodingVerdict": "encoded | partially_encoded | not_encoded | null",
      "encodingRationale": "string | null",

      "verificationMethod": "test | analysis | inspection | simulation | formal | null",
      "verificationLevel": "unit | integration | subsystem | system | flight_test | null",
      "acceptanceCriteriaRef": "string | null",
      "targetEvidence": ["string"]
    }
  ],

  "requirementProjections": [
    {
      "projectionId": "string",
      "label": "string",
      "description": "string | null",
      "sourceRequirementId": "string | null",
      "sourceArtifactId": "string",
      "sourceReference": "string"
    }
  ],

  "intentGraph": {
    "nodes": [
      {
        "intentId": "string"
      }
    ],
    "edges": [
      {
        "edgeId": "string",
        "type": "refines | motivates | satisfies | constrains | assumes | mitigates | verifies | implements | encoded_by | specified_by | evidenced_by | leads_to | supported_by | encoded_from | enforces",
        "fromIntentId": "string",
        "toIntentId": "string",
        "rationale": "string | null"
      }
    ]
  },

  "decisionRecords": [
    {
      "decisionRecordId": "string"
    }
  ],

  "createdAt": "ISO-8601 timestamp",
  "createdBy": {
    "name": "string",
    "role": "string",
    "organization": "string"
  },

  "supersedesSnapshotId": "string | null"
}

Field definitions

intentSnapshotId

Type: string

Stable identifier for the snapshot.

projectId

Type: string

Identifier for the project to which this snapshot belongs.

profileId

Type: string

Identifier of the Project Intent Profile under which this snapshot was evaluated.

profileVersion

Type: string

Version of the Project Intent Profile used for this snapshot.

status

Type: enum

Values:

• active
• superseded

An active snapshot is the current interpretation. A superseded snapshot has been replaced by a newer one.

sourceArtifacts

Type: array of objects

References the artifacts that informed the interpretation captured in this snapshot.

Each artifact reference includes:

• artifactId: Stable identifier for the artifact
• artifactType: Type of artifact. Must be one of:
  • requirement — Raw requirement artifact (e.g., from a requirements database, ReqIF exchange file, or other requirement management source)
  • requirement_projection — Normalized obligation extracted from a raw requirement (see Requirement projections below)
  • designDocument — Design document
  • safetyAnalysis — Safety analysis document
  • other — Other artifact types
• reference: Location or identifier within the artifact

Semantic distinction: requirement represents the raw requirement text as it appears in source artifacts, independent of storage or exchange format. requirement_projection represents the normalized, interpreted obligation extracted from that raw requirement. This separation enforces the structural distinction between intent and requirements, avoiding the failure mode where an intent statement is "supported" by a vague SHALL when it is actually only weakly implied.

intentBaseline

Type: object

The Intent Baseline layer captures foundational intent elements that exist independently of requirement evidence. These elements form the minimal semantic foundation for system intent reasoning.

The intent baseline includes:

• losses — Unacceptable outcomes that the system must prevent
• hazards — System-level hazardous states (not component failures) that could lead to losses
• topLevelGoals — Mission/operational goals that motivate the system

Key property: Elements in the intent baseline can exist with zero requirement evidence and are allowed to be hypotheses. They represent the foundational reasoning layer that precedes formal requirement specification.

Baseline elements are represented as normal intent elements (with intentId, label, description, status) but are explicitly separated to emphasize their foundational role. They participate in the intent graph like other intent elements.

See Intent baseline below for detailed field definitions.

intentElements

Type: array of objects

The core semantic claims about the system. See Intent elements below for detailed field definitions.

requirementProjections

Type: array of objects

Normalized extractions from raw requirements. A requirement projection represents the interpreted obligation extracted from a raw requirement artifact, distinct from the raw requirement text itself.

Each requirement projection includes:

• projectionId: Stable identifier for the requirement projection
• label: Human-readable label for the projection
• description: Detailed description of the normalized obligation
• sourceRequirementId: Identifier of the source requirement (if available)
• sourceArtifactId: Identifier of the source artifact containing the raw requirement
• sourceReference: Location or identifier within the source artifact

Semantic distinction: Requirement projections are separate from raw requirement artifacts (reqif_requirement). This separation enforces that:

• Intent elements are supported by requirement projections (normalized obligations)
• Requirement projections are encoded from raw requirements
• This avoids the failure mode where an intent statement is "supported" by a vague SHALL when it is actually only weakly implied

See Requirement projections below for detailed field definitions.

intentGraph

Type: object

Captures explicit relationships between intent elements, requirement projections, and artifacts. See The intent graph below.

decisionRecords

Type: array of objects

References to decision records that explain changes in interpreted intent.

Each reference includes:

• decisionRecordId: Identifier for the decision record

createdAt

Type: ISO-8601 timestamp

Timestamp when the snapshot was created.

createdBy

Type: object

Identifies the human author of the snapshot.

Fields:

• name: Author name
• role: Author role
• organization: Author organization

supersedesSnapshotId

Type: string | null

References the immediately prior snapshot, if any.

This establishes the historical chain of interpreted intent.

Intent baseline

The intent baseline captures foundational intent elements that exist independently of requirement evidence. These elements form the minimal semantic foundation for system intent reasoning.

losses

Type: array of objects

Unacceptable outcomes that the system must prevent. Losses represent the fundamental "why" — what bad things must not happen.

Each loss includes:

• intentId: Stable identifier for the loss (references an intent element in the intent graph)
• label: Human-readable label for the loss
• description: Detailed description of the unacceptable outcome
• status: Review status (proposed | accepted | modified | rejected)

Key property: Losses can exist with zero requirement evidence and are allowed to be hypotheses. They represent foundational reasoning that precedes formal requirement specification.

Losses participate in the intent graph. A loss leads_to one or more hazards.

hazards

Type: array of objects

System-level hazardous states (not component failures) that could lead to losses. Hazards represent conditions that, if uncontrolled, could result in unacceptable loss.

Each hazard includes:

• intentId: Stable identifier for the hazard (references an intent element in the intent graph)
• label: Human-readable label for the hazard
• description: Detailed description of the hazardous state
• status: Review status (proposed | accepted | modified | rejected)

Key property: Hazards can exist with zero requirement evidence and are allowed to be hypotheses. They represent foundational reasoning that precedes formal requirement specification.

Hazards participate in the intent graph. A hazard is leads_to by one or more losses, and mitigates one or more constraints.

topLevelGoals

Type: array of objects

Mission/operational goals that motivate the system. Top-level goals represent the fundamental "why" — what good things the system must achieve.

Each top-level goal includes:

• intentId: Stable identifier for the goal (references an intent element in the intent graph)
• label: Human-readable label for the goal
• description: Detailed description of the mission/operational goal
• status: Review status (proposed | accepted | modified | rejected)

Key property: Top-level goals can exist with zero requirement evidence and are allowed to be hypotheses. They represent foundational reasoning that precedes formal requirement specification.

Top-level goals participate in the intent graph and may motivate lower-level goals, constraints, and behaviors.

Requirement projections

Requirement projections represent normalized extractions from raw requirements. They capture the interpreted obligation extracted from a raw requirement artifact, distinct from the raw requirement text itself.

projectionId

Type: string

Stable identifier for the requirement projection within the snapshot.

label

Type: string

Human-readable label for the requirement projection.

description

Type: string | null

Detailed description of the normalized obligation extracted from the raw requirement.

sourceRequirementId

Type: string | null

Identifier of the source requirement (if available). This may reference a requirement ID from a requirements database, ReqIF exchange file, or other requirement management system.

sourceArtifactId

Type: string

Identifier of the source artifact containing the raw requirement. This must reference an artifact in sourceArtifacts with artifactType: "requirement".

sourceReference

Type: string

Location or identifier within the source artifact where the raw requirement can be found.

Semantic distinction: Requirement projections are separate from raw requirement artifacts (requirement). This separation enforces that:

• Intent elements are supported_by requirement projections (normalized obligations)
• Requirement projections are encoded_from raw requirements
• This avoids the failure mode where an intent statement is "supported" by a vague SHALL when it is actually only weakly implied

Requirement projections participate in the intent graph:

• An intent element may be supported_by a requirement projection
• A requirement projection is encoded_from a raw requirement artifact
• A constraint may be enforced by requirement projections (or requirement projections enforce constraints)

Intent elements

Each intent element represents a semantic claim about the system.

Examples:

• A system goal
• A safety constraint
• A hazard that must be controlled
• A blackbox behavioral expectation
• A design principle guiding lower-level choices
• A verification intent
• A hypothesis about system behavior
• A pragmatic assumption made under operational constraints
• A risk tradeoff decision
• A constraint discovered during operations

Intent elements are not requirements.

They express meaning, not obligation.

Requirements remain as artifacts. Intent elements express the interpreted meaning of those requirements, not the requirements themselves. Intent elements reference requirement artifacts via supportingArtifacts and graph edges like encoded_by or specified_by for semantic traceability.

Intent snapshots record why something was believed to work, not just that it met a specification. This includes pre-requirement artifacts (hypotheses, pragmatic assumptions, risk tradeoffs, operational constraints) that capture the reasoning and operational basis for design decisions.

This distinction aligns with Leveson's framework, which distinguishes between intent constraints, requirements, and design decisions across abstraction levels. The semantics must be crisp to support mechanical verification of constraint preservation and requirement coverage.

intentId

Type: string

Stable identifier for the intent element within the snapshot.

axisId

Type: string | null

Optional metadata — Axis under which the intent element is classified.

An axis defines a specific semantic dimension of system intent, such as:

• Function
• Mode
• Hazard
• Safety constraint
• Assumption
• Verification objective

Axes are defined in axis definitions and grouped into axis packages.

Important: axisId is optional metadata used for organization and filtering. It is a view, not part of the ontology. Graph relationships (like refines, mitigates, verifies) must not be derived from axis tags. Relationships are defined explicitly through the intent graph edges, independent of axis classification.

If provided, the axisId must belong to an axis from a package enabled by the Project Intent Profile referenced by the snapshot. This constraint lives in validation logic and documentation, not in the snapshot payload, keeping snapshots compact and timeless.

May be null if the intent element is not classified under any axis.

See:

• Intent Axes
• Axis Definition Schema
• Project Intent Profile
• Project Intent Axis Packages

intentLevel

Type: enum

The abstraction level at which the intent is expressed.

Values:

• system_purpose
• design_principle
• blackbox_behavior
• design_representation
• physical_representation

These levels form a means–ends hierarchy. Higher levels explain why. Lower levels explain how.

concern

Type: enum

The horizontal concern addressed by this intent element.

Values:

• environment
• operator
• system
• verification

intentKind

Type: enum

The semantic nature of the intent element.

Values:

goal
A high-level objective or purpose the system must achieve.
Example: Provide accurate navigation guidance to the flight crew.

constraint
A restriction or limitation that bounds the design space or system behavior. Constraints may be preservation invariants that must be maintained through refinement and allocation.
Example: Navigation solution accuracy must not degrade below 10 meters horizontal position error.

assumption
A foundational belief about the system or its environment that must hold for the intent itself to be valid.
Example: The aircraft will only operate within the environmental envelope defined in CS-25.

limitation
A known restriction or boundary of the system's capabilities or scope.
Example: The navigation system does not provide guidance below 50 feet above ground level.

hazard
A system-level condition that could lead to unacceptable loss.
Example: Loss of navigation capability during approach phase.

behavior
A description of how the system behaves or responds in specific situations.
Example: When GPS signal is lost, the system transitions to inertial navigation mode within 100 milliseconds.

design_principle
A guiding principle that informs design decisions and lower-level choices.
Example: Fail-safe design: system defaults to most conservative mode when uncertainty exceeds threshold.

vnv_intent
Verification and validation intent, describing how an intent element should be verified or validated. VNV intent elements should include structured verification metadata: verificationMethod, verificationLevel, acceptanceCriteriaRef, and optionally targetEvidence.
Example: Verify navigation accuracy requirement through flight test data analysis comparing computed position to surveyed ground truth.

hypothesis
A testable belief about how the system should work or why a design choice is appropriate.
Example: Using dual-redundant sensors will reduce false alarm rate below 0.1% while maintaining detection sensitivity.

pragmatic_assumption
An assumption made under operational constraints, time pressure, or practical considerations, distinct from foundational assumptions.
Example: Assume worst-case crosswind conditions are out of scope for the initial flight test campaign so envelope expansion can proceed incrementally.

risk_tradeoff
A documented tradeoff between risks, capturing what risks were accepted in favor of others.
Example: Accept increased computational latency to prioritize safety-critical path execution over non-critical features.

operational_constraint
A constraint identified during operations, integration, testing, or deployment rather than upfront design.
Example: Integration testing revealed that sensor fusion algorithm must complete within 50ms to avoid buffer overflow in downstream systems.

Safety-critical intent elements typically include hazard and constraint kinds.

Pre-requirement artifacts (hypothesis, pragmatic_assumption, risk_tradeoff, operational_constraint) capture intent that exists before formal requirements are established. They record why something was believed to work, not just that it met a specification.

label

Type: string

Human-readable label for the intent element.

description

Type: string | null

Detailed description of the intent element. May be null if the label is self-explanatory.

beliefRationale

Type: string | null

Records why this intent element was believed to work or be appropriate, not just what it specifies.

This field captures the reasoning, justification, or operational basis for the intent element. It is particularly important for pre-requirement artifacts (hypotheses, pragmatic assumptions, risk tradeoffs) and operational constraints.

Examples:

• Why a hypothesis was formed
• What operational experience informed a pragmatic assumption
• What operational conditions led to discovering a constraint
• Why a risk tradeoff was acceptable

May be null if the rationale is captured elsewhere (e.g., in decision records or the description field).

status

Type: enum

Review status of the intent element.

Values:

• proposed
• accepted
• modified
• rejected

supportingArtifacts

Type: array of objects

Artifacts that provide evidence for this specific intent element.

Each reference includes:

• artifactId: Identifier for the artifact
• reference: Location or identifier within the artifact
• evidenceType: Type of evidence provided (see Evidence types below)
• evidenceDirection: Whether the evidence supports or contradicts the intent element (supporting | counter)
• evidencePriority: Priority/weight of this evidence (low | medium | high)

Evidence priority is used to privilege field validation over formal verification when both are available. Field validation evidence should typically be assigned higher priority than formal verification evidence for the same intent element.

constraintCriticality

Type: enum | null

Applies to: Intent elements with intentKind: "constraint"

The criticality category of a constraint that must be preserved through refinement and allocation.

Values:

• safety — Safety-critical constraint derived from hazards
• mission — Mission-critical constraint
• regulatory — Regulatory or certification constraint
• other — Other criticality category
• null — Not applicable (for non-constraint intent elements or constraints without explicit criticality)

This field enables mechanical checks: every constraint with preservation: "required" and constraintCriticality: "safety" must trace into lower-level intents and into requirements and verification intent.

preservation

Type: enum | null

Applies to: Intent elements with intentKind: "constraint"

Whether this constraint must be preserved as a preservation invariant through refinement and allocation.

Values:

• required — The constraint must be preserved through all refinement and allocation steps
• best_effort — The constraint should be preserved where feasible, but may be relaxed under documented rationale
• null — Not applicable (for non-constraint intent elements or constraints without explicit preservation requirement)

Constraints with preservation: "required" are preservation invariants that must trace into lower-level intents and into requirements and verification intent. This enables mechanical verification of constraint preservation across abstraction levels.

Promotion to constraint: For constraints with constraintCriticality: "safety", the intent graph must include an explicit chain: loss → hazard (via leads_to) → constraint (via mitigates). This ensures Leveson-aligned safety reasoning where constraints are derived from hazards, which are derived from losses.

verificationMethod

Type: enum | null

Applies to: Intent elements with intentKind: "vnv_intent"

The method used to verify or validate the intent element.

Values:

• test — Testing (unit, integration, system, flight test)
• analysis — Engineering analysis, trade studies
• inspection — Code review, design review, inspection
• simulation — Simulation-based verification
• formal — Formal methods (proofs, model checking, static analysis)
• null — Not applicable (for non-VNV intent elements) or method not yet specified

verificationLevel

Type: enum | null

Applies to: Intent elements with intentKind: "vnv_intent"

The level at which verification or validation should occur, following the principle of verifying at the lowest feasible level.

Values:

• unit — Unit-level verification
• integration — Integration-level verification
• subsystem — Subsystem-level verification
• system — System-level verification
• flight_test — Flight test or operational validation
• null — Not applicable (for non-VNV intent elements) or level not yet specified

acceptanceCriteriaRef

Type: string | null

Applies to: Intent elements with intentKind: "vnv_intent"

Reference to an artifact (e.g., a requirement, test specification, or acceptance criteria document) that defines the acceptance criteria for this verification intent.

May be null if acceptance criteria are captured in the description field or elsewhere.

targetEvidence

Type: array of strings

Applies to: Intent elements with intentKind: "vnv_intent"

Optional array specifying what artifact types should exist as evidence for this verification intent.

Examples:

• ["test_report", "flight_test_data"]
• ["formal_proof", "model_checking_report"]
• ["analysis_report", "simulation_results"]

May be empty if not specified.

encodingVerdict

Type: enum | null

Applies to: Intent elements with intentKind: "constraint" and preservation: "required"

Explicit sufficiency verdict indicating whether the constraint is adequately encoded in the requirement set.

Values:

• encoded — The constraint is fully encoded by one or more requirement projections
• partially_encoded — The constraint is partially encoded, with identified coverage gaps
• not_encoded — The constraint is not encoded in the requirement set
• null — Verdict not yet determined or not applicable

This field bridges Leveson semantics (constraints derived from hazards) and Kefalas rigor (requirement coverage verification). It states whether the requirement set actually encodes the constraint.

When encodingVerdict is partially_encoded or not_encoded, encodingRationale must document the coverage gaps and link to the enforcing projections (if any) and missing requirements.

encodingRationale

Type: string | null

Applies to: Intent elements with intentKind: "constraint" and preservation: "required"

Rationale explaining the encodingVerdict, including:

• Links to enforcing requirement projections (if encoded or partially_encoded)
• Identification of coverage gaps (if partially_encoded or not_encoded)
• Justification for the verdict

May be null if the rationale is captured elsewhere or if encodingVerdict is null.

Evidence types

Type: enum

The type of evidence provided by the artifact.

Values:

• formal_verification — Formal proofs, model checking, static analysis
• field_validation — Operational data, flight test results, field observations
• operational_counter_evidence — Field data or observations that contradict the intent element
• analysis — Engineering analysis, trade studies, risk assessments
• test — Test results (unit, integration, system)
• simulation — Simulation results
• review — Review findings, inspection results
• other — Other types of evidence

Evidence direction:

• supporting — The evidence supports the intent element
• counter — The evidence contradicts or challenges the intent element

Counter-evidence is critical for safety and certification workflows. Operational counter-evidence should be ingested and tracked, not ignored, even when formal verification exists.

Evidence priority:

• low — Lower priority evidence (e.g., formal verification when field validation exists)
• medium — Standard priority evidence
• high — High priority evidence (e.g., field validation, operational counter-evidence)

When multiple evidence types exist for the same intent element, field validation should be privileged over formal verification. Operational counter-evidence should typically be assigned high priority.

Hazards and safety intent

Hazards are first-class intent elements, captured both in the intent baseline and as regular intent elements.

A hazard intent element represents:

• A system-level condition that could lead to unacceptable loss
• Independent of implementation or mitigation
• System-level hazardous states, not component failures

Safety intent is expressed through:

• Losses — Unacceptable outcomes that must be prevented
• Hazards — System-level hazardous states that could lead to losses
• Safety constraints — Constraints derived from hazards to mitigate them
• Explicit chains — Loss → Hazard → Constraint relationships in the intent graph

Leveson-aligned safety reasoning: For constraints with constraintCriticality: "safety", the intent graph must include an explicit chain:

• loss → hazard (via leads_to edge)
• constraint → hazard (via mitigates edge)

This ensures auditable safety reasoning where constraints are derived from hazards, which are derived from losses.

Safety is controlled through constraints, not components.

Safety and certification workflows should ingest operational counter-evidence, not ignore it. When operational data contradicts formal verification, the counter-evidence should be recorded with high priority in the supportingArtifacts array, and the intent element's beliefRationale should explain how the contradiction is being addressed.

The intent graph

The intent graph captures explicit relationships between intent elements, requirement projections, and artifacts.

It represents:

• Means–ends reasoning
• Safety rationale (loss → hazard → constraint chains)
• Design justification
• Verification intent
• Intent-to-requirement traceability (intent elements ↔ requirement projections ↔ raw requirements)

The intent graph is descriptive, not executable.

nodes

Type: array of objects

References to intent elements that participate in the graph.

Each node includes:

• intentId: Identifier of the intent element

Note: Requirement projections are not listed in the nodes array. They are referenced directly in edges via their projectionId when using edge types like supported_by, encoded_from, or enforces.

edges

Type: array of objects

Explicit relationships between intent elements, requirement projections, and artifacts.

Each edge includes:

• edgeId: Stable identifier for the edge
• type: Relationship type (see Edge types below)
• fromIntentId: Source identifier (may be an intentId or projectionId, depending on edge type)
• toIntentId: Target identifier (may be an intentId or projectionId, depending on edge type)
• rationale: Optional explanation of the relationship

Edge identifier semantics:

• For edges between intent elements: use intentId values
• For edges involving requirement projections: use projectionId values
• For edges involving artifacts: use artifactId values

The edge type determines which identifiers are valid. For example:

• supported_by: fromIntentId = intent element, toIntentId = requirement projection
• encoded_from: fromIntentId = requirement projection, toIntentId = raw requirement artifact
• leads_to: fromIntentId = loss, toIntentId = hazard
• mitigates: fromIntentId = constraint, toIntentId = hazard

Edge types

Common edge types include:

• motivates — Higher-level intent explains why lower-level intent exists
• satisfies — Lower-level intent fulfills higher-level intent
• constrains — A constraint restricts design or behavior
• assumes — A decision relies on an assumption
• mitigates — A constraint mitigates a hazard (constraint → hazard). Required for safety-critical constraints.
• verifies — Verification intent validates another intent element
• implements — Physical realization implements design intent
• leads_to — A loss leads to a hazard (loss → hazard). Required for Leveson-aligned safety reasoning.
• supported_by — An intent element is supported by a requirement projection (intent element → requirement projection). This provides semantic traceability from intent to normalized requirement obligations.
• encoded_from — A requirement projection is encoded from a raw requirement artifact (requirement projection → raw requirement artifact). This separates normalized obligations from raw requirement text.
• enforces — A requirement projection enforces a constraint (requirement projection → constraint). Alternative direction: constraint → requirement projection via encoded_by.
• encoded_by — An intent element is encoded by a requirement artifact (intent element → requirement artifact reference). This provides semantic traceability from intent to normative requirements. Note: For requirement projections, use supported_by instead.
• specified_by — An intent element is specified by a requirement artifact (intent element → requirement artifact reference). Alternative to encoded_by with equivalent semantics.
• evidenced_by — An intent element is evidenced by an evidence artifact (intent element → evidence artifact reference). This provides semantic traceability separate from supportingArtifacts, enabling explicit graph-based evidence relationships.

Safety constraint chain requirements:

For constraints with constraintCriticality: "safety", the intent graph must include:

• loss → hazard (via leads_to)
• constraint → hazard (via mitigates)

This ensures Leveson-aligned safety reasoning where constraints are derived from hazards, which are derived from losses.

Requirement projection relationships:

The separation between raw requirements and requirement projections is enforced through:

• intent_element → requirement_projection (via supported_by)
• requirement_projection → raw_requirement_artifact (via encoded_from)
• requirement_projection → constraint (via enforces) or constraint → requirement_projection (via encoded_by)

This avoids the failure mode where an intent statement is "supported" by a vague SHALL when it is actually only weakly implied.

The supported_by, encoded_from, and enforces edge types form the backbone for "map requirements to intent axes" and "preserve constraints across refinement" workflows. They enable mechanical checks that every preservation-required constraint traces into requirement projections and verification intent.

Edges may include rationale text.

Pre-requirement artifacts and relationships:

Pre-requirement artifacts (hypotheses, pragmatic assumptions, risk tradeoffs, operational constraints) often motivate or inform formal requirements:

• A hypothesis may motivate a constraint or other intent element
• A pragmatic_assumption may be connected via assumes edges to intent elements that depend on it
• A risk_tradeoff may motivate design decisions or constraints
• An operational_constraint may constrains existing intent elements or motivates new ones

These relationships capture the evolution from pre-requirement reasoning to formal specification, preserving the "why" behind requirements.

Intent-to-requirement traceability:

Intent elements reference requirement artifacts through:

• supportingArtifacts array (for evidence and context)
• supported_by graph edges (for semantic traceability from intent to requirement projections)
• encoded_by or specified_by graph edges (for direct traceability to raw requirement artifacts, less preferred)

Requirements remain as artifacts. Intent elements express the interpreted meaning of those requirements, not the requirements themselves. The supported_by edges provide explicit semantic trace from intent to requirement projections (normalized obligations), enabling mechanical checks for constraint preservation and requirement coverage.

Decision records

Decision records explain changes in interpreted intent.

They capture:

• Why an intent element was accepted, modified, or rejected
• Why one interpretation was chosen over alternatives
• Why a new snapshot superseded a prior one

Decision records are the authority boundary.

See the decisionRecords field in Field definitions above.

Relationship to other records

• Artifacts provide evidence
• Intent snapshots capture interpreted meaning
• Decision records justify interpretation and change
• Project intent profiles define semantic structure

Together, these form the M45 context layer.

Design intent

The intent snapshot exists to make meaning:

• Explicit rather than implicit
• Structured rather than scattered
• Versioned rather than overwritten
• Reviewable rather than assumed

This enables safety-critical engineering without automating authority.

Version History

Version 0.6 (Current)

• Added intentBaseline section with losses, hazards, and topLevelGoals that can exist with zero requirement evidence and are allowed to be hypotheses. This makes "intent above requirements" explicit as a first-class layer.
• Separated raw requirement evidence from requirement projection evidence:
  • Added requirementProjections array for normalized obligations extracted from raw requirements
  • Distinguished artifactType: "requirement" (raw) from artifactType: "requirement_projection" (normalized)
  • Added edge types: supported_by (intent → requirement projection), encoded_from (requirement projection → raw requirement), enforces (requirement projection → constraint)
• Made "promotion to constraint" require explicit loss/hazard chain:
  • Added leads_to edge type (loss → hazard)
  • Required mitigates edge (constraint → hazard) for safety-critical constraints
  • Updated safety intent section to document the loss → hazard → constraint chain requirement
• Made axisId optional metadata (views, not ontology):
  • Changed axisId type from string to string | null
  • Clarified that axis tagging is optional metadata for organization/filtering
  • Emphasized that graph relationships must not be derived from axis tags
• Added explicit sufficiency verdict per promoted constraint:
  • Added encodingVerdict field (encoded | partially_encoded | not_encoded | null)
  • Added encodingRationale field for documenting coverage gaps and links to enforcing projections
  • This bridges Leveson semantics and Kefalas rigor by stating whether requirements actually encode constraints

Version 0.5

• Removed intentKind: "requirement" from intent snapshots. Requirements remain as artifacts; intent elements reference them via supportingArtifacts and graph edges like encoded_by or specified_by. This aligns with Leveson's distinction between intent constraints, requirements, and design decisions.
• Added constraintCriticality field to constraint intent elements (values: safety, mission, regulatory, other, or null)
• Added preservation field to constraint intent elements (values: required, best_effort, or null) to support preservation invariants that must be maintained through refinement and allocation
• Extended vnv_intent elements with structured verification fields: verificationMethod, verificationLevel, acceptanceCriteriaRef, and targetEvidence to support mechanical "three balls" alignment checks
• Added encoded_by, specified_by, and evidenced_by edge types to intent graph for explicit semantic traceability from intent to requirements and evidence

Version 0.4

• Added pre-requirement artifacts as first-class intent kinds: hypothesis, pragmatic_assumption, risk_tradeoff, operational_constraint
• Added beliefRationale field to intent elements to record why something was believed to work
• Enhanced supportingArtifacts with evidenceType, evidenceDirection, and evidencePriority to support field validation over formal verification and operational counter-evidence
• Removed confidence field
• Added definitions and examples for all intentKind values

Version 0.3

• Adapted schema definitions based on Leveson's Intent Specifications