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. 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.
Select a Solution Architecture node. Its subtree defines the function set in scope.
Every Function yields a failure-mode candidate: "Fails to: …". Expandable — a function can fail in many ways.
Every fulfilling Solution Requirement yields a cause: "Violated: …" — a constraint that must hold, not holding.
Every mode carries a function reference, every cause a requirement ID. Coverage is answerable mechanically.
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.
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.