Windags Premortem

---
license: BSL-1.1
name: windags-premortem
description: Failure pattern scanning and risk assessment for WinDAGs DAGs. Runs after decomposition but before execution. Performs a lightweight scan on EVERY DAG (BC-PLAN-004), escalating to deep analysis when recognition confidence is low or known failure patterns are found. Activate on "premortem", "failure scan", "risk assessment", "DAG validation", "timing analysis", "failure patterns", "pre-execution check". NOT for post-execution learning (use windags-curator), retrospective analysis (use windags-looking-back), or DAG construction (use windags-architect).
metadata:
  tags:
    - windags
    - premortem
    - failure-scan
    - risk-assessment
category: Agent & Orchestration
tags:
  - windags
  - premortem
  - risk-analysis
  - planning
  - prevention
---

# WinDAGs PreMortem

Scan every DAG for failure patterns before execution begins. Run the lightweight scan unconditionally. Escalate to deep analysis when warranted. Produce a `PreMortemResult` that the Executor uses to decide whether to proceed, monitor, or halt.

**Model Tier**: Tier 1 (Haiku-class)
**Behavioral Contract**: BC-PLAN-004

---

## When to Use

Use this skill when:
- A DAG has been decomposed and is awaiting execution
- The Executor needs a go/no-go recommendation
- Timing estimates are needed for the critical path
- You need to identify shared failure domains across parallel batches

Do NOT use for:
- Post-execution analysis (use `windags-looking-back`)
- Learning updates after execution (use `windags-curator`)
- DAG restructuring after failure (use `windags-mutator`)

---

## Behavioral Contract: BC-PLAN-004

**The PreMortem lightweight scan runs on EVERY DAG, including trivial depth-1 DAGs.**

No exceptions. No "this DAG is too simple to scan." A depth-1 DAG with a single node still gets the lightweight scan. The cost is negligible (Tier 1 model, structured checks). The risk of skipping is not.

---

## Two-Level Scan Architecture

```mermaid
flowchart TD
    DAG[DAG received from Decomposer] --> LW[Lightweight Scan]
    LW --> RC{Recognition confidence >= 0.7?}
    RC -->|Yes| FP{Failure patterns found?}
    RC -->|No| DEEP[Deep Scan]
    FP -->|None| PROCEED[Recommend: PROCEED]
    FP -->|Found| DEEP
    DEEP --> SEV{Severity assessment}
    SEV -->|Low| MONITOR[Recommend: ACCEPT_WITH_MONITORING]
    SEV -->|Medium| MONITOR
    SEV -->|High| ESCALATE[Recommend: ESCALATE_TO_HUMAN]
```

### Level 1: Lightweight Scan (Always Runs)

Execute these checks in order. Each check is a structured pattern match, not a generative task.

1. **Cascade Depth Check**: Walk the DAG and measure the longest path. Flag if depth > 3 with no isolation boundaries between failure domains.

2. **Shared Failure Domain Check**: For each parallel batch (wave), identify nodes that share a failure domain (same model provider, same API, same file system resource). Flag if any batch has > 50% of nodes in the same failure domain.

3. **Single Point of Failure Check**: Identify any node where `count(dependents) >= 3`. That node's failure cascades to 3+ downstream nodes. Flag it.

4. **Resource Contention Check**: Identify nodes in the same wave that require the same expensive resource (GPU, large model, exclusive file lock, rate-limited API). Flag contention.

5. **Timing Risk Check**: Estimate per-node duration using historical data or heuristics. Identify nodes on the critical path where a 2x slowdown would push total execution past the user's time expectation.

6. **Known Pattern Match**: Compare the DAG topology against the failure pattern library (see Failure Pattern Categories below). Log any matches with confidence scores.

### Level 2: Deep Scan (Conditional)

Trigger deep scan when:
- Recognition confidence < 0.7 (the Sensemaker was uncertain about this problem type)
- Lightweight scan found one or more failure patterns
- DAG depth >= 5 (complex enough to warrant deeper analysis)

