Roles
Roles and Schemas
Read the Gate Chair and role-authority model before promotion language.
Open routeAI Research System / Human-Gated Promotion
Human-Gated Promotion
Protected promotion is separate authority: automated workflow can prepare evidence, but it cannot issue the verdict.
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 can prepare candidate calculations, audits, refutations, documentation, validator results, completion records, and handoffs, but some decisions remain deliberately outside automated authority. Canonical ontology adoption, benchmark promotion, scientific claim closure, and a Gate Chair verdict require the explicit tracked human approval specified by the source process. Defining the Gate Chair in a role registry does not activate that authority, and a validator PASS, completion, handoff, commit, or public page cannot substitute for the required person and approval record.
This Human-Gated Promotion page explains how evidence can accumulate below that boundary: automated work may organize a question, preserve uncertainty, block unsafe conclusions, and demonstrate technical readiness, while the protected verdict remains separate. Publication acceptance and deployment are also separate owner decisions, not automatic effects of scientific or technical checks. Together, these controls make one research transaction easier to inspect, but none independently proves a physics claim, completes the open first-principles derivation, promotes the proposed ontology, or authorizes protected execution.
Static diagram
Keep human-gated promotion outside validator authority.
The human-gate map shows Gate Chair decisions, protected approvals, claim promotion, automation limits, and validator limits as separate boundaries.
Gate stack
Preparation is not promotion.
The gate model protects high-risk claims from being laundered through operational signals. Evidence can accumulate without becoming a verdict.
| Layer | Can prepare | Cannot decide |
|---|---|---|
| Draft/control evidence | Candidate, audit, refutation, selector, or documentation artifacts can prepare the question. | Preparation does not promote a source law, benchmark, ontology claim, or downstream physics result. |
| Validators and tests | Checks can confirm structure, state, provenance, and boundary preservation for the checked surface. | PASS does not issue Gate Chair approval or prove theorem correctness. |
| Completion and handoff | Receipts can preserve evidence, uncertainty, blocked conclusions, and the next route. | A handoff that names a gate has not executed that gate. |
| Registry and claim-boundary rows | Rows can make status, provenance, and blocked overreads discoverable. | Registry metadata is not protected promotion. |
| Explicit human gate | Tracked human approval can authorize protected execution when the source process requires it. | No website page can create or simulate that approval. |
Protected actions
Automated outcomes stay below protected authority.
This page deliberately places promotion language after the gate explanation. That order prevents validators, completions, and handoffs from reading like hidden promotion paths.
| Protected action | Automated outcome may show | Required gate |
|---|---|---|
| Canonical ontology adoption | A role output, validator PASS, or completion may prepare evidence. | Explicit tracked source authority must authorize adoption. |
| Benchmark promotion | Tests, screenshots, and completion receipts may show operational readiness. | Protected promotion remains a separate source and human-gated path. |
| Gate Chair verdict | A role registry row can define the role; a handoff can recommend a gate. | Gate Chair authority is not active without explicit tracked approval. |
| Scientific claim closure | Local obstructions, freezes, and validations can sharpen routing. | Closure needs the source-side authority required by the claim class. |
| Publication acceptance | A local checkpoint and page validation can prove technical readiness. | Owner acceptance and deployment remain separate from automated checks. |
Blocked overreads
The public reading must not confuse readiness with verdict.
The same records that make the project auditable can become misleading if their scope is not stated beside them.
| Unsafe overread | Correct reading |
|---|---|
| A validator passed, therefore the claim is promoted. | Validator PASS means operational consistency for the checked state, not claim promotion. |
| A handoff names a gate, therefore the gate happened. | Handoff language transfers state and recommends a next packet; execution requires a later tracked authorization. |
| Gate Chair exists in the registry, therefore it can execute now. | The role is human-gated and paused unless explicit tracked approval exists. |
| A website page explains promotion, therefore it approves promotion. | The website explains the authority model and cannot become source authority. |
Source basis
Gate language is source-bound.
A public explainer can state the rule. It cannot make the protected decision or substitute for the tracked approval record.
| Source area | Used here for | Authority boundary |
|---|---|---|
| Role and schema requirements | Gate Chair status, role authority, and active-versus-paused language. | Planning and website copy cannot activate a protected role. |
| Workflow and validator requirements | Completion, handoff, PASS, and checkpoint boundaries. | Operational receipts prepare evidence; they are not protected verdicts. |
| Claim-boundary registry and current-state rules | Blocked overreads and dated examples when current source status is shown. | Moving source status requires dated snapshot behavior. |