Workflow
Workflow
Read the full state-to-handoff lifecycle.
Open routeAI Research System / Validators and Handoffs
Validators and Handoffs
Validators, completions, handoffs, screenshots, and commits are checked-state receipts, not proof or permission expansion.
The Æther Flow Project is a two-part research program about foundational physics and the governed, human-accountable AI research system used to organize and test that work. Its physics track asks whether ordinary general relativity can be interpreted, and eventually derived, from a deeper Æther or Æther-Flow foundation; general relativity remains the exact benchmark for observable gravity, while the first-principles substrate derivation is still open.
The AI track turns research steps into bounded, inspectable transactions in which one job names the allowed work, expected outputs, checks, claim limits, and stop conditions. A validator then answers one named question about the state actually checked—for example, whether the changed files follow a schema, preserve provenance, build correctly, or fit the approved write boundary—and says nothing automatically about unmodified surfaces, future changes, or scientific truth.
This Validators and Handoffs page explains the evidence chain that follows: a completion closes one job by recording outputs, validator results, remaining uncertainty, browser review, and conclusions the evidence does not license; a handoff transfers that durable state and recommends a separate next packet; program state points to the current job; and a local checkpoint seals the allowed transaction in repository history.
Screenshot review can expose overflow, missing headings, broken navigation, or other reader-surface defects, but it cannot make a website page source authority. Together, these records make research work easier to inspect and resume safely, but no validator PASS, completion, handoff, registry row, screenshot, commit, or webpage independently proves a physics claim, completes the open first-principles derivation, promotes the proposed ontology, expands role authority, deploys the site, or silently continues 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.
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. |