Evidence profiles
An evidence profile says what kind of proof a task must preserve. It does not say how independently an agent may collaborate, whether implementation is complete, or whether a lifecycle write is authorized. agent_mode and evidence_profile are independent dimensions: changing either one never expands scope, destructive-action authority, external-system authority, validation requirements, or approval authority.
Runtime
Section titled “Runtime”Runtime evidence is for acceptance claims about executable behavior. A Runtime attempt captures a post-readiness, pre-write task baseline, changes at least one runtime-eligible declared target, and records executable validation against the current attempt. The implementation summary preserves the baseline identity, fresh runtime paths, validation commands, inherited criterion IDs, explicit adoptions, and an empty ineligible-path list.
A dirty diff is not automatically Runtime evidence. Pre-existing dirty targets need explicit adoption rationale at baseline, and only changes after that baseline are attributable to the attempt. Documentation-only prose cannot stand in for a claimed behavior change.
Contract
Section titled “Contract”Contract evidence freezes a specification, policy, schema, documentation contract, or other non-runtime agreement. It still needs current applicable validation, but it must not fabricate a baseline, fresh runtime path, or executable-behavior claim. Choose Contract only when no acceptance criterion requires changed runtime behavior.
Hybrid
Section titled “Hybrid”Hybrid evidence combines a contract change with Runtime proof. It carries the Runtime baseline and freshness obligations in addition to the authored contract evidence. Hybrid is useful when a new policy, schema, or documented boundary is accepted only if a conforming executable surface proves it.
Validation postures are separate
Section titled “Validation postures are separate”The repository recognizes three validation postures without treating any of them as implicit acceptance:
- Automatic declared-set execution uses
task validation-setagainst the exact current task revision. Preview returns deterministic shell-free argv, evidence paths, preconditions, and retry selectors without launching; apply records each command once in order and stops on the first required unsuccessful or unrecordable result. - Explicit selected-command execution uses
task validation-recordwith exact argv after--; preview does not launch the process, while apply executes it once and appends the revision-bound result. - Imported evidence uses a bounded verified result, source reference, and explicit provenance. Manual or CI records remain evidence-only and do not claim command-owned execution.
A waiver is a typed, auditable exception tied to a validation identity. It does not erase the planned command, turn blocked evidence into a pass, or grant authority to complete or close a task.
Selection rule
Section titled “Selection rule”Choose the smallest profile that can prove every acceptance criterion. If a criterion says code runs, output changes, or a behavior is enforced, use Runtime or Hybrid. If the criterion only freezes a contract and makes no runtime claim, Contract may be sufficient. Record the selected profile in the task agreement before readiness, then preserve it throughout the attempt.
Continue with Task agreement and implementation evidence for artifact ownership, Lifecycle records for the ordered record sequence, and Evidence requirements for the machine-consumer checklist.