Deep scan adds:

1. **Dependency Chain Analysis**: Trace every path from root to leaf. Score each path for fragility: `fragility = (path_length * max_fan_out) / isolation_boundaries`. Flag paths with fragility > 5.0.

2. **Failure Propagation Simulation**: For each flagged node, estimate the blast radius (how many downstream nodes fail if this node fails). Rank nodes by blast radius.

3. **Resource Budget Projection**: Sum estimated costs (tokens, API calls, time) across all nodes. Compare against the user's budget constraints. Flag if projected cost exceeds 80% of budget.

4. **Alternative Topology Suggestions**: If failure patterns are severe, propose specific mitigations:
   - Add isolation boundaries (split a wave)
   - Add redundancy (duplicate a critical node with a different model/skill)
   - Reorder waves to fail fast on high-risk nodes

---

## Failure Pattern Categories

Maintain and match against these five categories.

### 1. Cascading Dependency Chains

**Pattern**: Linear chain of depth > 3 with no isolation boundaries.
**Risk**: A single early failure wastes all downstream computation.
**Mitigation**: Insert checkpoint gates. Move high-risk nodes earlier. Add fallback paths.

### 2. Shared Failure Domains in Parallel Batches

**Pattern**: Multiple nodes in the same wave depend on the same external resource (API provider, model endpoint, file system).
**Risk**: One provider outage takes down the entire wave.
**Mitigation**: Distribute nodes across failure domains. Stagger API calls. Add circuit breakers per domain.

### 3. Single Points of Failure

**Pattern**: A node with fan-out >= 3 (three or more nodes depend on it).
**Risk**: This node's failure cascades broadly.
**Mitigation**: Add retry logic with backoff. Consider running the critical node with a more reliable (higher-tier) model. Add a fallback skill.

### 4. Resource Contention

**Pattern**: Multiple nodes in the same wave compete for the same scarce resource.
**Risk**: Serialization, timeouts, or resource exhaustion.
**Mitigation**: Stagger execution within the wave. Reduce parallelism for contended resources. Pre-allocate resources.

### 5. Timing Risks

**Pattern**: A slow node sits on the critical path with tight-deadline dependents downstream.
**Risk**: Delay cascades and the user's time expectation is violated.
**Mitigation**: Estimate critical path duration. Flag if critical path > 80% of user's time expectation. Consider parallel alternatives or faster model tiers for bottleneck nodes.

---

## Timing Analysis

Perform timing analysis on every DAG (lightweight level). This addresses the Chef's concern from the Constitutional Convention: users need realistic time expectations before execution begins.

### Critical Path Estimation

1. Assign each node an estimated duration:
   - Use historical execution data if available for the skill + model combination
   - Fall back to tier-based heuristics: Tier 1 = 5-15s, Tier 2 = 15-45s, Tier 3 = 30-120s
   - Add overhead per wave transition: 2-5s

2. Compute the critical path using longest-path algorithm on the DAG.

3. Compute total wall-clock estimate: `critical_path_duration + (wave_count * wave_overhead)`.

### Delay Cascade Identification

For each node on the critical path, compute `cascade_impact`:
```
cascade_impact = (node_duration / critical_path_duration) * count(downstream_nodes)
```

Flag nodes where `cascade_impact > 0.3` -- these are the nodes where a delay hurts the most.

### Time Budget Check

Compare estimated total duration against user expectation (if provided). Report one of:
- `WITHIN_BUDGET`: Estimate < 80% of user expectation
- `TIGHT`: Estimate is 80-100% of user expectation
- `OVER_BUDGET`: Estimate > user expectation (flag specific bottleneck nodes)

---

## Output Format

Produce a `PreMortemResult` with these fields:

