Endrisk is a safety analysis platform we are building for systems-theoretic safety analysis. Our goal is to keep each conclusion connected to the evidence behind it and to the loss it is intended to prevent.
Here is why we are building it.
Why are we doing this?
Many safety analyses are spread across a collection of files.
| Artifact | Where it often lives today | Where its links often live |
|---|---|---|
| Control structure | A diagram, exported to PNG, pasted in a slide | In the analyst's notes |
| Unsafe control actions | A spreadsheet, one tab per control action | In cell references or conventions |
| Loss scenarios | A Word document | In prose |
| Safety requirements | DOORS, or a different spreadsheet | In manually maintained identifiers |
| The reasoning behind all of it | Review notes, email, and team memory | Across those sources |
Each artifact can work on its own. The difficulty appears at the seams. When links are implicit or manually maintained, it becomes harder to ask which requirement came from a scenario, which hazard a mitigation is intended to control, or what evidence supported a review decision.
Designs also change. A control action moves to a different component. A human task becomes automated. A feedback path changes when a sensor is replaced.
A spreadsheet cannot automatically tell that the diagram it was derived from has changed. Without an explicit dependency model, teams have to discover which conclusions need another look and record that review by hand.
That can lead to a large review before a milestone or to updates that happen unevenly across artifacts. We want the analysis to behave like one connected object that can be reviewed as the design evolves, not simply like a collection of documents.
What problem are we solving?
Systems-theoretic safety methods treat safety as a control problem rather than only as a component-failure problem. They examine whether the constraints that keep a system safe are enforced, including cases involving software, autonomy, human decisions, and organizations.
The methods provide a strong framework. Common toolchains can make the framework laborious to maintain. We are designing Endrisk as one workspace for the analysis, with capabilities such as:
- Control structures represented as models rather than static pictures. Components, responsibilities, control actions, and feedback can become structured records that other analysis artifacts reference.
- Unsafe control actions developed against that structure, with review cues when the set of modeled control actions changes.
- Loss scenarios and safety constraints connected to the unsafe control actions that motivated them, instead of maintained in parallel documents.
- Requirements connected to constraints and supporting evidence, such as a test, analysis, review, or accepted argument.
- Change review designed around dependencies. When the control structure changes, affected downstream items can be surfaced for review and the resulting decision recorded.
The same underlying model could support investigations from the other direction: begin with the control structure already in use, record what the investigation learns, and identify assumptions in the earlier analysis that may need revision.
AI-assisted capabilities are part of the design direction, not a substitute for analysis. We are exploring ways to help enumerate control-action contexts, draft candidate scenarios for review, find a requirement that may no longer match its source, and extract relevant passages from long reports.
Any AI-assisted workflow we build is intended to keep suggestions attributed, reviewable, and rejectable. Decisions about losses, hazards, evidence, and acceptance remain with the responsible team.
Why now?
Two trends make this problem especially important to us.
The systems changed. Many modern systems are software-defined, increasingly autonomous, or include a learned component somewhere in the loop. Traditional and systems-theoretic methods ask complementary questions:
| Method | A question it helps answer |
|---|---|
| FTA, FMEA | What could happen if this component fails? |
| Systems-theoretic analysis | What could make this control action unsafe, including when components have not failed? |
Some losses emerge from interactions among components whose individual behavior appears correct in isolation. Systems theory gives analysts a way to examine those interactions and the controls around them.
The tooling has room to improve. A common toolchain is still a spreadsheet and a drawing canvas, or a general-purpose modeling suite with a separate safety-analysis workflow.
When rigor is expensive to maintain, schedule pressure can turn it into a tradeoff. Good tooling should lower the cost of keeping the analysis current.
There is also a practical challenge for teams already using model-based systems engineering. Their architecture may live in Cameo or CATIA Magic. Recreating it in a separate safety tool introduces another representation to reconcile, so we are designing model integrations that can reduce duplicate maintenance.
What we are building
| Area | Direction |
|---|---|
| Safety analysis workspace | A connected environment for systems-theoretic safety analysis artifacts, their relationships, and the evidence used during review. |
| Model integrations | Ways to bring safety-analysis workflows closer to architecture already maintained in Cameo Systems Modeler and CATIA Magic. |
These analytical methods predate Endrisk. We are working to make their analysis easier to maintain as programs and designs evolve.
What we believe
- The analysis is the deliverable, not only the document that describes it.
- Traceability helps teams understand what a change may have affected.
- A tool should make rigor less expensive to maintain.
- AI assists. It does not sign.
- Important conclusions should be connected to the evidence behind them.
Follow our progress
If you work in safety analysis or incident investigation and recognize the collection of files at the top of this post, we would be glad to learn about your workflow and share what we are building. Request a demo.