Workflow
Workflow
Read where preflight sits before Director routing and bounded work.
Open routeAI Research System / Memory Preflight
Memory Preflight
Memory preflight is navigation support, not source authority. It finds likely evidence; canonical sources remain authority.
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 uses memory preflight before bounded work to find relevant source objects, registry rows, prior tasks, handoffs, and other evidence without confusing fast retrieval with authority. A preflight first checks whether the retrieval layers are fresh enough for navigation, then runs a targeted lookup, opens the tracked source file and its registry row, and records a receipt containing the query, returned canonical object IDs, inspected paths, hashes, and authority note.
Registered TeX carries physics and derivational claims; registered Markdown and tracked control records carry their scoped project authority; registries carry provenance, relationships, status, and memory metadata. Generated wiki notes, semantic extracts, Obsidian mirrors, SQLite indexes, and `.local` caches can point toward likely evidence, but they remain downstream retrieval support.
If a retrieval hit and a tracked source disagree, the tracked source wins; a stale retrieval warning calls for maintenance or direct source inspection, not rejection of the canonical source. This Memory Preflight page explains how that source-first sequence helps one AgentJob begin from inspectable evidence. No memory hit, freshness report, registry row, generated derivative, receipt, AI output, or website page independently proves a physics claim, completes the open first-principles derivation, promotes the proposed ontology, expands authority, or replaces direct canonical inspection.
Static diagram
Keep retrieval below source inspection.
The source-first layers diagram shows memory, generated retrieval layers, registries, handoffs, and source inspection without allowing retrieval to become authority.
Preflight chain
Lookup is useful only when followed by inspection.
The safe model is small and repeatable: check retrieval state, ask a targeted question, inspect the canonical source, and leave an auditable receipt.
| Stage | Purpose | Boundary |
|---|---|---|
| Status | Check retrieval freshness, known drift, and whether lookup support is usable for navigation. | A freshness report is maintenance context, not claim authority. |
| Targeted lookup | Find likely source paths, registry rows, prior tasks, handoffs, or object IDs. | A returned hit is only a candidate until inspected directly. |
| Canonical inspection | Open tracked source files, control records, and relevant registry rows before relying on the hit. | Canonical sources remain authority when retrieval and source disagree. |
| Receipt | Record query commands, returned IDs, inspected paths, registry rows, hashes, and boundary notes. | Receipts make the transaction auditable; they do not prove the underlying claim. |
Authority layers
Source, registry, derivative, and retrieval are different layers.
The website can explain all four layers, but it must not flatten them into one evidence class.
| Layer | Examples | Safe use |
|---|---|---|
| Canonical source | Registered TeX, Markdown, schemas, control records, source specs, and current tracked task state. | Claim-affecting language, routing, and source selection after direct inspection. |
| Registry metadata | Source, derivative, AgentJob, role, claim-boundary, wiki, semantic, and publication registries. | Provenance, relationship, status, and source-location evidence. |
| Generated derivative | PDFs, HTML explainers, wiki notes, GitHub-facing summaries, and rendered pages. | Reader support and discovery, with source verification when claims matter. |
| Local retrieval | Semantic extracts, Obsidian mirrors, SQLite indexes, and `.local/` caches. | Navigation only. Local retrieval must not be cited as source authority. |
Blocked overreads
Retrieval never outranks the source it points to.
The page is designed to prevent retrieval convenience from becoming public authority by habit.
| Unsafe reading | Correction |
|---|---|
| A memory hit names a path, therefore it can be cited. | Retrieval hits must be verified against the tracked source or registry row before use. |
| A generated wiki note says the claim, therefore the claim is promoted. | Generated derivatives help locate evidence; they cannot promote scientific or workflow claims. |
| A receipt records a lookup, therefore the theorem is checked. | The receipt records what was inspected. It is operational evidence, not proof. |
| A stale retrieval warning invalidates the canonical source. | Stale retrieval is a maintenance signal unless a source validator reports a source problem. |
Source basis
The source basis is inspected, not inferred from search.
This route uses PRD and dossier evidence for website structure while preserving the upstream source hierarchy for claim-bearing content.
| Source area | Used here for | Authority boundary |
|---|---|---|
| Memory and retrieval requirements | Navigation-versus-authority language, generated derivative classes, and source-inspection rule. | Requirements planning does not become source authority. |
| Research-control workflow | Memory preflight receipt shape, one-packet routing, and canonical inspection expectations. | Workflow receipts do not prove science or promote claims. |
| Memory registries dossier | Route-specific safe and unsafe summaries for retrieval layers and receipts. | Dossiers guide website implementation and remain below tracked source files. |