Documents / Governance / Registries

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.

Animated registry provenance map Registry families point to source, derivative, workflow, claim, and publication records while proof remains outside the registry map.
Registry rows preserve status and provenance; they do not replace source inspection or human-gated decisions.

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

Read registries as typed control records.

The claim-boundary explorer diagram is reused to show how registry rows feed checked snapshots and public readers while forbidden overreads remain blocked.

The diagram illustrates how claim-boundary registry rows feed checked snapshots and public explorer views while blocked overread paths stay separated.
Diagram showing the claim-boundary registry feeding a checked-in snapshot and public explorer while forbidden overreads remain blocked.

The diagram illustrates how claim-boundary registry rows feed checked snapshots and public explorer views while blocked overread paths stay separated.

Registry families

Rows are maps to evidence, not the evidence itself.

The registry page starts with families so readers do not mistake every CSV row for the same kind of authority.

FamilyExamplesWhat it can sayWhat it cannot say
Source registriesTEX_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 registriesPDF, 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 registriesAgentJob, 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 registriesCLAIM_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 registriesPUBLICATION_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

Registry use is a four-step source-inspection workflow.

A row is most useful when it is followed by owner inspection and a clear statement of what the row does not prove.

StepActionGuardrail
Find the rowUse 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 ownerOpen 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 dateCheck approval status, freshness, source commit, or current-state boundary before reuse.Outdated metadata is a maintenance signal, not proof or rejection.
Record the limitState what the registry supports and what it cannot prove.Registry dashboards show provenance and status; they do not prove physics claims.

Proof limits

Positive registry signals stay scoped.

Registry metadata is important because it makes the project auditable. It remains metadata, not theorem proof or publication acceptance.

SignalSupportsLimit
HashFile identity for a specific published or source object.Hash integrity does not establish scientific correctness.
Approval statusPublication, asset, or review state for the named surface.Approval status is not a theorem proof or source-law adoption.
Claim-boundary rowAllowed, forbidden, and gate-required wording for a scoped claim.Boundary metadata does not execute the gate it describes.
Workflow rowTraceability for a task, job, role, or decision.Traceability does not widen the original permission envelope.