You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Forge needs a lightweight way to surface regressions, stuck workflows and critical evidence changes before they become silent failures. The old Sentinel concept was directionally correct—deterministic signals first—but it mixed project-specific scheduling with detection and could have become an always-on LLM scanner.
VNext supplies the correct separation: #341 owns schedule/event delivery, #342 owns external adapters/escalation Operations, #356 produces recurring proof evidence and #189 owns autonomy effects. Sentinel owns only deterministic detection, finding lifecycle and controlled escalation.
Desired Outcome
Forge maintains deduplicated evidence-backed Sentinel findings from deterministic Project/Mission/runtime signals. Trigger occurrences run cheap detectors first; unchanged/healthy observations use zero model calls. Findings preserve history, resolve when source state recovers, can request bounded analysis/operator action, and can trigger autonomy review/revocation before any speculative repair.
Sentinel cannot directly edit code, merge, deploy, control services or widen Grants.
User Story
As the Forge operator,
I want important regressions and stuck/unsafe states surfaced automatically with evidence and one clear recovery path,
So that ongoing Workforces remain observable without paying for noisy LLM polling or allowing a detector to become an autonomous repair agent.
Requirements
A. Finding contract
Persist versioned findings with stable identity, Project/Mission/Resource scope, type/severity, deterministic source signal/detector version, first/last observed times, Resource/environment fingerprint, evidence refs, versioned dedupe fingerprint, state (open | acknowledged | resolved | suppressed), recommended escalation/action, linked runtime/goal/verification/GitHub records and latest recovery evidence.
Finding identity/history is durable; repeated observations append/update state rather than creating duplicate issue spam.
B. Detector framework
Implement small deterministic detectors before any model invocation. Initial required families:
persistent Mission/Trigger failure or repeated dead occurrence.
Each detector has explicit inputs, versioned fingerprinting, severity/default escalation, stale/recovery rules and bounded query scope.
C. Trigger ownership
Sentinel cadence/on-demand execution uses #341 Triggers. Do not add an internal timer/cron/LLM polling loop. A Trigger occurrence runs the relevant deterministic detector set for bound Resources/Missions.
D. Dedupe/observations
same underlying fingerprint updates one finding;
observation history is append-only/bounded by retention policy;
detector-version/fingerprint changes do not silently merge unrelated incidents;
suppression is explicit/scoped/audited and does not delete history/evidence.
E. Recovery/resolution
When deterministic source state recovers, Sentinel may resolve the finding while preserving prior observations. Resolution requires source-specific recovery evidence; absence of a new failure is not universally proof of recovery. Reappearance follows explicit reopen/new-occurrence policy.
F. Model usage
A model may be invoked only when deterministic evidence needs bounded classification, summarization or work-order drafting. Calls use #335 common invocation/budget/egress boundary with a small evidence packet. Model output is advisory Artifact data and cannot mutate finding evidence, Grants, autonomy or repair state by itself.
Preserve deterministic evidence before creating any repair request. #190 therefore waits for #342 rather than inventing interim connector/write paths.
H. No direct repair authority
Sentinel itself has no code-edit, repository-write, merge, service-control, broad network or credential authority. Follow-up remediation is a separately admitted Mission/Execution/Operation under current Grant/autonomy/budget policy.
I. Cost/frequency guards
Configure Trigger cadence, detector query limits, escalation cooldown and optional model-call budget. Healthy/unchanged scans terminate with zero model calls. Repeated same finding does not repeatedly spend model tokens unless evidence/policy changed materially.
J. Operator controls
Authenticated APIs/UI support inspect, acknowledge, suppress/unsuppress and request an allowed follow-up. Show source evidence, first/last observation, severity/state, linked autonomy effect and exact recovery/next step.
Very Large - detector/finding/escalation framework, expected as 5-8 small PRs after Trigger, adapter and autonomy foundations land.
Technical Notes
Prefer many small transparent deterministic detectors over one “AI health agent.” Sentinel is a signal/evidence control-plane component, not a parent model.
Parent Epic: #184
Execution mode: implementation
VNext programme: #333
Depends on: #189, #341, #342, #356
Consumed by: #343, #191
Related execution/evidence: #188, #335
Problem Statement
Forge needs a lightweight way to surface regressions, stuck workflows and critical evidence changes before they become silent failures. The old Sentinel concept was directionally correct—deterministic signals first—but it mixed project-specific scheduling with detection and could have become an always-on LLM scanner.
VNext supplies the correct separation: #341 owns schedule/event delivery, #342 owns external adapters/escalation Operations, #356 produces recurring proof evidence and #189 owns autonomy effects. Sentinel owns only deterministic detection, finding lifecycle and controlled escalation.
Desired Outcome
Forge maintains deduplicated evidence-backed Sentinel findings from deterministic Project/Mission/runtime signals. Trigger occurrences run cheap detectors first; unchanged/healthy observations use zero model calls. Findings preserve history, resolve when source state recovers, can request bounded analysis/operator action, and can trigger autonomy review/revocation before any speculative repair.
Sentinel cannot directly edit code, merge, deploy, control services or widen Grants.
User Story
As the Forge operator,
I want important regressions and stuck/unsafe states surfaced automatically with evidence and one clear recovery path,
So that ongoing Workforces remain observable without paying for noisy LLM polling or allowing a detector to become an autonomous repair agent.
Requirements
A. Finding contract
Persist versioned findings with stable identity, Project/Mission/Resource scope, type/severity, deterministic source signal/detector version, first/last observed times, Resource/environment fingerprint, evidence refs, versioned dedupe fingerprint, state (
open | acknowledged | resolved | suppressed), recommended escalation/action, linked runtime/goal/verification/GitHub records and latest recovery evidence.Finding identity/history is durable; repeated observations append/update state rather than creating duplicate issue spam.
B. Detector framework
Implement small deterministic detectors before any model invocation. Initial required families:
needs-clarification, dependency-blocked or agent-blocked work;Each detector has explicit inputs, versioned fingerprinting, severity/default escalation, stale/recovery rules and bounded query scope.
C. Trigger ownership
Sentinel cadence/on-demand execution uses #341 Triggers. Do not add an internal timer/cron/LLM polling loop. A Trigger occurrence runs the relevant deterministic detector set for bound Resources/Missions.
D. Dedupe/observations
E. Recovery/resolution
When deterministic source state recovers, Sentinel may resolve the finding while preserving prior observations. Resolution requires source-specific recovery evidence; absence of a new failure is not universally proof of recovery. Reappearance follows explicit reopen/new-occurrence policy.
F. Model usage
A model may be invoked only when deterministic evidence needs bounded classification, summarization or work-order drafting. Calls use #335 common invocation/budget/egress boundary with a small evidence packet. Model output is advisory Artifact data and cannot mutate finding evidence, Grants, autonomy or repair state by itself.
G. Escalation through #342
Supported escalation policies include:
Preserve deterministic evidence before creating any repair request. #190 therefore waits for #342 rather than inventing interim connector/write paths.
H. No direct repair authority
Sentinel itself has no code-edit, repository-write, merge, service-control, broad network or credential authority. Follow-up remediation is a separately admitted Mission/Execution/Operation under current Grant/autonomy/budget policy.
I. Cost/frequency guards
Configure Trigger cadence, detector query limits, escalation cooldown and optional model-call budget. Healthy/unchanged scans terminate with zero model calls. Repeated same finding does not repeatedly spend model tokens unless evidence/policy changed materially.
J. Operator controls
Authenticated APIs/UI support inspect, acknowledge, suppress/unsuppress and request an allowed follow-up. Show source evidence, first/last observation, severity/state, linked autonomy effect and exact recovery/next step.
Implementation Sequence
Primary Code Seams To Inspect First
Orthogonal Checkpoints
Acceptance Criteria
Out of Scope
Implementation Scope
Very Large - detector/finding/escalation framework, expected as 5-8 small PRs after Trigger, adapter and autonomy foundations land.
Technical Notes
Prefer many small transparent deterministic detectors over one “AI health agent.” Sentinel is a signal/evidence control-plane component, not a parent model.