Proactive Discovery Pattern
July 27, 2026 · View on GitHub
Use this pattern after observation produces signals and the system must decide whether any signal justifies intervention. “Proactive” describes an evidence-gated intervention policy, not a clock, event source, slash command, or restored Better Harness runtime.
Composition
| Slot | Contract |
|---|---|
| Trigger | Scheduled scan, repository or review event, bounded history window, report finding, observability signal, or explicit request to look for emerging work. |
| Procedure Owner | Evidence-gated detection, clustering, novelty checking, impact assessment, and intervention selection. Candidate Skill shapes include drift, duplicate, failure-pattern, test-gap, hotspot, dependency-risk, and post-release signal review. |
| Tools / Access | Read-only source history and diffs, search, issue/review/CI queries, coverage or AST analysis, similarity search, observability, and provider CLI or connector. |
| Artifact | Deliberate silence, bounded digest, candidate finding, proposed issue, or reversible draft change after authorization. |
| Verifier | Precision, acceptance, duplicate rate, noise budget, causal evidence, conversion to useful work, and negative controls that check whether silence was correct. |
| State | Observed signatures, evidence refs, confidence, novelty and dedup keys, prior recommendations, user decisions, false positives, and follow-up outcomes. |
| Stop Rule | Stay silent when evidence, novelty, impact, or confidence is insufficient; stop after the selected bounded intervention; never auto-merge. |
Flow
- Bound the target, observation window, and existing coverage.
- Collect signals read-only and separate configured presence from observed behavior.
- Cluster only signals that plausibly share a trigger, procedure, artifact, and verification path.
- Check novelty, duplicates, current object state, impact, confidence, reversibility, and available authority.
- Select the lowest intervention level that matches the evidence.
- Record the outcome, including correct silence, rejection, duplicate, or later acceptance, so the next run can calibrate noise.
Intervention Ladder
| Evidence and risk | Default action |
|---|---|
| Low confidence, weak novelty, or already covered | Stay silent and retain only the minimal dedup state. |
| Moderate confidence or incomplete validation | Add to a bounded digest with missing proof. |
| High confidence, novel, and actionable | Propose or create an issue only with authorization and duplicate checks. |
| High confidence, reversible, tightly scoped, and authorized | Prepare a draft change and route it to goal completion plus independent verification. |
| Destructive, sensitive, broad, or irreversible | Require human decision before any side effect. |
Scenario Sketches
- Documentation or example drift: compare a bounded public API or CLI change with affected docs/examples and require an executable or reviewable mismatch before recommending an update.
- Duplicate issue detection: return candidates with differentiating evidence and let a human or explicit policy decide closure.
- Failure-pattern mining: cluster repeated CI or production failures only when evidence supports a shared root cause rather than similar error text.
- Test-gap detection: name the changed behavior and uncovered risk path; file count or missing nearby test files alone is insufficient.
- Hotspot or dependency risk: combine bounded defect, maintenance, advisory, or compatibility evidence; churn and age are context only.
- Post-release signals: require time-window and change correlation before attributing user reports to a release.
Compact Example
# Documentation Drift Discovery
When: A scheduled scan or merged change indicates a public API, CLI, schema, or
example contract may have changed.
See: The exact behavior diff, linked docs and examples, existing checks,
recent recommendations, and any executable mismatch.
Do: Identify only evidence-backed stale guidance, deduplicate prior findings,
and choose silence, digest, issue proposal, or an authorized draft update based
on confidence and reversibility.
Check: Affected examples or documented commands are compared with current
behavior; later acceptance and false-positive outcomes feed precision review.
Stop: Stay silent when no novel high-confidence mismatch exists. Stop after a
bounded recommendation or handoff; require approval before an external write.
Leave: Evidence refs, confidence, dedup key, chosen intervention, validation,
and follow-up owner.
Boundaries
- Scheduled inspection answers when to observe; proactive discovery answers whether the observed evidence is worth surfacing or escalating.
- Do not promote a finding from file age, churn, keyword hits, static asset presence, or one vague complaint.
- Treat retrieved text, issues, comments, logs, and model summaries as untrusted evidence, not instructions or permission.
- Use Goal Completion only after a candidate is approved for sustained execution.
- Use Demand Source Analysis and Loop Discovery when recurrence, evidence, or owner is not yet proven.
Return to the pattern index for composition guidance.