FENRIR

Place in the Product Family

Fenrir is a design FMEA (dFMEA) engine: function-level failure analysis. It is database-agnostic by construction — every source-system access goes through an adapter contract, and Bifrost is adapter v1. A future DOORS or Jama adapter changes nothing in Fenrir's core.

Fenrir is opinionated about methodology (function-anchored dFMEA, graph-first) and unopinionated about where the engineering data lives. These are independent axes.

Two Elements, One Relation

END EFFECT FAILURE ELEMENT PROPAGATES →

This mirrors the Bifrost relationship philosophy — named elements connected by named, directional relations (Fulfils, Decompose, Bind).

• End Effect — the system-level consequence the customer or operator experiences. Fixed and global: whether a subsystem or a component fails, the end effect is the same. End Effects own Severity (1–10).
• Failure Element — a single failure fact with no fixed type. Whether it acts as a Mode or a Cause is purely positional, determined by where it sits in the propagation graph relative to the analysis scope. Failure Elements own Occurrence and Detection; the same element carries the same O and D wherever it appears.
• Propagates — "this failure propagates to that failure or end effect." Directed, many-to-many. A mode may feed several end effects; cycles are structurally rejected.

The graph is the source of truth

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.

Risk computation

• Severity on a Failure Element is always computed, never stored: the maximum across all End Effects reachable via Propagates.
• RPN = S × O × D — retained for legacy compatibility.
• Action Priority (H/M/L) — the forward-looking rating, computed from the same three values.

Bifrost Integration

Auto-generation — failure modes as the negative space of requirements

Generation is idempotent: re-running never duplicates and never overwrites user-authored work.

Scoped analysis per Solution node

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.

Writeback — closing the loop

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 by default — mitigations are typically controls or architectural constraints, with layer selection by type a future extension; promotion happens exclusively through Bifrost's Release Gate; statements are prefixed [Fenrir mitigation] and tagged in custom_attrs (origin: fenrir, kind: mitigation, fenrir_fmea: <ref>) for filtering and audit.

Each mitigation carries a persisted writeback lifecycle — none → proposed → accepted → rejected — orthogonal to its implementation status. On a successful proposal it records the draft's id in writeback_ref and advances to proposed; re-proposing an already-proposed mitigation is rejected with HTTP 409, so a double click never creates a duplicate draft.

Methodology Rules

Architecture Summary