Flow Atlas, Lineage, Impact, and Navigability

1. The Atlas is derived visibility and access infrastructure

AIOS has no central file or agent that contains the meaning of a domain. That distribution preserves local ownership and open-ended development, but it creates a practical question: how can a person see what exists, how it relates, what has changed, and where authority lives without opening every file? The Flow Atlas answers that visibility problem.

It follows registration and promotion: Chapter 19 explains how work acquires standing; this chapter explains how those distributed states and relationships become navigable. It precedes epistemic maintenance: correction depends on seeing lineage, affected consumers, and unresolved contradiction without confusing a map with the ground it represents.

The Registration and Flow Atlas layer makes visible:

• what a component or resource is;
• which source is canonical;
• who owns it;
• which purpose, standard, or accepted decision it is intended to serve;
• what it reads, produces, parses, changes, or displays;
• what depends on it;
• which evidence supports its current state;
• which installed version, compatibility boundary, or authorized departure applies;
• what is missing, stale, invalid, deprecated, or superseded;
• what a proposed change will definitely affect;
• which semantic neighbors may deserve review.

The Atlas is separate, removable, and derived. Ordinary composition must continue if the registry, search index, or visual projection is absent. Its governing invariant is:

canonical files and companion metadata
  → compiled registry and indexes
    → Atlas views and navigation

delete any derived layer
  → rebuild from the same source snapshot
    → recover the same declared identities, standings, and relationships

The Atlas may expose omissions or contradictions in canonical files or accepted ground. It cannot repair them silently or become a second source of authority.

2. Why a registry is needed

As the system grows, important contracts become distributed across:

• prompts and seat definitions;
• context sources and capsule composition;
• parsers and response contracts;
• commands and operation owners;
• workflows and stages;
• ontology and recommendation relationships;
• artifacts and companion metadata;
• assignments and returns;
• interface surfaces;
• tests, reviews, and acceptance evidence.

Without a derived registry, the system can remain conceptually coherent while becoming operationally difficult to inspect.

3. Owner declarations and compilation

The source model can include:

• capabilities and operation owners;
• commands and invocation paths;
• semantic seats and prompt contracts;
• context-file regions and producers;
• model input, output, parser, landing, and consumer chains;
• workflows, stages, accepts, produces, follow-ons, and controlled relations;
• interface regions, messages, controls, adapters, and effect owners;
• feature contracts, implementation evidence, specialist reviews, acceptance, deprecation, and supersession;
• project documents, decisions, relationships, work, returns, and candidate knowledge;
• organizational knowledge packages, installed versions, compatibility declarations, local variation, supersession, revocation, rollback, and installation evidence.

The registry compiles these from exact owner files. It does not create a parallel source of canonical authority. Any extracted fact or inferred relationship retains its source snapshot, derivation method, time, and standing so that a reader can descend to the artifact that actually carries authority.

4. Registry families

Definition Registry

Accepted system and expertise definitions:

• ontology and recommendation taxonomy;
• component identities, versions, owners, and hashes;
• workflows, stages, inputs, outputs, follow-ons, and effects;
• roles, guidance, prompts, response contracts, parsers, and consumers;
• validation, installation, deprecation, and supersession evidence;
• package identity, dependency and compatibility declarations, distribution integrity evidence, permitted local-variation boundaries, installed versions, revocation state, and rollback targets.

Project Registry

Project owner records:

• documents and sections;
• Purpose and Plan revisions;
• outputs and decisions;
• relationships and dependencies;
• source sets and lineage;
• work items, assignments, returns, and integration receipts;
• candidates and acceptance standing.

Active Work Index

A small projection over proposals, plans, active work, attention-needed work, and returns. It is not a new global queue.

Recommendation State Index

Origin-scoped context signals, current optional focus, menu snapshots, recommendation evidence, person take-up, and pending or expired pivots.

Search and Facet Index

Rebuildable mapping from controlled identities and labels to typed references. It carries no acceptance authority.

