The gods knew the wolf would one day break loose and devour the world. They did not wait. They named the risk, forged Gleipnir, and bound it — and Týr paid a hand for the binding. Fenrir does the same work: it names the catastrophic failure before it happens and binds it with analysis and mitigation. The hand given up is the design constraint accepted to keep the system safe.
Fenrir is a design FMEA (dFMEA) engine: function-level failure analysis, with risk rated under AIAG-VDA or as a MIL-STD-1629A criticality analysis. It reads its source requirements and architecture from Bifrost, and it is database-agnostic by construction — every source-system access goes through a single adapter contract, so the engine's methodology never depends on where the engineering data is stored.
Fenrir is opinionated about methodology (function-anchored dFMEA, graph-first) and unopinionated about where the engineering data lives. These are independent axes.
END EFFECT FAILURE ELEMENT PROPAGATES →
This mirrors the Bifrost relationship philosophy — named elements connected by named, directional relations (Fulfils, Decompose, Bind, Verifies).
The FMEA is the propagation graph. The traditional flat FMEA
table is a calculated view — each row one path,
End Effect ← Mode ← Cause, with risk columns denormalised
onto it — generated on demand for review and export (xlsx), never
edited directly.
Two risk schemes run side by side. An FMEA declares which one it uses, and the rating fields, the ranking and the flat table follow it. In both, Severity on a Failure Element is always computed, never stored: the maximum across all End Effects reachable via Propagates.
AIAG-VDA
MIL-STD-1629A
Cm = β · α · λp · t per failure mode: β, the conditional
probability that the failure produces the classified severity, on
the mode → End Effect Propagates edge; α, the failure mode ratio, on
the element; λp (failures per 106 h) and t (operating
hours) entered per architecture item in Fenrir, with source and
note. Cr = ΣCm per item and severity class. Both are
computed on read, never stored — a missing factor yields no number
and names the factor that is missing.Select a Solution Architecture node. Its subtree defines the function set in scope.
Every Solution Requirement on a Function yields one failure mode: "Violated: …". A Function with no requirements yields one generic mode: "Fails to: …".
Drawn by the engineer, never generated. A cause is the failure of the element below; generation wires no links and invents no End Effects.
Every mode carries a function reference and, where a requirement named it, a requirement ID. Coverage is answerable mechanically; modes with no cause are counted.
Generation is idempotent: re-running never duplicates and never overwrites user-authored work.
Industry practice runs FMEA sessions per subsystem. Fenrir supports this as a viewport, not a partition: there is one FMEA per project — one graph — and selecting a Solution node scopes the view to its functions, their failure elements, one Propagates hop above and below, and all End Effects, always. The graph stays whole; the scope is a lens.
A Mitigation can be proposed back to the source system as a draft requirement. Governance is strict: it lands in the project, never the Library; it is proposed into the Solution layer, where mitigations naturally live as controls or architectural constraints; and promotion happens exclusively through Bifrost's Release Gate. Every proposed requirement is marked as originating from a failure analysis and linked back to the mitigation it came from, so reviewers can always see why a constraint exists.
Each mitigation carries its own writeback state — proposed, accepted or rejected — kept separate from its implementation status. A mitigation can only be proposed once, so repeated clicks never produce duplicate drafts in the source system.
Severity is owned at the End Effect, inherited downward; the highest value wins on multiple inheritance.
Occurrence and Detection are owned by the Failure Element and are identical wherever the element appears.
Mode and Cause are roles, not types. Position in the graph relative to scope decides the role.
The graph is the single source of truth. The flat table is a derived, read-only export artefact.
Generation is idempotent. User-authored content is never overwritten.
Cycles in Propagates are invalid and rejected at creation.
Writeback proposes to the project; the Release Gate decides Library promotion. Fenrir never touches the Library.
One FMEA per source project. Scope is a viewport over a single graph, never a data partition.
Failure-rate data belongs to the item. λp and t sit on the item, α on the mode, β on the mode-to-End-Effect edge. Criticality is derived, never stored; a missing factor withholds the number and is named, never approximated.
None of the following is open to an FMEA tool that does not own the requirements, the verification record and the standards knowledge. It is the reason Fenrir sits inside the family.
On the way, and not yet built: failure modes proposed per function under the same human gate as Norn's proposals; failure catalogues seeded from the standards Mimir has already sealed; and a review queue in the FMEA when the requirements it derives from change.
Fenrir runs alongside Bifrost as part of a single installation — one instance per organisation, with no shared or multi-tenant data. It can be hosted for you or deployed entirely within your own environment, including air-gapped networks, so engineering data never has to leave your infrastructure.
Identity is not duplicated: Bifrost is the single sign-on authority for the whole product family, and every read from and write to the source model runs under the permissions of the engineer making the request. Analysts work in a three-pane workspace — architecture tree, propagation canvas, attribute panel — with the flat FMEA table available on demand as a review and export view.