[FEATURE] Add independent Verification Workforce execution

[Joncallim]

Parent Epic: #184
Execution mode: implementation
VNext programme: #333
Depends on: #336
Consumed by: #337, #189, #191

Problem Statement

A worker, reviewer prompt or model response cannot be allowed to declare its own implementation correct. Forge has manual review gates and execution evidence, but VNext needs a reusable independent Verification contract that separates deterministic checks, verifier evidence and authoritative Gate decisions. Without it, reliability/autonomy evidence can be circular self-assessment.

Desired Outcome

Forge can launch an independent Verification run against a completed Work Package/Execution or deterministic Operation result using fresh bounded context and no private reasoning transcript. It persists per-criterion structured findings/evidence under a separate identity, then a deterministic versioned Gate decides pass/rework/human-required from required evidence.

The verifier has no repository-write/merge authority.

User Story

As the Forge operator,
I want implementation/proof results checked independently from the worker that produced them,
So that completion and later earned autonomy rely on inspectable evidence rather than self-grading.

Requirements

A. Verification request contract

A versioned verification request pins:

• Mission/Execution/Work Package identity where applicable;
• producer Agent Run/Operation/result identity;
• objective and acceptance criteria;
• exact changed diff/Artifact/Resource versions to inspect;
• deterministic validation evidence already produced;
• required verification methods/policies;
• relevant repository/Workforce rules;
• risk classification;
• explicitly scoped prior blocking findings for re-verification;
• verifier budget/cognitive requirement/Grant.

Do not include the producer's hidden reasoning transcript or unbounded task history.

B. Deterministic checks first

Before any verifier model call, evaluate available deterministic evidence such as schema/Artifact integrity, lint/type/test/build/proof results, required evidence presence/freshness and Resource version match. If deterministic policy already establishes a hard failure/block, a model call is unnecessary.

C. Independent identity/context

Verifier Agent Run/Execution context is separate from producer identity. The producer cannot write the verifier result row/Artifact or mark itself independently verified. Context is freshly assembled under #335 budgets/egress and #336 read-only Resource Grants.

D. Criterion-level result

Every acceptance criterion reports one of:

• passed;
• failed;
• inconclusive;
• not_tested.

A verification run also has an overall evidence disposition such as passed | failed | inconclusive | blocked | needs_human_review; overall passed is impossible when required criteria/evidence are missing/inconclusive/not tested under policy.

E. Structured findings

Persist immutable findings containing stable finding identity/version, criterion/type/severity, affected Resource/file/surface where appropriate, evidence refs, verification method, verifier runtime/model snapshot, required remediation/follow-up, confidence only as advisory context, and re-verification lineage/status.

F. Trusted Gate

Verifier output is evidence. A deterministic Gate evaluator consumes required evidence + versioned policy and produces pass | rework | human_required | blocked. Neither verifier nor producer can bypass missing evidence by emitting PASS text.

G. Change-scoped rework

For implementation merge gates, a blocking finding must be caused, exposed or materially worsened by the current approved change and within acceptance/security criteria. Adjacent pre-existing improvements are preserved as separate follow-up issues/evidence, not injected into the current rework loop.

Re-verification receives only prior blocking findings plus current objective/evidence needed to judge remediation. It appends a new run/finding disposition; it never overwrites original findings.

H. High-risk verification

Policy may require a Security verifier/runtime class or human gate for specified risk/Capability/Resource classes. This is an additional evidence requirement, not permission for a model to authorize dangerous work.

I. Reliability integration

Only Gate-qualified independent verification outcomes become the verified evidence expected by #186/#189. Unverified worker success, missing verification, stale evidence or tampered Artifact identity does not count as a verified pass.

Implementation Sequence