Lexical indexes, vector indexes, extracted-fact tables, relational graphs, rerankers, summaries, and multi-resolution views can coexist because they answer different access questions. Their use should respond to measured vocabulary mismatch, corpus heterogeneity, multi-hop depth, latency, update rate, and concurrency—not an arbitrary file count. Indexing a candidate or untrusted source makes it discoverable; it does not make it accepted, eligible for activation, or safe to compose into a future judgment.

5. Node and edge model

The important distinction is between source-bearing nodes and projections. Definitions can guide projects; projects commission work; work changes or evidences projects; all three can be rendered in views whose edges retain type, source, standing, owner, and temporal state.

Three edge namespaces remain distinct.

Authored definition edges

has-stage, depends-on-stage, accepts, produces, follow-on, classified-as, uses-guidance, parsed-by, consumed-by, validated-by, supersedes-version.

Project semantic edges

informs, constrains, supplies, challenges, qualifies, supersedes, implements.

Provenance, authority, and work edges

derived-from, instantiates, proposed-by, approved-by, assigned-to, returned-to, integrated-through, evidenced-by.

Every edge has one primary type, exact source and target, provenance, standing, owner, and temporal state. Where time matters, the record distinguishes when the relationship was observed, when it was accepted, and the interval for which it is understood to apply.

6. Atlas views

Definition Atlas

Ontology, workflows, stages, guidance, roles, seats, prompts, and response/consumer chains.

Project Atlas

Purpose, plan, documents, decisions, outputs, dependencies, lineage, work, returns, and candidates.

Flow Atlas

Exact routes from source through context, judgment, output, operation, file effect, and user-facing result.

Impact Atlas

Exact consumers, owners, tests, contracts, and evidence affected by a proposed change.

Consistency Atlas

Evidence-backed contradictions, duplicate responsibilities, stale terminology, and candidate clusters across a bounded source set.

Authority Atlas

Proposal → grant → operation → result → review → acceptance or supersession.

7. Exact impact and semantic neighbors differ

EXACT IMPACT
known parser, consumer, file, test, or contract dependency

SEMANTIC REVIEW CANDIDATE
a conceptually related artifact that may bear but is not mechanically dependent

Collapsing the two creates either false certainty or overwhelming change reviews.

The registry can prove exact joins. A semantic review seat can identify possible conceptual consequences, which remain advisory until examined.

Neither class proves that every affected object has been found. Exact impact is exact only relative to registered mechanical and authored relationships. Semantic review candidates depend on fallible retrieval and interpretation. Missing edges, stale metadata, or an unregistered consumer can create false negatives; visual proximity can create false positives.

Example: propagating an organizational evidence standard

Suppose an organization updates its public-claims standard because its governing purpose requires every consequential claim to remain traceable to exact evidence. Version 4 adds a requirement that model-produced source summaries identify themselves as derived interpretations.

The Atlas separates three results:

1. Exact registered dependencies. Six workflows declare that they use the standard, four document templates validate against it, and two completion checks consume its versioned identity. These are provable joins relative to the registered source snapshot. They can receive an exact compatibility review and update plan.
2. Fallible semantic review candidates. Search and a bounded review judgment identify other documents, prompts, and team packages that discuss source fidelity but do not declare the standard as a dependency. They may need revision, but similarity does not authorize mutation or prove that the new rule applies.
3. Unknown impact. Offline installations, unregistered scripts, exported artifacts, missing edges, and local copies that have never reported their state remain outside the provable field. The Atlas should state this unknown impact rather than turn the absence of a relationship into evidence of no effect.

The organization can then distribute the versioned update, signed where issuer identity and integrity require it. Each local installation still evaluates compatibility, scope, authority, and permitted variation. A team may accept the update, defer it, record an authorized departure, or roll back after a defect. The central release does not automatically make every local copy consistent, and the Atlas must distinguish the version that was published from the version each known installation has actually verified.

8. Validation classes

Structural and relational validation

