Flow Atlas, Lineage, Impact, and Navigability

1. The Atlas makes distributed intelligence visible

AIOS stores meaning across artifacts, companion memory, definitions, workflows, assignments, decisions, receipts, and source relationships. At small scale, people can inspect these forms directly. At larger scale, understanding the whole requires a derived view of identity, ownership, flow, evidence, standing, and change impact.

The full Flow Atlas is planned as a later product build after the core application is live. It sits on top of the metadata and registration structure already present in the system, turning those relationships into maps that make workflow definitions, enforcement, gaps, lineage, and change visible across the whole environment.

The Registration and Flow Atlas compiles that view from exact owner files. It reveals what a resource is, where its canonical ground lives, who owns it, what it reads and produces, what depends on it, which evidence supports it, what has become stale or superseded, and where a proposed change has exact or possible consequences.

The Atlas is disposable infrastructure. Its authority comes from the source relationships it projects, and ordinary composition continues when the projection is absent.

Chapter 09 supplies the governing test.

The canonicality test is simple: if a projection disappears, can exact owner files and accepted records recreate it? A projection that cannot be rebuilt has become an undeclared source of truth.

This is the test against projection authority: a useful view may guide inspection, but it cannot acquire standing above the ground from which it was built.

2. Operational coherence must remain inspectable

Important AIOS contracts are distributed among semantic seats, prompts, context regions, response contracts, parsers, commands, capability owners, workflows, ontology relations, artifacts, metadata, delegated work, interface surfaces, tests, reviews, and acceptance records.

This distribution protects local ownership and prevents one central representation from becoming the intelligence. It also creates an inspection problem: a coherent architecture can become difficult to trace in a running product.

The registry addresses that problem by compiling exact relationships without relocating their ownership.

3. Registration begins at canonical sources

The source model begins with four families of canonical owner records:

• capability definitions, commands, and invocation paths;
• cognitive and operational contracts connecting ground, judgment, landing, and effect;
• workflows, stages, products, relations, interfaces, review, acceptance, and supersession;
• project documents, decisions, assignments, returns, and candidate knowledge.

Each relationship comes from an owner file with identity and standing. Compilation can fail, rebuild, or disappear without creating a second source of truth.

4. Registry families answer different questions

The Definition Registry resolves system and expertise definitions: terms, components, roles, workflows, stages, prompts, parsers, consumers, validation, installation, versioning, and supersession.

The Project Registry resolves purpose, plan, artifacts, sections, decisions, dependencies, sources, work, returns, candidates, and integration receipts for each project.

The Active Work Index projects proposals, plans, admitted operations, work needing attention, and returned products. It offers a navigable view across origins while leaving each operation under its local owner.

The Recommendation State Index preserves origin-scoped signals, optional focus, menu snapshots, recommendation evidence, person take-up, and pending or expired pivots.

The Search and Facet Index maps controlled identities and labels to typed references. It is rebuildable navigation, never acceptance authority.

5. Nodes and edges preserve typed relationships

Authored definition edges express relationships such as stages, dependencies, inputs, products, follow-ons, classifications, guidance use, parsing, consumption, validation, and version supersession.

Project semantic edges express informing, constraining, supplying, challenging, qualifying, superseding, and implementing.

Provenance, authority, and work edges express derivation, instantiation, proposal, approval, assignment, return, integration, and evidence.

Every edge has one primary type, an exact source and target, provenance, standing, and ownership. Typed relationships keep conceptual proximity from masquerading as dependency.

6. Atlas views expose the system at useful altitudes

The Definition Atlas shows ontology, workflows, stages, guidance, roles, seats, prompts, and response-to-consumer chains.

The Project Atlas shows purpose, plan, artifacts, decisions, outputs, dependencies, lineage, work, returns, and candidate knowledge.

The Flow Atlas traces a complete movement from source and context through judgment, output, operation, file effect, and person-facing result.

The Impact Atlas identifies exact consumers, owners, contracts, tests, and evidence touched by a proposed change.

The Consistency Atlas presents evidence-backed contradictions, duplicate responsibilities, stale terms, and candidate clusters inside a defined source set.

The Authority Atlas follows proposal, grant, operation, result, review, acceptance, and supersession.

These views are different projections of shared ground. Each can descend to the file and relationship from which its claim was compiled.

7. Exact impact and semantic review are separate products

EXACT IMPACT
a registered parser, consumer, file, test, owner, or contract dependency

SEMANTIC REVIEW CANDIDATE
a conceptually related artifact that may bear on the change and requires judgment

The registry proves explicit joins. A semantic review can propose neighboring concepts, artifacts, or decisions whose relationship deserves inspection.

Separating the two protects change analysis from false precision and from undifferentiated review overload. Exact impact carries mechanical evidence; semantic proximity carries an invitation to examine meaning.

8. Validation preserves the semantic-mechanical boundary

Structural and relational validation finds duplicate or absent identities, missing owners, unsafe paths, unreachable commands, workflow-stage mismatch, invalid authored relations, broken context-parser-consumer routes, missing source-to-interface joins, stale references, and drift between canonical and compiled forms.

