Authority
Source Authority
Read the source, registry, derivative, and retrieval class ladder.
Open routeDocuments / Governance / Registries
Registries are provenance and status maps. They help readers find the owner of a claim, but they do not prove physics or promote claims.
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.
Its AI track uses tracked tasks, Director decisions, bounded AgentJobs, roles, validation, memory preflight, completions, handoffs, and human gates so that theoretical work remains inspectable without becoming accepted physics by workflow alone. Registries are the project's tracked maps to the material and decisions behind both tracks: their rows can identify an owner, path, status, date, hash, relationship, or limit, but they do not replace the file or decision record they describe.
Source registries point to registered TeX for scoped physics and derivational claims and registered Markdown for authored guidance, contracts, schemas, publication briefs, and source specifications; a reader must still inspect the named source and preserve its exact qualification. Derivative registries connect PDFs, HTML explainers, GitHub-facing Markdown, wiki notes, and other generated reading surfaces to their inputs, while publication and relationship registries connect briefs, specifications, sources, and outputs without making the downstream surface canonical.
Workflow registries record bounded AgentJobs, Director decisions, roles, tasks, completions, and validation state; a row can show what happened and within which paths, but it cannot widen an allowlist, expand a role, or turn a validator PASS into a scientific verdict. Claim-boundary rows record allowed wording, forbidden overreads, and required gates, while the Distance-to-GR ledger records named open burdens and evidence paths; neither the boundary metadata nor a burden label executes a gate or closes the first-principles derivation.
A reliable reading sequence is to find the relevant row, open the owner it names, check the recorded status, date, source commit, or freshness boundary, and then state both what the row supports and what it cannot prove. A hash can identify the contents of a particular file, and an approval status can record a bounded publication or review state, but neither establishes scientific correctness.
As a Documents governance page, Registry Explorer presents these limits through contextual copy, tables, and provenance rather than a separate Source authority component section. No registry row, dashboard, hash, approval status, generated derivative, memory hit, validator PASS, review receipt, AI output, or website page independently proves a physics claim, completes the open first-principles derivation, promotes the proposed ontology or a benchmark, expands workflow authority, overrides a human gate, or replaces direct source inspection.
Static diagram
The claim-boundary explorer diagram is reused to show how registry rows feed checked snapshots and public readers while forbidden overreads remain blocked.
Registry families
The registry page starts with families so readers do not mistake every CSV row for the same kind of authority.
| Family | Examples | What it can say | What it cannot say |
|---|---|---|---|
| Source registries | TEX_SOURCE_REGISTRY, MARKDOWN_SOURCE_REGISTRY, publication source listings. | Which tracked source lane exists and where to inspect it. | The registry row alone proves the source claim. |
| Derivative registries | PDF, HTML explainer, generated wiki, and semantic registries. | Which generated surface exists and how it relates to source material. | A generated surface has become canonical authority. |
| Workflow registries | AgentJob, Director decision, role-execution, research-task, and project-improvement signal registries. | What workflow state or operational record is discoverable. | The workflow record proves physics or expands role authority. |
| Claim and burden registries | CLAIM_BOUNDARY_REGISTRY and DISTANCE_TO_GR_LEDGER. | Allowed wording, forbidden overreads, status boundaries, and open burden labels. | A dashboard, burden label, or row closes the derivation. |
| Publication and relationship registries | PUBLICATION_BRIEF_REGISTRY and source/derivative relationship rows. | How reader surfaces, briefs, source specs, and outputs are connected. | Publication quality grants source authority. |
How to read a row
A row is most useful when it is followed by owner inspection and a clear statement of what the row does not prove.
| Step | Action | Guardrail |
|---|---|---|
| Find the row | Use the registry to locate a source, derivative, task, role, claim boundary, or public asset. | Do not stop at the row when the claim depends on source text. |
| Inspect the owner | Open the source file, handoff, completion, publication brief, or manifest record named by the row. | The owner decides the claim class and current status. |
| Read status and date | Check approval status, freshness, source commit, or current-state boundary before reuse. | Outdated metadata is a maintenance signal, not proof or rejection. |
| Record the limit | State what the registry supports and what it cannot prove. | Registry dashboards show provenance and status; they do not prove physics claims. |
Proof limits
Registry metadata is important because it makes the project auditable. It remains metadata, not theorem proof or publication acceptance.
| Signal | Supports | Limit |
|---|---|---|
| Hash | File identity for a specific published or source object. | Hash integrity does not establish scientific correctness. |
| Approval status | Publication, asset, or review state for the named surface. | Approval status is not a theorem proof or source-law adoption. |
| Claim-boundary row | Allowed, forbidden, and gate-required wording for a scoped claim. | Boundary metadata does not execute the gate it describes. |
| Workflow row | Traceability for a task, job, role, or decision. | Traceability does not widen the original permission envelope. |