/omen

Omen LLM Fix Prompt Generation

Purpose: Omen-specific action verbs, suppression cases, template fields for the ## LLM Fix Prompt block paired with every actionable failure mode (RPN above threshold, AP not Low, not classified ACCEPT-RISK). Read when: Omen has enumerated failure modes via FMEA / pre-mortem / fault tree / Swiss Cheese / HAZOP and one or more modes warrant downstream action.

Universal authoring rules and prompt structure: _common/LLM_PROMPT_GENERATION.md. This file documents only Omen-specific verbs, suppression cases, template fields.

When Omen Emits a Fix Prompt

Omen does not write code, so every actionable failure mode is a hand-off. Pair a Fix Prompt with the failure mode whenever:

The OMEN_TO_* handoff (Builder, Beacon, Triage, Mend, Pulse) carries a fix_prompt field; populate it whenever Omen does NOT classify the mode as ACCEPT-RISK.

Omen Action Verbs

Each fix prompt declares one verb at the top of # Your task.

Verb Selection Heuristic

Severity == 9 or 10 (catastrophic) ─┬─ no concrete control yet ────────→ INVESTIGATE-FURTHER
                                     ├─ control exists, code change ────→ ADD-GUARDRAIL
                                     ├─ underlying blocked, workaround ─→ MITIGATE
                                     └─ runbook is the only response ──→ ADD-RUNBOOK

RPN > 200 OR AP == High ─┬─ detection gap is the critical layer ──────→ ADD-MONITOR
                          ├─ prevention gap is the critical layer ─────→ ADD-GUARDRAIL
                          ├─ recovery gap is the critical layer ───────→ ADD-RUNBOOK
                          └─ data missing for scoring ──────────────────→ INVESTIGATE-FURTHER

RPN 100-200 OR AP == Medium ─→ ADD-GUARDRAIL or ADD-MONITOR (whichever closes the bigger Swiss-Cheese gap)

RPN < 100 AND AP == Low AND Severity < 9 ─→ ACCEPT-RISK (with trigger condition for revisit)

Tiebreakers:

• Severity ≥ 9 always emits a Fix Prompt — catastrophic severity cannot be offset by low occurrence per Core Contract.
• When detection AND prevention are both gaps, prefer ADD-GUARDRAIL (prevention) and cross-link a follow-up ADD-MONITOR so the receiving agents see both layers.
• ADD-RUNBOOK is the right choice when the failure is rare-but-survivable and code-level prevention has poor cost / benefit.
• MITIGATE always documents why the underlying fix is not happening this cycle (cost, dependency, scope) — otherwise the receiving LLM may try to "really" fix it and exceed scope.

Omen-Specific Suppression Cases

Universal cases live in _common/LLM_PROMPT_GENERATION.md. Omen adds:

In all suppression cases, write a one-line note in the report explaining why.

Per-Failure-Mode Fix Prompt Template (Omen Fields)

Omen adds these Omen-specific blocks on top of the universal skeleton:

• Failure mode ID — tracking identifier (e.g., FM-007) so the receiving LLM and stakeholders can cross-reference the FMEA table
• RPN score — Severity × Occurrence × Detection (1-1000), and/or AP score (Low / Medium / High)
• Failure scenario — ordered "if X happens then Y, then Z" causal chain
• Detection gap — what would currently prevent or detect this failure (often "nothing")
• Trigger condition for revisit — for ACCEPT-RISK only — what observation should re-open the decision

## LLM Fix Prompt

```text
# Your task
<VERB> the failure mode described below.

# Failure mode context
- Failure mode ID: [e.g., FM-007]
- Title: [brief description]
- RPN score: [S × O × D = N]  (Severity [1-10], Occurrence [1-10], Detection [1-10])
- AP score: [High | Medium | Low] (AIAG-VDA, when applicable)
- Severity rationale: [why S = N — blast radius, user impact, data loss potential]
- Confidence: [HIGH | MEDIUM | LOW] (Omen's enumeration confidence)
- Source method: [pre-mortem | FMEA | fault tree | Swiss Cheese | HAZOP | bowtie]

# Failure scenario
1. [trigger / upstream cause]
2. [propagation step]
3. [observed failure mode]
4. [downstream impact / blast radius]

Location of risk: `<file or component>:<line or surface>` in `<function or boundary>`

# Detection gap
What currently prevents or detects this failure: [list current controls; if none, write "None — defense layers all permeable for this scenario"]
Swiss-Cheese layers analyzed: [layers with holes that align]

# Recommended action
Approach: [defensive control strategy — guardrail type, monitor SLI, runbook structure]
Files / surfaces to modify: [list with expected change per file]
Defensive controls:
- [library / pattern, e.g., `idempotency-key middleware`, `circuit-breaker (resilience4j)`, `Zod schema at boundary`]
- [framework-native control, e.g., DB unique constraint, queue dead-letter handler]
Constraints:
- [coupling / side-effect / backward-compat note]
- [latency / throughput budget if guardrail is hot-path]

# [MITIGATE only — Underlying status]
- Why the underlying cause is not addressed this cycle: [cost / dependency / scope reason]
- When it should be addressed: [trigger / next cycle]

# [INVESTIGATE-FURTHER only — Verification plan]
- Data to collect: [failure rate, blast radius sample, log query]
- Tooling: [Pulse query, Beacon dashboard, log scan]
- Decision threshold: [score adjustment that flips action verb]

# Acceptance criteria
- [ ] Guardrail / monitor / runbook in place at the cited location
- [ ] Failure scenario step [N] no longer reaches step [N+1] without detection
- [ ] Regression test added covering the trigger condition
- [ ] No new test failures in the affected module
- [ ] [ADD-MONITOR] Alert fires within [latency budget] of trigger event
- [ ] [ADD-RUNBOOK] Runbook reviewed by Triage owner

# Ruled-out alternatives (do not revisit)
- [alternative 1] — eliminated because [evidence, e.g., framework guarantee, prior incident outcome]
- [alternative 2] — eliminated because [evidence]

# What NOT to do
- Do not silence the symptom (catch-and-ignore, swallow logs, suppress the alert)
- Do not over-engineer beyond the cited failure mode — defense in depth is welcome but new dependencies require justification
- Do not bundle unrelated failure modes into the same change (one failure mode per prompt per Universal Rule 9)
- Do not weaken the existing Swiss-Cheese layers while adding the new one
- Do not expand scope beyond the cited files / surfaces unless evidence demands it
```

For ACCEPT-RISK, no Fix Prompt is emitted; instead the report records:

- Failure mode ID: FM-NNN
- Disposition: ACCEPT-RISK
- Rationale: [why action is deferred]
- Trigger condition for revisit: [observation that reopens the decision — e.g., "occurrence rate > 1/week", "new tenant onboarded above 10k events/sec", "regulatory change"]
- Owner: [decision-maker name / role]
- Review date: [YYYY-MM-DD]