AI workspace for safety-critical engineering
Designed to investigate like a systems engineer. M45’s engineering workflows guide which evidence to examine across your existing tools and what to check next. They follow up on findings and develop proposed next steps, such as engineering work packages or certification pathways.
Keep your existing tools and systems of record. M45 works across them.
Investigate what a decision, proposed change, regulatory update, or field report means for your system. Examine the consequences, supporting evidence, any conflicts between sources, and what needs to be checked or changed.
You
We want to show the crew when the hoist cable is moving. Can we use the HOIST MOTION signal for that? What do we need to check?
M45
The interface document says this signal reports a motor command, not measured cable movement. That finding guides the next checks: what the crew can infer while the hoist stops, and which feedback and verification are needed.
Rescue hoist · Crew display
Change impact assessment
Change impact assessment
Rescue hoist · Crew display
Using the hoist’s motor-command signal as a cable-movement indication.
Engineering question
Not on its own. HOIST MOTION shows that the controller is asking the motor to run. It does not measure whether the cable is moving.
Why this matters
If the indication goes off, the crew might assume the cable has stopped. This signal alone cannot confirm that.
Work to resolve
Establish what the display should tell the crew, which feedback can support it, and how to verify it, including while the hoist is stopping.
From the interface document · ICD-RH-208 · Rev C · §2
“Indicates that the controller is commanding the motor in either direction. It does not measure cable speed.”
Definition of the HOIST MOTION signal
Examine the indication while the hoist starts, runs, and stops, and identify the evidence needed to distinguish commanded motion from observed cable movement.
Assessment continues below
Impact assessment
Investigate whether a HATR or regulatory update is relevant to your program. Examine the comparison, supporting evidence, and questions that need further investigation.
Field report · Avionics cooling
A field report describes a mission-computer shutdown after an extended ground wait.
Relevant comparison
Our ground tests covered idle operation, not the planned mission workload.
Limit of the comparison
Our cooling uses a fan and ducts. The reported installation was passively cooled.
Sources: Field report · Ground-test record · Installation description
| Parameter | Project evidence | Work to resolve |
|---|---|---|
| Computer workload | Idle during ground tests | Review mission-load coverage |
| Cooling arrangement | Fan and ducted airflow | Examine installed airflow and heat load |
Review thermal evidence for ground waiting with the mission workload. The report alone does not establish overheating in our installation.
Assessment continues below
Work out what you can reuse, what needs changing, and what you need to demonstrate. M45 helps turn those questions into a traceable work plan, so you can judge the effort before committing.
From the engineering assessment
Plan overview
Tasks, inputs, and evidence in each section
Commanded motion, cable movement, and brake state are different information.
Completion evidence
Reviewed indication requirements that distinguish these states.
View section
HOIST MOTION reports a motor command, not measured cable speed.
Completion evidence
Signal-to-requirement mapping with unsupported indications identified.
View section
The display must be checked during stopping as well as steady motion.
Completion evidence
Verification cases with expected indications and acceptance criteria.
View section
Question to resolve before selecting feedback
Which crew decisions require measured cable movement, and when is operator observation sufficient?
Section 01 · Detailed work
Required inputs: Crew procedure and operational evaluation. Basis: ICD-RH-208 Rev C · §§2, 4 · OEV-RH-021 · Observations and open actions.
Completion evidence: Reviewed indication requirements that distinguish these states.
Detailed plan continues below
Regulatory research
Investigate which requirements and guidance apply to your question. Review the authority sources, supporting material, and relevant project evidence behind the answer.
Regulatory research · Pipeline inspection drone
Authority source · FAA Part 107 waiver guidance
Describe the proposed operation, operational risks, and how those risks would be mitigated.
Project evidence
The demonstration covers flights within sight at a test site, not the proposed pipeline route.
Supporting technical source
The supplier’s radio-range specification does not establish coverage along the route.
Work to scope
Traffic detection, command-link coverage, and lost-link response. Define the analyses and tests needed for the proposed operation.
Clarify what your system is meant to achieve, how its parts contribute, and who is responsible for what. Give your team a common reference for discussing goals and evaluating design decisions.
Using the hoist’s motor-command signal as a cable-movement indication.
Procedures and responsibilities
Examine who directs the work, who makes the decision, and how that is communicated. Compare those relationships with the documented procedure.
Project: Matterhorn Rotorcraft · Crew coordination
Hoist operator
Supplies positional information
Pilot
Retains the aircraft decision
During the snag-response evaluation, the crew’s first discussion did not clearly establish who could command aircraft repositioning.
Open action · Procedure wording
Confirm this division of responsibility in the next procedure revision. The evaluation records the agreement; it does not close the action.
Source: OEV-RH-021 · OBS-OEV-05 · OEV-A04
Teams keep using their requirements, modeling, test, code, document, and collaboration tools. M45 uses the relevant material to investigate engineering questions across them.
Collaboration & dev tools
Engineering systems
Follow findings to the relevant source passages. Review what the evidence establishes, how it applies to your system, and what remains unresolved.
M45 preserves engineering reasoning and its links to project evidence as the work develops. Git keeps earlier versions available for review.
Open reference implementation
Safety analysis and system design need to stay connected as a system evolves. Our open reference implementation brings safety-analysis definitions from RAAML 1.1 into SysML v2 so both can share a common modeling language.
Explore the repositoryChoose where your data is stored, where AI models run, and how access is controlled, with an operating model your team can support.
For teams that want managed infrastructure and updates, with less operational work in-house.
For programs combining cloud services with internal systems and defined data boundaries.
For teams that need to host internally and can take responsibility for operations and updates.
We’re currently working with a small group of early partners and customers to apply M45 to real engineering work and shape the product around their needs.
Let’s talk