1. Verification request/result/finding schemas — pure contracts + lineage/versioning.
2. Deterministic evidence preflight — missing/stale/tampered evidence fail-closed matrix.
3. Separate verifier Agent Run path — fresh bounded context, read-only Grant, [FEATURE] VNext Phase 1 — deterministic budget, routing, and context economics #335 broker.
4. Criterion parser/Artifact contract — structured results/findings; no prose-only authority.
5. Trusted Gate evaluator — deterministic pass/rework/human/block policy.
6. Re-verification lineage — immutable original finding + scoped rework evidence.
7. Change-scope policy — port reviewed stale-branch test cases onto current VNext contracts.
8. High-risk Security/human requirement — policy fixtures, no authority widening.
9. [FEATURE] Add capability reliability ledger #186 integration — only trusted independently verified evidence counts.
10. Standalone verification fixtures — verify one synthetic repository-change result and one generic deterministic Operation/proof result using current [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336 contracts. Integration with the actual [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 verification-goal runner happens later in [FEATURE] VNext Phase 3 — complete Software Engineering as the first generic Workforce #337, so [FEATURE] Add independent Verification Workforce execution #188 and [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 remain parallel rather than cyclic.

Primary Code Seams To Inspect First

• existing agent_runs, artifacts, approval/review gate stores
• current Reviewer/Security prompts/handoffs only as compatibility inputs
• [FEATURE] Normalize execution outcomes and stop reasons #185 canonical outcomes and [FEATURE] Add capability reliability ledger #186 capability attempts
• [FEATURE][ARCH] VNext Phase 0 — generic runtime contracts and compatibility seam #334 Artifact/Gate/Principal contracts
• [FEATURE] VNext Phase 1 — deterministic budget, routing, and context economics #335 invocation/context broker
• [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336 read-only Grant/confinement
• work-package acceptance criteria and diff/repository evidence

Orthogonal Checkpoints

1. Independence: producer tries to self-verify, shared context/state leakage, same identity mutation.
2. Evidence completeness: missing/stale/tampered diff/tests/Artifact/criterion, false pass attempts.
3. Scope: unrelated pre-existing bug, malicious broad reviewer, repeated rework scope expansion.
4. Security: hostile changed/source text, verifier tool request, high-risk policy bypass.
5. Lineage: re-verification, finding overwrite/reuse, Resource version drift.
6. Budget/failure: verifier provider failure, timeout, budget exhaustion, deterministic failure avoiding unnecessary model call.
7. Reliability: only trusted Gate result flows to [FEATURE] Add capability reliability ledger #186/[FEATURE] Add evidence-based earned autonomy policy engine #189.
8. Dependency isolation: implementation/tests must not import or require future [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 code; [FEATURE] VNext Phase 3 — complete Software Engineering as the first generic Workforce #337 is the explicit integration point.

Acceptance Criteria

• A producer cannot mark its own attempt independently verified.
• Verification uses separate identity and fresh bounded context without private reasoning transcript.
• Deterministic checks/evidence validation run before model-based verification where applicable.
• Every acceptance criterion is passed | failed | inconclusive | not_tested with evidence/method.
• Missing/stale/tampered required evidence cannot produce an overall verified pass.
• Verifier output is evidence and a deterministic Gate is authoritative.
• Re-verification appends history/lineage without overwriting original findings.
• Merge-gate rework contains only change-scoped blocking findings; adjacent defects require separate triage.
• High-risk work can require Security verifier/human Gate without widening execution authority.
• Only Gate-qualified independent verification feeds verified [FEATURE] Add capability reliability ledger #186/[FEATURE] Add evidence-based earned autonomy policy engine #189 evidence.
• [FEATURE] Add independent Verification Workforce execution #188 can close without [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 existing; its fixtures use generic current contracts and [FEATURE] VNext Phase 3 — complete Software Engineering as the first generic Workforce #337 owns later [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 integration.
• Tests cover independence, bounded context, deterministic preflight, scope control, re-verification, high-risk policy, fail-closed evidence loss and dependency isolation.

Out of Scope

• Replacing human final approval where policy requires it.
• Giving verifier repository-write/merge authority.
• Autonomy promotion/demotion ([FEATURE] Add evidence-based earned autonomy policy engine #189).
• Full reporting ([FEATURE] Add reliability, autonomy, and regression reporting #191).
• Providing hidden chain-of-thought to verifiers.
• Implementing the verification-goal runner ([FEATURE] Complete verification-goal on-demand proof execution through VNext #355).

Implementation Scope

Large / trust-critical - expected as 4-6 small PRs immediately after #336, in parallel with #355.

Technical Notes

The repository-wide orthogonal review skill can remain broad when the operator explicitly asks for a repo audit. This issue's merge-gate verifier should be bounded to the approved change so verification cannot become an endless adjacent-improvement generator.

[Joncallim]

VNext architecture constraint — 2026-09-03 repo audit

The independent-verification direction remains valid, but this issue must now be implemented through the generic VNext contracts rather than as a coding-only authority path.

Before restoring ready-for-agent:

• the verifier is a Principal/Agent Run operating under a bounded Grant and fresh context;
• verifier output is a structured evidence Artifact, not the authoritative gate decision;
• a trusted deterministic Gate evaluator consumes versioned policy + required evidence and decides pass | fail | human_required;
• missing/stale/malformed evidence fails closed;
• the verifier cannot obtain repository-write, merge, credential, or other authority by virtue of being a Verification/Security role;
• model/provider choice must use [FEATURE] VNext Phase 1 — deterministic budget, routing, and context economics #335's deterministic budget/routing boundary and be attributable through receipts;
• the implementation should be reusable by later non-coding Workforces, not hardwired solely to Project/Task/Git semantics.

ready-for-agent was removed and needs-clarification added pending that contract rebase.

[Joncallim]

Hostile verification addendum — exact evidence-set identity, stale-pass invalidation, and verifier independence that survives retries

A fresh cross-phase pass against SPEC-0002/0003/0007/0008/0012 and the new Phase-0 Execution-lineage contract found several trust conditions that need to be explicit before #188 can safely feed #186/#189/#337.

1. Verification is bound to an immutable evidence-set identity, not merely an Execution/Work Package

A verification request must pin an exact verification subject manifest containing at least:

• Mission + exact execution_id and state revision;
• Work Package/Operation/result identities and immutable versions;
• exact objective/acceptance-criteria revision;
• exact diff/Resource/Artifact versions or digests;
• exact deterministic check/proof result identities and their governing definitions;
• exact policy/Gate definition revision;
• applicable Workforce/workflow revision;
• risk/security requirement revision;
• verification-request schema version.

Canonicalize this manifest deterministically and store a bounded domain-separated digest/reference. The Gate evaluates that exact immutable subject.

Changing any material input produces a new verification request/run. It must never silently reuse a prior pass merely because the Work Package or Task id is unchanged.

2. A prior pass becomes historical evidence when the subject changes; it does not remain current authority

Explicit invalidation cases include:

• new commit/diff/resource version;
• replan/objective or acceptance-criterion revision;
• deterministic proof rerun under a different definition/tool version when policy requires exact proof identity;
• policy/security requirement change;
• package/workflow revision change;
• material remediation that creates a new Artifact revision;
• Resource classification/binding revision affecting what was reviewed;
• Execution N+1 retry.

Do not mutate the old Gate result to “stale.” Keep it immutable and derive current applicability from exact subject/revision matching.

A pass for Execution N never authorizes Execution N+1 unless an explicit trusted policy says a specific immutable Mission-level Artifact/evidence is reusable and all bound revisions remain valid. Default is no cross-Execution pass inheritance.

3. Producer/verifier independence must be defined by authority and write domains, not vendor/model names

“Different Agent Run id” alone is insufficient if the same producer path can write verifier evidence or the verifier can modify its own subject.

Required separation:

• producer Principal/Agent Run cannot insert/update the verifier result/finding/Gate decision rows;
• verifier Principal has read-only Grants to the subject Resources/evidence and only narrowly scoped append authority for its own verification evidence Artifact/result through a trusted verifier writer;
• verifier cannot mutate implementation files, deterministic proof outputs, acceptance criteria, policy, Grants, Gate definitions, or the subject manifest it is grading;
• Gate evaluator is a distinct trusted deterministic authority from both producer and verifier;
• a model/provider may be the same SKU if policy permits; vendor difference is not the security boundary. The boundary is independent run/context/authority/evidence ownership. High-risk policy may require additional diverse evidence, but do not confuse model diversity with Grant separation.

Where DB role/routine protection exists from #334/#336, extend it so producer code paths cannot directly manufacture verification/Gate state.

4. The verifier context itself is an Artifact/provenance boundary

Before model-based verification, construct a bounded context manifest that records references/versions included, exclusions, classification, and construction-policy revision. The model receives a rendering of this context; the authoritative verifier input is the manifest, not an untracked prompt string.

Requirements:

• no hidden producer transcript/chain-of-thought;
• untrusted source/diff text is clearly data and cannot modify verifier system/policy/Grant fields;
• prior blocker text is referenced as immutable finding IDs, not copied as authority-bearing prose;
• context truncation that omits required evidence produces inconclusive/blocked, not optimistic pass;
• if context construction changes after admission, re-admit/re-run rather than pretending the old verification still covers it.

5. Criterion status and Gate result are separate and total

Do not let a parser infer overall success from prose.

For every required criterion, the result set is closed and total. Gate policy explicitly maps the vector of criterion statuses + required deterministic/security evidence to pass | rework | human_required | blocked.

Rules:

• any missing required criterion row => Gate cannot pass;
• not_tested/inconclusive cannot be treated as pass unless the policy explicitly marks that criterion non-required for this subject before verification;
• deterministic hard failure cannot be overridden by verifier confidence/prose;
• verifier failure/timeout/budget exhaustion is not a failed implementation criterion; it is verification unavailable/inconclusive with a stable causal reason;
• Gate evaluation error => blocked, never pass/rework by guess;
• human_required is not success and cannot feed [FEATURE] Add capability reliability ledger #186/[FEATURE] Add evidence-based earned autonomy policy engine #189 as verified pass.

6. Gate evaluation is idempotent over exact inputs

For a fixed Gate definition/policy revision + exact verification subject/evidence set, repeated evaluation must produce the same result.

Persist a stable Gate-evaluation identity/dedupe key over those exact inputs. Concurrent duplicate evaluators either converge on one immutable result or append byte-equivalent evidence; they cannot race into contradictory pass/rework states.

If policy changes, that is a new Gate evaluation against the same evidence with a new policy revision; preserve both histories and expose which evaluation is currently applicable.

7. Verification freshness has two different meanings

Separate:

1. content identity freshness — exact diff/Artifact/Resource version unchanged;
2. time-sensitive evidence freshness — an external/status/security proof is still within a policy-defined observation horizon.

An immutable old artifact can remain byte-identical while a dependency vulnerability, remote check, policy, or external condition becomes stale. Evidence types that are time-sensitive must declare their freshness rule and authoritative observation time.

Do not apply a generic age TTL to deterministic immutable evidence such as a content digest unless the policy says the underlying claim is time-dependent.

8. Rework lineage cannot let findings self-disappear

Each blocking finding has immutable identity + subject version + status history.

On remediation/re-verification:

• new verifier run explicitly addresses each prior blocker by finding ID;
• disposition is resolved | still_present | superseded_by_subject_change | human_required (exact vocabulary may differ);
• “not mentioned by the new reviewer” is not resolution;
• a finding can only be marked resolved by evidence on the new exact subject;
• if a subject change makes a finding no longer applicable, record why/version rather than deleting it;
• newly discovered change-scoped blockers are added; adjacent findings are separately triaged and cannot expand the bounded rework loop.

9. Contradictory verifier evidence fails safely

If deterministic evidence and verifier claims disagree, or two required verifier classes disagree:

• never pick the favorable answer;
• retain both immutable evidence sets;
• deterministic hard-invariant/security failures dominate model opinion;
• policy decides whether the contradiction maps to rework, human_required, or blocked;
• unresolved contradiction cannot become verified pass.

Do not add majority voting/ensemble semantics as a shortcut.

10. Verification cancellation/revocation and stale-worker fencing

Bind verifier run + Gate evaluation to exact Execution/subject generation.

Inject:

• producer changes subject while verification runs;
• Execution is cancelled/terminalized/retried;
• verifier Grant revoked mid-read or before model invocation;
• current security policy changes;
• stale verifier finishes after Execution N+1 becomes current.

The stale verifier may preserve historical evidence of what it saw, but it cannot publish a current applicable pass after its subject/admission generation is stale. Gate admission rechecks exact revisions before recording an applicable decision.

11. Verification audit is authoritative; UI logs are projections

Verification request creation, verifier evidence finalization, Gate evaluation, applicability/supersession, and human decisions (where applicable) need durable append-only audit correlation to Mission/Execution/subject/Gate identities.

Do not rely on best-effort Task logs/SSE for verification authority. Audit/event payloads remain bounded and contain refs/digests, not raw diffs/prompts/secrets.

12. Reliability/autonomy evidence must use applicable verification, not merely any historical pass

#186/#189 consumers must require:

• exact comparable cohort/subject semantics;
• currently applicable Gate-qualified pass;
• no stale subject/policy mismatch;
• no unresolved contradictory/hard-invariant evidence;
• no duplicate counting of re-verifications for the same logical attempt unless the reliability metric explicitly models rework.

A historic pass that was superseded by a later failing revision cannot continue raising autonomy/reliability evidence for the current revision.

13. Hostile conformance fixtures

Add at minimum:

• verifier pass on commit A, code changes to B before Gate -> A pass cannot apply to B;
• pass on Execution N, retry creates N+1 -> no inherited pass;
• producer attempts direct verifier/Gate row write -> denied;
• verifier attempts subject mutation/tool write -> denied;
• missing criterion row -> no pass;
• verifier timeout/provider failure -> verification inconclusive/unavailable, not implementation failure/pass;
• deterministic hard failure + model says pass -> Gate refuses pass;
• two concurrent Gate evaluations same inputs -> one deterministic result;
• policy revision changes after pass -> old immutable pass retained but applicability re-evaluated/new Gate run required as policy dictates;
• prior blocker omitted from re-review output -> blocker remains unresolved;
• contradictory Security/Reviewer evidence -> human/rework/block per policy, never optimistic pass;
• stale verifier finishes after subject revision/pointer advancement -> historical only, not current authority;
• malformed/model-injected result text cannot alter criterion IDs/policy/Grant/Gate result outside validated schema.

The strengthened invariant is:

Verification proves one exact immutable subject under one exact policy/evidence set. Independence is enforced through authority and write separation; a pass cannot float across revisions, retries, or missing evidence.