• duplicate or missing identity;
• missing owner;
• unsafe path;
• broken command reachability;
• workflow and stage mismatch;
• invalid ontology relation;
• broken prompt → context → parser → consumer chain;
• missing source → judgment → effect → interface join;
• stale or superseded references;
• canonical versus compiled drift.

Semantic review findings

• contradictory definitions;
• duplicated responsibility;
• unclear scope;
• obsolete rationale;
• inconsistent terminology;
• missing evidence;
• questionable promotion;
• project or artifact drift.

Structural failures and semantic findings remain separate.

The same separation applies to truth. Provenance can establish that an edge came from a particular file, model judgment, person decision, or operation. It cannot establish that the underlying claim is correct. The Atlas is a control and navigation plane for evidence and standing, not a truth oracle.

9. Contract and implementation reconciliation

Before a bounded change, the registry can verify:

• accepted feature or capability contract;
• source and baseline availability;
• explicit scope and non-goals;
• named owners and files;
• expected tests and evidence;
• absence of unresolved semantic decisions disguised as mechanical tasks.

After the change, it can compare:

• actual changed files versus authorized envelope;
• exact component revisions;
• provider, file-effect, interface, reload, adverse, and test evidence;
• unexpected routes, owners, commands, or compatibility paths;
• review evidence bound to the same contract and implementation;
• staleness caused by later artifact changes.

10. Coordinating independent review

For high-consequence changes, AIOS can require independent review across:

• intelligence review;
• product and interaction review;
• code and mechanical review.

Each receipt binds:

• feature identity;
• contract revision and hash;
• implementation source baseline and reviewed revision;
• review kind and reviewer;
• exact artifacts and hashes;
• verdict, findings, limitations, and time.

All reviews must refer to the same declared purpose, artifact versions, and implementation. Eligibility remains distinct from build success, visibility, repeated observation, and acceptance. Final acceptance stays with the person or declared program owner. Lower-risk work may use a lighter review path; adding reviewers is valuable only when they contribute different evidence, methods, or authority.

11. Incremental compilation and recovery

owner finishes bounded write
  → receipt names affected identity and revision
    → registry rereads affected owner records
      → validates and atomically replaces derived rows
        → Atlas rehydrates affected scope

A full rebuild remains the recovery and verification path. For the same source snapshot and compiler version, incremental and full results should agree.

One malformed source should create a local issue rather than corrupt unrelated rows.

This is what keeps the Atlas from becoming canonical through convenience. If a compiled database is lost, the knowledge system loses speed and visibility, not its accepted artifacts, decisions, provenance, or authority. If a rebuild produces a different projection from the same snapshot, that discrepancy is a defect to investigate rather than an opportunity to treat the latest index as governing ground.

For distributed organizational knowledge, the same rule extends across a package or fleet lifecycle:

author and accept a versioned package
  → declare identity, dependencies, compatibility, scope, and variation boundaries
    → sign or otherwise attest distribution where appropriate
      → local authority verifies, installs, defers, or declines
        → local use records version and authorized departures
          → supersede, revoke, migrate, or roll back with lineage

The registry can compile reports from known installations and expose incompatible, stale, revoked, or divergent versions. It cannot assume that an unreported installation is current or overwrite a local decision merely because a newer package exists. Local authority and local copies remain real; organizational consistency requires an explicit update, acceptance, and verification process.

12. Audit trail by design

The combined file, metadata, and registry architecture can preserve:

• who or what initiated work;
• what purpose and authority applied;
• which exact sources and versions were used;
• what context was composed;
• which model or provider produced a result;
• what output contract was parsed;
• which effect was proposed and applied;
• which artifact revision resulted;
• what independent reviews occurred;
• what limitations and residual risks remained;
• what was accepted, rejected, or superseded;
• which organizational package and version supplied governing ground;
• which compatibility decision, authorized departure, revocation, or rollback applied locally.

