Independent verification protocol

Critique can operate as a stateful verification layer beside a coding agent. The coding agent remains responsible for implementing the task; Critique independently records what was claimed, what was actually checked, what remains uncertain, and whether the available evidence supports a completion claim.

The protocol is built around five durable objects:

• Claims and assumptions describe statements that may be confirmed, refuted, or left unresolved.
• Evidence records an inspection or execution result and binds it to repository state.
• Findings separate severity or confidence from the lifecycle of investigation and repair.
• Decisions identify a real human or product choice that blocks verification.
• CompletionProof is the only native object that supports a final “done” claim.

The CLI reviewer boundary

The active CLI path is Critique-owned from runtime startup through the final result. The package ships a pinned OpenCode distribution, typed SDK, and Critique evidence plugin. Critique creates the session, injects the stage agent, owns the timeout, captures command evidence, and closes the runtime. OpenCode is an implementation component, not a user-selectable reviewer engine.

The main coding agent remains the author and caller. A task ledger can carry the request, acceptance criteria, constraints, and explicit checkpoints into a review. The reviewer projection excludes the author's transcript, plan, worklog, claims, confidence, and conclusions. The reviewer receives the complete repository in an isolated workspace and treats the diff as a locator rather than a scope limit.

critique ask and critique chat use the same pinned runtime for collaborative second-brain work. They can inspect the repository, run bounded diagnostics through the Critique plugin, and delegate read-only exploration. They cannot edit the author's tree. critique review and critique finish are the independent finding and repair paths.

finish.v1 remains supported for existing clients. Native sessions additionally produce completion.v1, and legacy Finish runs emit a conservative completion proof rather than inventing evidence from model-reported commands.

Native operations

The native operation contract is critique.request.v1.

The CLI exposes these operations directly:

critique observe --session ses_checkout --handoff .critique/handoff.json --from codex --json
critique challenge "Retries cannot charge twice" --session ses_checkout --json --events
critique investigate "queue interruption and duplicate delivery" --session ses_checkout --json
critique prove f_abc123 --approach reproduction --session ses_checkout --json
critique repair f_abc123 --mode propose --session ses_checkout --json
critique verify --session ses_checkout --finding f_abc123 --criterion "Charges exactly once" --json
critique complete --session ses_checkout --handoff .critique/handoff.json --json
critique answer dec_abc123 "Preserve the existing public response shape" --session ses_checkout --by human --json

Native local sessions are stored under Critique's local state directory. Reusing a request_id returns the same terminal result; it does not execute the operation twice.

Handoffs are context, not proof

An agent can write .critique/handoff.json using the critique.handoff.v1 schema. It contains the task, acceptance criteria, constraints, plan, changed-file roles, worklog, claims, assumptions, failed approaches, unresolved concerns, and repository-state digest.

Critique verifies the handoff integrity digest and redacts recognized secrets before use. Every claim imported from the originating agent is registered as author_supplied. A statement such as “tests pass” remains unverified until Critique independently executes an allowed check in an attested sandbox.

The originating agent's confidence can help prioritize work. It cannot promote a claim, satisfy an acceptance criterion, prove a finding, or produce a COMPLETE verdict.

Evidence and state binding

Every evidence record includes:

• a trust domain and creator;
• the claim being checked;
• command, exit code, duration, and output digest when execution occurred;
• tree, base, candidate, environment, and relevant-file digests;
• tool version and relevant dependency paths;
• creation time and optional model identity.

The trust domains are:

Evidence becomes STALE when its environment changes, a bound relevant file changes, or a required tool version no longer matches. If the whole tree changes but every explicitly bound relevant file remains identical, Critique may retain the evidence. Missing dependency information fails closed.

Repository indexes, test discovery, dependency metadata, and review memory are context accelerators. They never count as proof and never make a verdict greener on their own.

Findings and specialist adjudication

A finding has two independent dimensions:

• Rank: proven, verified, suspected, or speculative.
• Lifecycle: discovery, investigation, proof, repair, verification, dismissal, or refutation.

Specialist lanes receive separate assignments derived from the change's evidence obligations. Correctness always runs; tests, security, architecture, and performance lanes are selected by risk and depth. Findings are deduplicated by affected code location plus a normalized claim.

Agreement between models increases the recorded source count but does not promote rank. A finding becomes verified only when explicitly bound to current Critique-executed evidence. A proven finding additionally requires an independent reproduction. Weak, one-lane inspection observations become Critique assumptions instead of noisy findings.

