Inspector Pattern Catalog

The Scenario

The Inspector Pipeline is observing decision traces from three cells using spec-writer@2.1.0. A pattern emerges.

vehicle-platform : declared confidence 0.7-0.95 -> downstream acceptance 88%
data-platform    : declared confidence 0.6-0.90 -> downstream acceptance 91%
frontend-product : declared confidence 0.65-0.85 -> downstream acceptance 47%

The anomaly: frontend-product has downstream acceptance far below the others despite similar declared confidence. The agent says it's confident, but the outputs are being rejected.

The Detected Pattern

spec-writer's confidence formula weights input_familiarity equally across domains, but it was trained primarily on backend/infrastructure specifications. Frontend specifications represent a domain shift the current formula does not account for.

proposal:
  type: capability_refinement
  capability: spec-writer @ 2.1.0
  proposed_action: add domain-aware confidence weighting
  evidence:
    period: 90 days, 247 invocations across 3 cells
    frontend-product calibration_delta: 0.31  # exceeds 0.15 tolerance
  proposed_outcome: spec-writer@2.2.0 (minor, backward compatible)
  status: filed_for_capability_maintainer_review

What This Illustrates

• Pattern detection operates on metadata — the Inspector reads declared confidence, acceptance, cell IDs; not the actual outputs. This preserves privacy.
• Multi-cell comparison reveals hidden issues — one cell's 47% could be explained many ways; the comparison localizes the problem to the agent's interaction with that domain.
• The pattern becomes a concrete proposal — with specific evidence, action, impact, and risks. Detection produces proposals; proposals produce decisions; decisions produce changes; changes produce new traces.
• The maintainer retains authority — the Inspector proposes; the maintainer decides. The framework does not auto-promote.