This is a strong auditability substrate. A receipt proves that a named event occurred against a named state; it does not prove that the source was true, the model judgment was sound, the human decision was wise, or the resulting control was effective. Legal compliance, certification, and regulated assurance additionally require domain-specific requirements, security, access control, retention, validation, monitoring, and external assessment.

13. Research and scientific reproducibility

The Atlas can help researchers inspect:

• source and prompt versions;
• context composition and omission;
• model and provider identity;
• exact artifact state before and after;
• semantic and mechanical deltas;
• evaluation fixtures;
• reviewer disagreement;
• supersession and later correction.

This makes the harness itself a research instrument rather than a black-box application.

14. Visual projection rules

Atlas visuals should:

• state their source snapshot;
• distinguish canonical declarations from candidate relations;
• show edge type and provenance;
• reveal staleness or missing joins;
• allow descent to exact source;
• avoid inferring importance from visual centrality alone;
• remain disposable and rebuildable.

The renderer owns layout, shape, and color. The canonical owner records determine node identity, relation, standing, and provenance.

15. One bounded proof

A representative vertical proof can register and display:

1. capability and command ownership;
2. a small accepted ontology and workflow set;
3. one complete reasoning chain from source through context, output, parser, effect, and interface;
4. one accepted feature contract;
5. pre-change reconciliation;
6. implementation evidence;
7. three aligned reviews;
8. pass, fail, missing, mismatch, and stale behavior;
9. equality of full and incremental compilation;
10. ordinary system operation with the registry removed.

This tests the architecture without requiring the complete future Atlas.

16. Failure modes

Registry as central brain

The compiled layer becomes the owner of semantic authority or runtime execution.

Second metadata system

Registration creates competing canonical records instead of compiling owner files.

Graph overclaim

Visual proximity or semantic similarity is presented as causal dependency.

Acceptance collapse

Build success, review, acceptance, and production are treated as one state.

Stale evidence

Reviews remain valid after the artifacts they examined change.

Compliance overclaim

An audit log is represented as regulatory certification.

Atlas dependency

Ordinary work fails when the registry is absent.

17. Research evaluation

Evaluate:

• source-to-projection fidelity;
• exact versus semantic-impact precision;
• full and incremental compilation equality;
• local failure isolation;
• recovery after index deletion;
• reviewer and evidence alignment;
• user ability to descend from a map to source;
• change-impact prediction accuracy;
• audit reconstruction completeness;
• purpose-to-standard-to-effect traceability;
• package propagation coverage across exact dependencies, semantic review candidates, and unknown impact;
• installed-version, authorized-departure, revocation, and rollback reconstruction;
• overhead imposed on ordinary composition.

18. Research connection

Current retrieval research reinforces the boundary between a graph and the source world it projects. BRINK found substantial degradation when answer-supporting knowledge-graph edges were withheld, exposing limited recovery from incomplete relational structure. A separate 2025 evaluation of long-document retrieval found that preserving a document’s original structure could match or outperform more elaborate retrieval hierarchies under matched context budgets. These results do not validate the Flow Atlas, but they support its design as a source-anchored, rebuildable routing and inspection layer rather than a replacement for canonical files or proof of evidentiary completeness.

The relational-memory research brief provides the deeper comparison among lexical, vector, relational, graph, and direct-source access. The architectural conclusion here is narrower: the Atlas helps a distributed knowledge system see itself while preserving exact descent and the possibility that its map is incomplete.

NIST’s 2026 report on post-deployment AI monitoring identifies fragmented logging across distributed infrastructure as a barrier to detecting drift and unforeseen behavior. Linked source, context, operation, and post-state records could reduce that fragmentation. They remain an assurance substrate, not certification.

19. What this page contributes to the whole

The Atlas gives visible form to the system’s “no center” architecture. It lets a person move from a domain-level map to an exact source, inspect how a judgment became an effect, distinguish accepted relationships from candidates, and see what a proposed change may touch. Because every projection remains disposable and rebuildable, navigability can increase without transferring canonical authority away from local files. Chapter 21 uses that visibility to show how a domain corrects itself across time.