The reasoning behind every engineering decision is supposed to survive from intent to artifact. On complex programs, it rarely does.
M45 monitors the chain continuously. AI infers. Engineers decide.
Hazard Review
Read
Requirements and inferred intent
Found
A safety-critical coverage gap
Requirements
Inferred Intent
“These requirements exist because a loss of autopilot or corrupt sensor data must never leave the pilot without clear awareness of the control state and immediate ability to take over manually.”
Gap
All three requirements pass. But no requirement ensures the pilot is informed that airspeed data is unreliable after disengagement. The pilot is left manually flying on the same bad airspeed that triggered the disconnect.
Found before certification review
“You should be able to walk away from your requirements, and somebody else should be able to pick them up and recreate the design. Most designs today do not meet that criterion.”
Systems engineer, aircraft OEM
“The certification authority wants to know, 'How have you done that? Why have you traded off this thing for that thing? Why have you made that decision?'”
Systems engineer, defense aerospace
Intent in a slide deck. Requirements in DOORS. Tasks in Jira. Decisions in someone's inbox.
Reasoning gets dropped at every handoff. Quietly, incrementally, across tiers and teams and months. By the time the gap surfaces, it means rework, program slip, or a finding you cannot easily close.
“A shocking amount comes from PowerPoint. PowerPoint engineering has become a bad habit.”
Systems engineer, aircraft OEM
“At a certain point, it was about 80% just paperwork and 20% progress.”
Systems engineer, defense aerospace
Cost to fix misalignment at each stage
What the system is supposed to achieve
Formal requirements and architecture
Code, hardware, test
Certification and field use
Requirements, design fragments, rationale, review findings, and decisions should add up to one inspectable picture of the system. M45 infers candidate structure from the artifacts you already have, keeps the reasoning traceable to source, and turns that context into engineer-controlled workflows.
That context has to work in both directions: inward across your own engineering artifacts, and outward toward the regulatory environment you still have to answer to.
M45 ingests the engineering material you already have and builds a candidate model of what the system is trying to do.
It infers functions, components, scenarios, constraints, and traceability links from requirement files, design fragments, and rationale — no re-entry by hand.
System requirements (ReqIF)
142 requirements
Subsystem spec v2.3 (PDF)
38 pages extracted
Safety analysis (STPA)
12 hazard scenarios
Design rationale notes
24 decision fragments
Functions
6 inferred
Components
9 mapped
Constraints
14 extracted
Traceability links
47 anchored
Protected mode activation
Req 44, 45 + safety note A-12
Crew alerting after transition
Req 61 + hazard review H-03
Hypotheses
18
Exceptions
7
Recommendations
12
“Crew alerting behavior” has an inferred intent for post-transition alerts, but no explicit requirement covers alert behavior after protected mode activation.
In intent review, M45 generates hypotheses about what the requirements mean, surfaces exceptions where intent and artifacts disagree, and proposes recommendations.
Engineers accept, reject, defer, or refine each finding. Every inference links back to its source artifacts, so every judgment is verifiable.
Every decision is recorded with its rationale and evidence. Across iterations, across workflows, across the program lifecycle. What was inferred, what was decided, and why stays inspectable. The engineering context grows richer instead of resetting with each review cycle.
Iteration 3
14 accepted, 3 deferred, 1 rejected
Iteration 2
11 accepted, 5 deferred
Iteration 1
8 accepted, 4 deferred, 2 rejected
M45 also helps engineers interrogate the regulatory environment in plain language.
Ask a certification question, get a structured answer with authority-specific citations and escalation guidance, then save the answer or full chat back into project context. External guidance becomes part of the working record instead of staying trapped in a separate research thread.
Project context
FMS-700 certification basis
User
We are changing avionics on a legacy aircraft under EASA DOA. Can prior compliance evidence be reused, and what would likely require authority coordination?
Assistant
2 authorities searched · 14 surfaced sources
Complete • 2 authority traces • 14 surfaced sources
Situation summary
Legacy-aircraft avionics change under EASA DOA with a question about whether previously accepted compliance evidence can be reused.easa.europa.eu
Overall answer
Prior compliance evidence may be reusable if the certification basis, installation assumptions, and failure-impact context remain materially comparable. Changed interfaces or altered safety effects usually require fresh justification and likely coordination.faa.goveasa.europa.eu
Applicability
In scope
Missing information
Escalation
Recommendation
Internal review
Recommended next steps
EASA
Reuse can be argued if applicability is demonstrated and assumptions still hold.easa.europa.eu
FAA
Changed-product and installation impact determine whether prior evidence remains acceptable.faa.gov
Research support only. Engineering judgment and authority interpretation still govern project decisions.
Describe the certification situation, and select one or more authorities.
Runs in our cloud or yours. Self-hosted available for regulated programs.
Artifacts come in through pull or monitoring. AI builds a shared engineering context across them. Workflows run on top. Engineers decide.
Currently in use with early design partners.
Pull
Engineer-initiated ingestion
Monitor
Event-driven detection
Shared Engineering Context
Persistent shared context connecting all layers
Workflows
Every workflow is human-gated. Nothing ships without engineer approval.
Intent Review
Requirements decompose through multiple tiers, from system functions down to component specs. Intent Review continuously checks where engineering intent was lost or distorted in that translation, and surfaces it before it becomes a finding.
Learn more →Regulatory Intelligence
Regulatory material is scattered across authorities, document types, and versions, and it changes constantly. Regulatory Intelligence gives you structured, cross-authority views on what applies to your specific program.
Learn more →Requirements Decomposition
Lower-tier requirements need to trace back to system-level intent and preserve safety context. That traceability is easy to lose when you're authoring across tiers. This workflow keeps those connections intact as you decompose.
Compliance Scout
DO-178C, ARP4754A, and MIL-STD-882 define hundreds of objectives. Compliance Scout maps your artifacts against those objectives and surfaces gaps before formal review.
Safety Case Assembly
Safety cases require connecting STPA analyses, requirements, and structured arguments across tools and teams. Safety Case Assembly builds those connections systematically, so you're not manually chasing links at the end of a program.
Vendor Validation
When artifacts cross organizational boundaries, intent gets lost: different terminology, different assumptions, different structures. Vendor Validation surfaces those gaps, whether you're reviewing a supplier deliverable or preparing to submit one.
Workflow outputs
We are working with a small number of early design partners: direct roadmap input, early access, built around your programs. Let's talk.