Semantic review finds contradictory definitions, duplicated responsibilities, unclear scope, obsolete rationale, inconsistent terminology, missing evidence, questionable promotion, and project or artifact drift.

The first class can often produce exact pass or fail results. The second produces evidence-bearing findings for judgment. Their presentation and authority remain distinct.

9. Change reconciliation binds contract, implementation, and evidence

Before a bounded change, the Atlas can resolve the accepted contract, canonical baseline, authorized envelope, affected owners, expected proof, and semantic decisions still requiring human resolution.

After the change, verification compares the intended and actual delta, affected objects, visible behavior, durable settlement, reconstruction, and independent review. Chapter 22 Section 17 follows that complete movement from source and context through effect, interface, and durable settlement.

Evidence remains bound to the artifact revision it examined. Later changes can make a prior review stale even when the review itself was sound.

10. Acceptance coordinates three independent views

A complete target model uses separate intelligence, product-and-interaction, and code-and-mechanical reviews. The review kinds remain independent and align only when they examine the same accepted object and revision.

Passing one review never implies the others. Passing tests does not imply product acceptance. A strong interaction does not prove mechanical integrity. Review eligibility, technical success, visibility, repeated observation, and final acceptance remain separate states.

The person or declared program owner retains final acceptance authority.

11. Incremental compilation remains answerable to full rebuild

an owner completes a bounded write
  → its receipt identifies the affected resource and revision
    → the registry rereads the relevant owner records
      → validates and atomically replaces derived relationships
        → the Atlas rebuilds only the affected view

A full rebuild remains the recovery path and reference check. For the same source snapshot, incremental and complete compilation produce the same semantic result.

Malformed input creates a local issue attached to its owner. It does not contaminate unrelated registry rows or require the rest of the system to stop.

12. Auditability emerges from joined evidence

The combined architecture can reconstruct who initiated work, which purpose and authority applied, which sources and versions entered context, which model produced the result, which response contract was validated, what effect was proposed and authorized, which artifact revision resulted, what reviews occurred, which limitations remained, and what was accepted or superseded.

This creates a strong auditability substrate and a research record of the harness itself. It supports named legal, regulatory, contractual, or assurance work by preserving evidence those regimes can inspect. The applicable regime still defines its own controls, access requirements, retention, validation, and external assessment.

13. The Atlas makes the reasoning system researchable

Researchers can inspect prompt and source versions, context selection and omission, model identity, artifact state before and after, semantic and mechanical deltas, fixtures, reviewer disagreement, acceptance, supersession, and later correction.

This permits experiments on the composed system rather than only the model response. Context composition, authority, durability, and reintegration become observable variables.

14. Visuals remain source-bound projections

Every Atlas view states its source snapshot, distinguishes accepted facts from candidate relations, shows edge type and provenance, reveals stale or missing joins, and permits descent to exact source. Visual centrality never becomes evidence of conceptual or operational importance.

The renderer owns layout, color, shape, and interaction. Semantic records own identity, relation, standing, and provenance. A view can be redesigned or deleted without changing what the system knows.

This division prevents projection authority: visual prominence, proximity, or persistence cannot elevate a view above its source records.

15. The first implementation can remain focused

An initial Flow Atlas implementation can register a focused set of capabilities, commands, workflows, owners, relationships, and effects. It can trace one complete path from source through context and model output to file and interface, reconcile a proposed change with its affected objects, and rebuild the same view from the underlying owner records.

That focused implementation establishes the mapping and registration pattern from which broader Atlas coverage can develop after the core application is live.

Boundary: the Atlas projects intelligence; it does not own it

Canonical meaning remains in owner files and accepted records. The Atlas compiles relationships, detects exact defects, and makes semantic review candidates visible. It neither executes ordinary work nor turns graphical proximity into causal truth.

16. Failure conditions and evaluation

The principal failure conditions are distinct:

• Registry as central brain: a derived index becomes the place where the system's meaning is authored or governed.
• Competing metadata truth: registration creates a second authority that can disagree with canonical owner records.
• Projection authority: a graph's visual arrangement is treated as evidence of causality, importance, or standing.
• Proof-state collapse: technical success, review, visibility, and acceptance are treated as one event.
• Stale evidence authority: a sound review continues to govern after the examined revision changes.
• Audit log as external assurance: internal records are presented as though they satisfy a named regime by themselves.
• Derived-layer dependency: ordinary work stops when a rebuildable registry or view is absent.

Evaluation tests source-to-projection fidelity, exact-impact precision, semantic-review usefulness, incremental and full equality, local failure isolation, recovery after deletion, alignment of reviews with artifacts, descent from view to source, impact prediction, audit reconstruction, and overhead imposed on ordinary composition.

The Flow Atlas makes a distributed intelligence system navigable without centralizing its intelligence. It gives people a way to see how meaning moves, where authority enters, and what a change will actually touch.