Documents / Governance / Retrieval Layers

Retrieval Layers

Retrieval layers help readers find source candidates. They do not decide claim status, prove physics, or replace source inspection.

Animated retrieval layer routing map Retrieval layers route through source inspection before any public claim can change.
Retrieval layers can surface candidate material, but source inspection decides what the website may claim.

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. Local retrieval layers are the project's search and navigation aids: they help a reader or research agent locate candidate material without becoming the owner of the claims they find.

Memory lookup can recall candidate paths, prior packets, and recorded decisions; semantic extracts can surface related passages; generated wiki pages and Obsidian mirrors can expose objects and relationships; SQLite or other local indexes can make repeated searches faster; and ignored local caches can hold previews, screenshots, logs, render checks, or other temporary QA material.

Each layer is useful for discovery, but each can be stale, partial, generated, or local-only. A source-first reading sequence therefore begins with a precise question, uses retrieval to find a candidate, identifies the tracked file, registry row, task, completion, handoff, or current control record that owns the relevant claim or state, inspects that owner in context, and reports any remaining uncertainty before reuse.

Registered TeX carries scoped physics and derivational claims within its stated status; registered Markdown and tracked control records carry their own documentation, governance, and workflow authority; and registries record provenance, relationships, paths, hashes, and status without replacing the material they describe. A memory preflight or local refresh may rebuild mirrors, semantic extracts, or an index so that search results match tracked inputs more closely, but that maintenance repairs navigation support rather than creating committed evidence, source authority, or scientific proof.

When retrieval and source disagree, the tracked source and current governed record win: an older memory must be rechecked, a partial extract must be expanded to its surrounding source, a generated mirror must route the reader back to its owner, and a local cache must remain local rather than being cited as public evidence. This page helps readers distinguish what each retrieval layer can find, how to move from a hit to its owner, which freshness or context failures to watch for, and how to state the limit of the result.

As a Documents governance page, Local Retrieval Layers presents these boundaries through contextual copy, tables, and provenance rather than a separate Source authority component section. No memory hit, semantic extract, wiki or Obsidian mirror, SQLite index, local cache, registry row, validator PASS, screenshot, 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

Keep retrieval layers below canonical source inspection.

The source-first memory diagram shows memory, semantic extracts, mirrors, caches, registries, handoffs, and the final source-inspection boundary.

The diagram illustrates source-first memory layers from canonical sources through registries, handoffs, generated memory layers, retrieval, and source inspection.
Diagram showing canonical sources above registries, handoffs, generated memory layers, retrieval, and source-first verification.

The diagram illustrates source-first memory layers from canonical sources through registries, handoffs, generated memory layers, retrieval, and source inspection.

Retrieval layer classes

Navigation layers stay below source authority.

The route keeps local, generated, and indexed material useful without giving it source status.

LayerExamplesUseLimit
Memory lookupLocal memory summaries, prior packet notes, and retrieved workflow hints.Find candidate files, commands, and prior decisions quickly.Memory lookup is a navigation aid, not claim authority.
Semantic extractsVector or text extracts used to locate related source objects.Discover relevant source files or registries for inspection.Extracts can omit context and cannot replace source reading.
Obsidian or wiki mirrorsGenerated notes, object pages, and relationship mirrors.Browse relationships and find source candidates.Generated notes are retrieval layers unless promoted by a tracked source.
SQLite or local indexesLocal databases, source indexes, and cache tables.Speed search and repeatable lookup across large source sets.Index rows are not proof, source authority, or public publication state.
.local and QA cachesIgnored previews, screenshots, temporary analysis, and local artifacts.Support local inspection, debugging, or browser QA..local data is not committed evidence or source authority.

Source-first workflow

A retrieval hit becomes useful only after owner inspection.

The workflow separates discovery, source ownership, inspection, and uncertainty reporting.

StepActionBoundary
Ask the retrieval questionUse memory, semantic search, wiki, or cache lookup to find candidate material.The retrieval layer can suggest where to inspect; it cannot decide the claim.
Locate the ownerMap the hit to a source file, registry row, handoff, completion, PRD, or manifest.The owner, not the retrieval hit, controls claim status.
Inspect the sourceRead the current tracked source or governed record before changing public copy.If source and retrieval disagree, source wins.
Report the uncertaintyName stale, partial, or local-only retrieval evidence before reuse.Uncertainty remains visible instead of being hidden behind a polished route.

Common failure modes

The useful warning is specific, not vague.

Retrieval layers fail differently. Naming the failure mode makes the safer next step clear.

RiskSafe responseBlocked use
Stale memoryRefresh against tracked files or state before relying on the hit.Do not present an older memory note as current source truth.
Partial extractOpen the full source and surrounding context.Do not infer missing assumptions from the extract alone.
Local cacheTreat cache paths as private QA or navigation support.Do not cite `.local` or ignored cache state as public evidence.
Generated mirrorUse the mirror to locate the canonical source or registry row.Do not edit the mirror to change canonical claims.