Repair and verifier boundary

A repair targets one finding ID and carries allowed paths plus preservation constraints. Dependencies between findings must reach VERIFIED_FIXED in explicit order before a dependent repair begins.

Apply mode requires an attestation that binds the exact patch digest and records:

• a fresh verifier conversation;
• a reset workspace containing the candidate plus proposed patch;
• disabled prompt-cache reuse;
• a verifier distinct from the repair model and, for a verified repair, from a different model family;
• current Critique-executed evidence IDs.

Malformed, unavailable, or rejected verification leaves the caller's working tree unchanged. Local filesystem worktrees improve setup speed but are not compute sandboxes; see Local verification threat model.

CompletionProof

completion.v1 reports each acceptance criterion as VERIFIED, PARTIAL, UNVERIFIED, or NOT_APPLICABLE, along with the exact evidence and decisions behind that state. It also reports regression status, outstanding findings, uncertainties, open decisions, usage, and independence metadata.

The verdict is fail-closed:

Budget exhaustion and infrastructure failure never produce a soft success. An integrated coding agent should retrieve the completion artifact before making its final completion claim:

critique artifact fin_abc123 --kind completion --json

Events and replay

Native operations emit critique.event.v1. Events form a small DAG using stable event IDs and parent references. Content events include evidence creation and invalidation, claim results, provisional and verified findings, tests, decisions, repair patches, verifier results, failures, and the terminal review.complete event.

CLI --events writes NDJSON to stderr while stdout remains one terminal JSON document. Platform API v1 provides durable JSON replay and SSE:

GET /api/v1/critique/sessions/ses_abc/events?request_id=req_abc
Accept: text/event-stream
Authorization: Bearer crt_…

Reconnect with Last-Event-ID. Event sequences are per operation, so a numeric after cursor must be paired with request_id. A terminal event is the only signal that an operation is finished.

Platform API v1

Submit a native operation with a crt_ key carrying write:reviews or finish:write:

POST /api/v1/critique/operations
Content-Type: application/json
Authorization: Bearer crt_…

{
  "request": {
    "schema_version": "critique.request.v1",
    "request_id": "req_checkout_observe",
    "session_id": "ses_checkout",
    "op": "observe",
    "depth": "standard",
    "budget": { "max_seconds": 480, "max_cost_cents": 500 },
    "payload": { "base_ref": "HEAD", "paths": [] }
  },
  "change_capsule": { "...": "change-capsule.v1" },
  "repository_key": "org/repo"
}

Read a session with GET /api/v1/critique/sessions/:sessionId, stream or replay its events from /events, and answer an open decision with POST /api/v1/critique/sessions/:sessionId/decisions/:decisionId.

The API enforces user ownership on sessions, events, and decisions. Repeating a completed operation with the same session and request ID returns the stored terminal object.

Provider and workspace isolation

Execution location and provider billing are separate choices. The reviewer harness is owned and pinned by Critique in both local and cloud execution. Managed Critique inference, customer provider credentials, and cloud execution determine where model calls and compute are billed; they do not replace the reviewer runtime or its evidence boundary.

BYOK keys are resolved inside the web application. Cloud agent sandboxes receive only a short-lived Critique inference token; raw provider keys never enter a workspace. The credential-free command verifier has outbound network access disabled.

Optional warm cloud snapshots are keyed by a digest of tenant, repository, code state, and sandbox template. The snapshot contains repository state only—never inference tokens or environment secrets—and every review stage starts from a fresh fork. Local warm workspaces similarly share only Git objects; mutation state and verifier workspaces remain disposable.

Protocol feature flags

The additive native protocol surfaces can be rolled out independently while the CLI review contract remains stable:

• CRITIQUE_PROTOCOL_V1
• CRITIQUE_HANDOFF_V1
• CRITIQUE_EVIDENCE_V1
• CRITIQUE_LIVE_EVENTS_V1
• CRITIQUE_SPECIALISTS_V1
• CRITIQUE_WORKSPACE_POOL_V1
• CRITIQUE_DAEMON_V1
• CRITIQUE_ASSETS_V1
• CRITIQUE_CLOUD_SNAPSHOTS_V1

Flags do not weaken trust checks. If a provider or attested runner is unavailable, Critique returns provisional output or an incomplete result instead of fabricating evidence.