Current
Current State
Read dated implementation-control context before interpreting live-looking workflow status.
Open routeAI Research System / Workflow
Workflow
One research or implementation request becomes one bounded workflow only after source state, authority boundaries, and validation obligations are made explicit.
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 makes each research or website request auditable by starting from tracked state, using memory only to locate sources, inspecting those sources, recording a Director decision, and binding one AgentJob to named roles, allowed files, expected outputs, validators, and claim boundaries. A completion record then states what happened and what remains uncertain, while a handoff identifies any later work as a separate packet before a local checkpoint seals the allowed transaction.
This Workflow page explains that chain so a general reader can see how authority narrows at each step; memory, role labels, child analyses, validator PASS, completions, handoffs, and commits can support an audit, but none of them independently proves a physics claim, expands the job, or replaces a protected human decision.
Static diagram
Follow one request through one bounded AgentJob chain.
The workflow diagram shows the request, Director decision, allowlist, execution, validators, completion, handoff, and bounded PASS scope.
Lifecycle
The route from tracked state to handoff narrows authority.
Each artifact answers one operational question: what state was read, which route was chosen, what one job may do, how it closed, and where the next separate packet begins.
| Stage | Artifact | Reader explanation | Boundary |
|---|---|---|---|
| Current state pointer | program_state.yaml | Names the active task, latest handoff, status, and next route so the operator starts from tracked state. | Compact pointer, not a proof surface or permanent website truth. |
| Memory preflight | Memory receipt and source inspections | Finds likely prior decisions and source paths before work begins. Memory preflight helps navigation; canonical sources remain authority. | Retrieval support only; useful hits must resolve back to tracked files. |
| Director decision | Director Decision Record | Selects one route, records why alternatives were not selected, and defines the authority surfaces used. | Routing record, not a scientific verdict. |
| Execution-role binding | Execution-role record | The execution-role record is the task-local authority contract that binds the selected role semantics to the job. | Role identity alone grants no permission. |
| AgentJob contract | AgentJob YAML | Defines one objective, allowed reads, allowed writes, expected outputs, validators, and claim boundary. | One bounded job; not reusable permission. |
| One bounded execution | Tool and file actions inside the allowlist | One invocation, one bounded AgentJob. Execution may use parent-child synthesis only as internal analysis inside one outer AgentJob. | Parent-child synthesis does not expand authority or create multiple independent jobs. |
| Completion record | Completion YAML | Records outputs, command evidence, validator results, uncertainty, forbidden conclusions, and next recommendation. | Validator PASS means operational consistency, not scientific proof. |
| Handoff | Handoff YAML and Markdown | Transfers durable state and names a separate next packet when more work remains. | A handoff is future routing context, not a silent extension of a closed job. |
| Checkpoint | Local commit | Seals the website-local transaction after evidence and validators are recorded. | Repository history is useful audit evidence, not proof or publication acceptance. |
Blocked overreads
Workflow evidence helps reasoning only when it stays scoped.
The strongest safeguard is adjacency: claim-boundary language appears next to workflow-power language, especially near validation, handoff, and parent-child synthesis.
| Workflow claim | Safe use | Blocked overread |
|---|---|---|
| One request can be made inspectable. | Route the request through tracked state, source inspection, one decision, one job, completion, handoff, and checkpoint. | Do not treat the workflow as autonomous scientific judgment or proof of a physics result. |
| Parent-child synthesis can compare perspectives. | Use Parent-child synthesis as internal decomposition inside one outer AgentJob when the source workflow allows it. | Do not present child artifacts as separate independent AgentJobs or expanded authority. |
| Validation can protect operational boundaries. | Read PASS as evidence that named checks accepted the checked repository state. | Do not infer theorem proof, ontology adoption, benchmark promotion, or model understanding. |
| Local obstruction can improve routing. | A local obstruction sharpens routing; it is not global theory rejection. | Do not convert a scoped failure into a global no-go claim without tracked authority. |
| Human gates can promote protected claims. | Human-gated promotion requires explicit tracked authority and remains separate from automated execution. | Do not treat completions, handoffs, commits, registries, or role labels as promotion. |
Source basis
This page explains source-backed artifact classes.
Stable workflow copy should describe record classes. If a future page shows task or handoff identifiers, they must be dated snapshot data under the current-state rules.
| Source area | Used here for | Authority boundary |
|---|---|---|
| Research-control workflow | One-job rule, Director decisions, AgentJob contracts, completions, handoffs, and validator limits. | Workflow authority stays in tracked upstream control files. |
| AgentJob and execution-role schemas | Artifact-class explanation for role binding, allowlists, outputs, validators, and claim boundaries. | Schemas explain shape; a live job still needs a tracked task-local record. |
| Current-frontier rules | Dated snapshot and stale-data behavior for any moving implementation-control example. | Transient task or handoff IDs are not stable website truth. |
| Validator and handoff explainers | PASS limits, completion receipts, handoff separation, and blocked-overread language. | Operational validation is not scientific proof. |