Intent and Engineering Artifacts
Purpose
This page explains how system intent is inferred and aligned across engineering artifacts.
Artifacts as sources of intent
Engineering artifacts are any recorded materials that express, imply, or constrain system meaning.
Artifacts may include:
- Requirements specifications
- Architecture and design documents
- Safety analyses
- Test descriptions
- Spreadsheets, presentations, and text documents
- Emails, meeting notes, and review protocols
- Images such as whiteboard photos or sketches
Artifacts may be structured or unstructured, formal or informal.
No single artifact is assumed to be complete or authoritative on its own.
Role of requirements
Requirements often serve as an early and explicit source of intent.
From requirements:
- Multiple intent elements may be inferred
- Intent may be expressed implicitly
- Redundancy and inconsistency are common
A requirement can be syntactically valid and still be semantically misaligned with inferred intent.
Cross-artifact alignment
As additional artifacts are introduced, M45 evaluates how intent is:
- Introduced
- Repeated
- Refined
- Constrained
- Contradicted
across the full artifact set.
Misalignment may occur when:
- Different artifacts imply conflicting intent
- Informal artifacts introduce intent missing from formal documents
- Later artifacts drift from earlier implied meaning
- Intent appears without sufficient supporting evidence
M45 does not privilege one artifact type by default.
Weighting and interpretation
Artifacts may carry different interpretive weight depending on:
- Artifact type
- Project phase
- Organizational practice
- Explicit human decisions
Intent inferred from informal artifacts requires explicit review before acceptance.
Historical integrity
M45 does not rewrite history.
Artifacts remain unchanged.
Intent snapshots represent interpretation at a specific point in time. Each snapshot is immutable and includes:
- Source artifacts (
sourceArtifactsfield) that informed the interpretation - Structured intent elements, each of which may reference specific supporting artifacts that provide evidence (with type, direction, and priority to support field validation over formal verification)
- An intent graph capturing relationships between elements
Changes in interpretation result in new intent snapshots (which accumulate over time) and are explained through decision records.
Sidebar: Why informal artifacts matter in safety-critical engineering
In safety-critical engineering, not all system meaning is captured in formal specifications.
Key decisions are frequently made or clarified through:
- Design discussions and reviews
- Trade studies and risk assessments
- Issue triage and mitigation planning
- Integration and test preparation
These decisions are often recorded in informal artifacts such as emails, meeting notes, presentations, spreadsheets, or whiteboard sketches.
While such artifacts are not authoritative specifications, they:
- Reveal assumptions and constraints
- Explain why formal artifacts were written a certain way
- Introduce intent that may not yet be reflected elsewhere
- Signal emerging changes or unresolved ambiguities
Excluding informal artifacts creates a false sense of completeness.
M45 treats informal artifacts as evidence of intent, not as final authority.
Their role is to surface implicit meaning so it can be reviewed, aligned, and, where appropriate, reflected in formal artifacts.
This allows teams to:
- Detect divergence between "what was decided" and "what is documented"
- Preserve rationale that would otherwise be lost
- Reduce rework caused by undocumented assumptions
Capturing informal intent does not weaken rigor.
It makes rigor possible.