```
PreMortemResult:
  scan_level: "lightweight" | "deep"

  failure_patterns_found:
    - pattern: string           # Category name
      severity: "low" | "medium" | "high"
      affected_nodes: [NodeId]
      description: string       # Human-readable explanation
      mitigation: string        # Suggested fix

  timing_analysis:
    critical_path_nodes: [NodeId]
    estimated_duration_seconds: number
    delay_cascade_nodes:
      - node_id: NodeId
        cascade_impact: number  # 0.0 to 1.0
    time_budget_status: "WITHIN_BUDGET" | "TIGHT" | "OVER_BUDGET"

  resource_analysis:
    contention_points:
      - resource: string
        competing_nodes: [NodeId]
        wave: number
    projected_cost: number      # Estimated total cost in dollars
    budget_utilization: number  # 0.0 to 1.0

  recommendation: "PROCEED" | "ACCEPT_WITH_MONITORING" | "ESCALATE_TO_HUMAN"
  recommendation_rationale: string
```

### Recommendation Decision Logic

```mermaid
flowchart TD
    START[Scan complete] --> HIGH{Any HIGH severity patterns?}
    HIGH -->|Yes| ESC[ESCALATE_TO_HUMAN]
    HIGH -->|No| MED{Any MEDIUM severity patterns?}
    MED -->|Yes| MON[ACCEPT_WITH_MONITORING]
    MED -->|No| OVER{Time OVER_BUDGET?}
    OVER -->|Yes| MON
    OVER -->|No| LOW{Any LOW severity patterns?}
    LOW -->|Yes| PRO_MON[PROCEED with notes]
    LOW -->|No| PRO[PROCEED]
```

- **PROCEED**: No significant risks found. Execute the DAG as planned.
- **ACCEPT_WITH_MONITORING**: Risks identified but manageable. Execute with enhanced monitoring on flagged nodes. The Executor activates the Resilience overlay.
- **ESCALATE_TO_HUMAN**: Serious risks found. Present the failure patterns and timing analysis to the user. Wait for human decision before proceeding.

---

## Integration with Meta-DAG

The PreMortem sits between the Decomposer and the Executor in the meta-DAG pipeline:

```mermaid
flowchart LR
    SM[Sensemaker] --> DC[Decomposer]
    DC --> PM[PreMortem]
    PM -->|PROCEED| EX[Executor]
    PM -->|ACCEPT_WITH_MONITORING| EX
    PM -->|ESCALATE_TO_HUMAN| HG[Human Gate]
    HG -->|Approved| EX
    HG -->|Rejected| DC
```

When the PreMortem recommends `ESCALATE_TO_HUMAN`, the Executor pauses and presents:
1. The failure patterns found (with severity and affected nodes)
2. The timing analysis (critical path, delay cascade nodes)
3. Suggested mitigations
4. Options: approve as-is, approve with mitigations applied, reject and re-decompose

---

## Performance Budget

| Operation | Target |
|-----------|--------|
| Lightweight scan | < 2s for DAGs with <= 20 nodes |
| Deep scan | < 8s for DAGs with <= 20 nodes |
| Failure pattern match | < 200ms per pattern category |
| Timing estimation | < 500ms |
| Total PreMortem overhead | < 3% of total execution cost |

The PreMortem must never become a bottleneck. If the scan itself takes longer than 10% of the estimated DAG execution time, truncate to lightweight-only and note the truncation in the result.

---

## Failure Pattern Library

Maintain a persistent library of failure patterns observed across executions. The Curator updates this library post-execution. The PreMortem reads it pre-execution.

Each pattern entry contains:
- `pattern_id`: Unique identifier
- `category`: One of the five categories above
- `topology_signature`: Graph structure that triggers the pattern
- `frequency`: How often this pattern has been observed
- `severity_distribution`: Historical severity outcomes
- `effective_mitigations`: Mitigations that worked in the past

The library starts with the five built-in categories and grows through execution experience. This is part of the learning loop (Principle 10).