Workflow
Workflow
Read the full state-to-handoff record chain around the job envelope.
Open routeAI Research System / AgentJob Lifecycle
AgentJob Lifecycle
An AgentJob is one auditable permission envelope for one transaction, not reusable permission and not scientific proof.
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 each bounded request into an inspectable record chain rather than giving an AI system general permission to act. At the center of that chain, one AgentJob is a single-use contract that names the request, source boundary, allowed reads and writes, forbidden paths, expected outputs, validators, claim limits, and stop conditions before work begins.
A Director decision chooses the route, an execution-role record binds the role to that one job, and a completion records the files changed, checks run, uncertainty, and result; any later work must begin through a separate handoff and new packet. This page explains that permission envelope so a general reader can distinguish what the job may inspect, change, and verify from what remains outside its authority. An AgentJob, validator PASS, completion, handoff, or local checkpoint can document one transaction, but none independently proves a physics claim, promotes the proposed ontology, authorizes upstream changes, or becomes reusable permission.
Static diagram
Read AgentJob lifecycle records as a narrowing chain.
The record-chain diagram shows how Director decisions, execution-role evidence, command receipts, completions, and handoffs close one transaction.
Permission envelope
The contract states what may happen and what must not happen.
The useful abstraction is small: one job, one allowlist, one validator set, one closeout. Anything outside the envelope requires a stop, handoff, or fresh tracked authorization.
| Envelope part | Purpose | Boundary |
|---|---|---|
| Input and objective | State the exact request, task context, source boundary, and expected transaction result. | An objective is not broad permission to solve adjacent problems. |
| Allowed reads | Name the source files, registries, schemas, tasks, handoffs, and prior records that may be inspected. | Allowed reads are evidence inputs, not claim promotions. |
| Allowed writes | Name the exact website or control-record paths that may change during this one job. | Allowed writes do not authorize unlisted routes, source refreshes, or upstream mutation. |
| Forbidden classes | Make stop conditions explicit before execution begins. | A forbidden class requires a stop, a new packet, or a tracked human gate. |
| Validators | Declare required checks for changed files, manifests, links, build output, browser behavior, and control records. | Validator PASS means operational consistency, not scientific proof. |
| Expected outputs | List the route files, manifests, ledger updates, and control evidence that completion must account for. | Output existence is not source adoption or publication acceptance. |
| Completion | Record changed files, command evidence, verdict, uncertainty, browser QA, and requirements satisfied. | A completion closes the job; it does not widen the job. |
| Handoff | Transfer durable state and recommend a separate next packet. | Handoff is not reusable permission or silent continuation. |
Lifecycle receipts
A closed AgentJob leaves evidence, not open-ended authority.
The lifecycle is intentionally transactional. Opening, executing, validating, completing, handing off, and checkpointing each have a receipt and a non-scope.
| Lifecycle event | Receipt | Non-scope |
|---|---|---|
| Job opened | Task, job, and handoff records exist with one active job. | The open job does not authorize adjacent route families. |
| Execution bounded | Reads, writes, expected outputs, validators, and stop conditions are inspectable before edits. | The model behavior inside the job does not become source authority. |
| Validation recorded | Required validators are run and attached to completion evidence. | PASS is not theorem proof, benchmark promotion, ontology adoption, or human acceptance. |
| Completion written | The completion records files changed, evidence, uncertainties, and next recommendation. | Completion does not convert expected outputs into adopted source claims. |
| Handoff separated | The handoff names what can happen next under a future packet. | The closed AgentJob cannot be reused as permission for the next job. |
| Checkpoint sealed | A local commit may preserve the allowed transaction after completion evidence exists. | A checkpoint is not deployment, publication acceptance, upstream mutation, or proof. |
Validation limits
Operational signals must not be overread.
The AgentJob lifecycle is a strong audit pattern precisely because it separates operational evidence from source, scientific, and human-gate authority.
| Signal | What it says | What it does not say |
|---|---|---|
| Allowed reads | These are sources the job may inspect. | The job adopts every strong claim found in those sources. |
| Allowed writes | These are the only files the job may change. | The job has general project permission. |
| Validator PASS | Named checks accepted the checked operational state. | The science is proven, a theorem is established, or a benchmark is promoted. |
| Completion | The transaction closed with evidence, outputs, uncertainty, and next recommendation. | The result becomes broad truth or future write authority. |
| Handoff | A separate next packet can be opened if live control records authorize it. | The current AgentJob silently continues. |
Source basis
The page explains the stable contract shape.
Historical examples are useful only when presented as dated examples. This greenfield page keeps the durable reader model focused on the AgentJob artifact class.
| Source area | Used here for | Authority boundary |
|---|---|---|
| Research-control documentation | One-job rule, lifecycle order, completion evidence, handoff separation, and checkpoint boundary. | Control records govern; website pages explain. |
| AgentJob schema | The stable envelope parts: inputs, allowed reads, allowed writes, validators, outputs, and claim boundary. | A schema is not an active job without tracked task-local instantiation. |
| Current-frontier and workflow PRDs | Dated snapshot behavior, blocked overreads, and validation-as-operations language. | Planning artifacts do not grant scientific or upstream authority. |