AI Research System / Validators and Handoffs

Validators and Handoffs

Validators, completions, handoffs, screenshots, and commits are checked-state receipts, not proof or permission expansion.

Read checked scope Human gates AgentJob lifecycle

Validator PASS and handoffs preserve checked evidence; they do not become proof or promotion decisions by themselves.

Validator PASS means a named check accepted the checked state. It does not prove physics, expand roles, issue Gate Chair approval, adopt source claims, or make generated pages authoritative. Handoffs transfer state; they do not silently continue a closed job.

Static diagram

Read PASS as scoped checked-state evidence.

The validator boundary diagram shows the changed surface, focused check, receipt, PASS scope, handoff, and the no-claim-promotion boundary.

Diagram showing changed surface, focused check, command or screenshot receipt, PASS for checked state, and no claim promotion. — The diagram illustrates validator PASS as a flow from changed surface through focused check, receipt evidence, checked state, and handoff context.

Checked scope

Every validation statement needs a non-scope.

A useful operator page says what was checked and what was not checked. This prevents green checks from being read as broad authority.

Surface	Checked scope	Non-scope
Changed file surface	Focused validators and tests check the files, manifests, links, layout language, SVG policy, build output, or control records in scope.	They do not validate unmodified surfaces or future route families.
Command evidence	Command output records whether a named check accepted the checked state.	Command PASS does not prove scientific claims, authorize roles, or issue human approval.
Screenshot or browser QA	Rendered evidence can catch layout overflow, missing headings, broken navigation, or visual-policy issues.	Screenshots do not make copy source authority or prove underlying source claims.
Completion record	The completion records outputs, validation, uncertainty, browser QA, and next recommendation for one job.	Completion does not widen the job or promote the result.
Handoff	The handoff preserves durable state and recommends one separate next packet.	A handoff does not silently continue the closed job.
Local checkpoint	A commit can seal the allowed transaction after completion evidence exists.	A checkpoint is not deployment, owner acceptance, source adoption, or proof.

PASS limits

Positive signals remain scoped signals.

Validators, registries, handoffs, commits, and screenshots are all valuable when interpreted at their proper grain.

Signal	What it says	What it does not say
Validator PASS	The named deterministic check accepted the checked state.	Theorem proof, ontology adoption, benchmark promotion, Gate Chair approval, or role expansion.
Registry row	A tracked record is discoverable with metadata.	The metadata proves the scientific content.
Handoff complete	Durable state was transferred with next-route context.	The next route has already executed.
Commit exists	Repository history preserves the local transaction.	Publication acceptance, deployment, or upstream source mutation.
Rendered page passes QA	The reader surface behaved correctly for checked viewports.	The reader surface became source authority.

Completion and handoff chain

Receipts close the current packet and protect the next one.

Good handoff practice does not hide continuation. It records exactly where the current job ends and what a future live packet must reopen.

Artifact	Purpose	Boundary
Completion	Close one job with outputs, validation, uncertainty, and forbidden conclusions.	Receipt, not proof or future permission.
Handoff YAML	Transfer state, stop conditions, next route, and validation evidence.	Routing evidence below live program state.
Handoff Markdown	Make continuation state readable for maintainers.	Human-readable summary, not new source authority.
Program state	Point to the active task, current job, latest handoff, and next action.	Compact live pointer, not proof surface.
Checkpoint	Commit the allowed packet after evidence exists.	Local audit history, not push, deploy, or owner acceptance.

Source basis

Operational evidence stays below source authority.

This route explains how to read checks and receipts. It does not alter command semantics, validator behavior, or the upstream workflow.

Source area	Used here for	Authority boundary
Validator/operator workflow	PASS-result limits, evidence receipts, screenshot QA, and checked-surface classification.	Operational validation cannot promote claims.
Research-control workflow	Completion, handoff, one-job rule, program-state pointer, and checkpoint expectations.	Workflow records preserve state; they do not prove science.
Tooling/runtime requirements	Command purpose, evidence produced, validates, does-not-validate, and failure interpretation.	Runtime capability is separate from write authority.

Related internal routes