B3 - CERBERUS VISOR Structural Map and Reconstruction Architecture Stack Registry • Table Registry • Structural Resolution • Native Reconstruction Version 1.0 | PASS 8 VERIFIED RELEASE Governed structural terrain for a self-describing, navigable, inspectable, and reconstructable Base. Executive Orientation VISOR is the governed structural map and reconstruction architecture of a CERBERUS Base. It makes the system's structural terrain explicit enough that a human, AI, or software process can determine what structural surfaces exist, where they belong, how they are connected, what can be traversed from the current context, and how deeply the implementation must be resolved for the task at hand. VISOR does this without absorbing the semantic authority of the systems it maps. The current architecture is centered on two primary registries and one deeper descriptive layer. The Stack Registry describes bounded structural groupings and their organization. The Table Registry registers the Tables occupying those groupings. When a task must resolve below the Table boundary, the Structural Pattern Dictionary (SPD) describes the Field-level implementation structure required for inspection, repair, validation, or reconstruction. A lightweight Field Inventory supports observed schema work without replacing SPD. VISOR DESCRIBES STRUCTURE. THE STRUCTURES IT MAPS RETAIN THEIR OWN AUTHORITY. This distinction is especially important for Native Personal Core reconstruction. The migration target is not an Airtable-shaped copy. The target is a structurally equivalent CERBERUS architecture whose Root Stacks, Stacks, Tables, Fields, relationships, cardinalities, derivations, classifications, and ownership boundaries can be independently observed and verified in new implementation material. VISOR provides the large-scale structural map; SPD provides deeper schema resolution; PORT handles material translation; PATCH and BUILD address defects or missing capability without becoming VISOR itself. Definitive reconstruction sentence VISOR is CERBERUS's governed structural map: it registers how Tables are organized into bounded Stacks and Root-Stack territory, preserves explicit structural relationships and routes, and provides sufficient structural resolution for humans, AI, and software to locate, inspect, traverse, validate, and reconstruct the Base without confusing structural position with semantic identity or authority. Document map # Section Purpose 1 VISOR and the Structural Map Core purpose, scope, and structural resolution. 2 The Current VISOR Stack Stack Registry, Table Registry, SPD, and Field Inventory. 3 Registries and Deeper Structural Resolution What each layer answers and why the distinctions matter. 4 BRAIN and Root-Stack Territory Current B1-B12 structural orientation. 5 Structural Relationships and Traversal Containment, routing, dependencies, bridges, and task-bounded paths. 6 Topology and Navigation Projection Why structural truth is not a breadcrumb, tree, or rendered map. 7 Ownership and System Handoffs VISOR boundaries with owning systems, QUIVER, DARTBOARD, Shell, and authority. 8 AI Orientation and Recursive Self-Mapping How intelligence can orient deterministically, including around VISOR itself. 9 Native Reconstruction Architecture How VISOR and SPD rebuild the structural skeleton before record migration. 10 Development Boundaries VISOR, SPD, PORT, PATCH, BUILD, and explicit structural gaps. 11 Formal Invariant Registry Compact laws that must survive migration and redesign. 12 Native Verification Checklist Tests for structural parity and reconstruction readiness. 13 Closing Orientation Compressed architecture and reconstruction test. 1. VISOR and the Structural Map A Base should be able to state its own structure explicitly. A user or AI should not have to infer architecture from screen layout, folder naming, table labels, or developer memory. If a Table exists, VISOR should be able to register it structurally. If that Table belongs to a Stack, that membership should be explicit. If the Stack sits beneath a Root Stack, that path should be resolvable. If the Table depends on, routes to, or bridges another structural surface, that relationship should be represented as a relationship rather than guessed from proximity. VISOR therefore acts as structural terrain. It can answer questions such as: Where is this Table? Which Stack contains it? What Root-Stack territory does that Stack resolve toward? What related structures are explicitly reachable? What level of structural detail is required to answer the present question? Which owning system should be consulted for the semantics once the structural destination is known? 1.1 Four durable responsibilities Inventory - register the structural objects that exist. Topology - preserve explicit organization and relationships among those objects. Routing - expose valid structural paths through the registered topology. Reconstruction - preserve enough structure that the architecture can be recreated in another implementation material. Navigation and interface presentation may use all four responsibilities, but rendered navigation is not itself a fifth source of structural truth. A tree, breadcrumb, relationship explorer, or AI context packet is a projection over VISOR-visible structure. 1.2 Structural resolution VISOR operates across structural resolutions. At broad resolution, BRAIN provides the overall system territory and the twelve Root Stacks provide the major structural regions. Beneath that, Stacks organize bounded groupings, Tables define registered structural surfaces, and SPD can resolve the Field-level implementation structure of a selected Table. BRAIN -> ROOT STACK -> STACK -> TABLE -> FIELD / SPD This is a resolution ladder, not an execution pipeline. Moving downward does not mean that one layer executes the next. It means the observer is asking for a finer structural description. A simple orientation question may stop at Table or Stack level. A migration compiler may need to descend to Fields, types, links, cardinality, and derivation behavior. TABLE != STACK != ROOT STACK != BRAIN | STRUCTURAL RESOLUTION != SEMANTIC AUTHORITY Figure 1. VISOR Structural Resolution. VISOR can resolve from BRAIN territory toward progressively finer structural detail while preserving the distinction between structural scale, semantic ownership, and runtime execution. 2. The Current VISOR Stack The current VISOR Stack contains four visible structural surfaces with different responsibilities: Stack Registry, Table Registry, SPD Writer, and Field Inventory. Their coexistence is important because they answer different questions at different levels of resolution. The Stack Registry and Table Registry form the primary orientation map. SPD provides deeper implementation description. Field Inventory supports lightweight observation and cleanup. 2.1 Stack Registry The Stack Registry describes bounded structural groupings. It carries Stack identity, purpose, ordering, Table membership, parent and child Stack relationships, lifecycle state, and the connection toward BRAIN-level orientation. The stable contract is not a particular Airtable field layout; it is that a Stack can be identified and placed in broader structural context. 2.2 Table Registry The Table Registry describes registered structural surfaces. It records the Table identity used by VISOR, the Table's name and purpose, Stack membership, local order, implementation location or platform context where useful, lifecycle state, and relationships to supporting structural resources. A registry record does not absorb the records or semantic authority contained in the Table it describes. 2.3 SPD Writer SPD resolves below the Table boundary when deeper structural inspection is required. In the current implementation, the SPD Writer can describe Field identity and order, Field type, Table link targets, classifications, list or code metadata, descriptive purpose, status, and generated Field/Table/Stack structural descriptions. The exact operational specification for SPD belongs to its own architecture; within VISOR, the important point is that the structural map can see deeply enough to reconstruct implementation structure rather than stopping at a list of Table names. 2.4 Field Inventory Field Inventory is a lightweight observed-schema surface. It is useful during cleanup, inspection, and SPD work because it can expose what implementation Fields are presently visible without requiring a complete semantic description. It does not replace SPD and should not be treated as the canonical explanation of Field meaning. REGISTRIES ORIENT • SPD RESOLVES • INVENTORY OBSERVES Figure 2. The Current VISOR Stack. The current B3 implementation separates Stack organization, Table registration, deeper SPD description, and lightweight Field observation while preserving their distinct structural roles. 3. Registries and Deeper Structural Resolution The easiest way to understand the current architecture is to ask three different structural questions. A Stack Registry record answers where a bounded grouping belongs and how it is organized. A Table Registry record answers which registered surface is being addressed and where it sits within that grouping. SPD answers how that surface is actually constructed when the task requires Field-level detail. Layer Primary question Typical structural information Stack Registry What bounded structural grouping? Stack identity, purpose, order, Tables, parent/child Stacks, Root orientation. Table Registry Which registered structural surface? Table identity, purpose, Stack membership, order, status, implementation location, structural links. SPD How is that surface constructed? Fields, types, links, cardinality, derivation, classification, lists/code, descriptions. Field Inventory What implementation Fields are currently observed? Lightweight inventory for inspection, cleanup, and SPD development. 3.1 Registry record is not registered object A Table Registry record can state that a Reader Binding Table belongs to BIGFOOT, that it has a particular structural purpose, and that it relates to other Tables. That does not turn the Registry record into the Reader Binding Table. Likewise, a Stack record is not the Tables it groups. Registry records provide structural context around independently addressable objects. THE MAP MAY DESCRIBE THE BUILDING WITHOUT BECOMING THE BUILDING. 3.2 Resolution economy VISOR should resolve only as deeply as the structural question requires. If the question is simply where a Table belongs, Table and Stack information may be enough. If the task is to reconstruct a native schema, validate a link, or determine whether a Field is derived, SPD-level resolution becomes necessary. Deeper resolution is additional structural detail, not greater truth or greater authority. 3.3 Structure survives implementation change An Airtable linked-record field, a SQLite foreign key, and a junction table can all be different material implementations of a relationship. VISOR's long-term value comes from preserving what structural relationship exists, not from treating one platform's implementation primitive as the architecture itself. The current platform is evidence. The structural contract is what must survive. Figure 3. Three Structural Questions. Stack Registry, Table Registry, and SPD answer grouping, surface, and implementation questions at different structural resolutions; Field Inventory remains an observed support surface rather than a substitute for SPD. 4. BRAIN and Root-Stack Territory BRAIN provides the top-level system territory through which the major Root Stacks are oriented. A Root Stack is not merely the largest ordinary Stack and BRAIN is not a thirteenth Root Stack. Root Stacks are the principal BRAIN-level structural regions; subordinate Stacks and Tables can then be organized beneath or around them according to their own bounded topology. 4.1 Current B1-B12 map Position Root Stack B1 CERBERUS B2 QUIVER B3 VISOR B4 BIGFOOT B5 BOSS B6 SPINE B7 BOOTSTRAP B8 MIRROR B9 DARTBOARD B10 SOLAR B11 PIECE B12 EDIFICE The numeric position supplies structural orientation. It does not prescribe runtime execution order, relative importance, or semantic authority. VISOR is highlighted when VISOR is the active structural lens, but B3 does not outrank the other Root Stacks. 4.2 Root-Stack handoff to BRAIN A structural route can ascend from Table to Stack toward a Root-Stack boundary. At that boundary, BRAIN supplies Base-level orientation among the major regions. This is a handoff in scale, not an identity collapse: the Table remains a Table, the Stack remains a Stack, the Root Stack remains its Root Stack, and BRAIN remains the larger orientation structure. ROOT-STACK POSITION PROVIDES STRUCTURAL ORIENTATION - NOT EXECUTION ORDER Figure 4. BRAIN Root-Stack Territory. The current twelve Root Stacks occupy distinct BRAIN-level structural regions. VISOR can map across them without turning numeric order into execution order or taking ownership of their functions. 5. Structural Relationships and Traversal VISOR becomes useful when structure is explicit enough to traverse. A Base is not merely a collection of registered Tables. Relationships state how those Tables and Stacks are organized, what depends on what, which structures are reachable, and where a route may cross from one bounded region into another. The relationship type matters more than the visual fact that two boxes happen to be connected. 5.1 Relation classes Relation class Structural meaning Does not automatically imply Containment / membership One structure belongs inside another bounded structural context. Shared identity, semantic merger, or mutation authority. Parent / child Recursive structural ancestry between bounded structures. Execution order. Dependency One structure requires another structure or capability. Containment or ownership. Route A traversal path is registered under the relevant context. Current traversal, permission, or semantic equivalence. Bridge / cross-Stack relation Independent structural territories are explicitly connected. One side absorbing the other. Order A declared sequence matters within a bounded structural context. Global precedence across the Base. Earlier VISOR work used relation names such as CONTAINS, PART-OF, DEPENDS-ON, PRECEDES, ROUTES-TO, COMPARES-WITH, BRIDGES, REQUIRES, and EXCLUDES. The durable requirement is not that this exact vocabulary can never expand; it is that the relation itself is explicit enough that later humans, AI, and software do not have to infer semantics from screen geometry. 5.2 Orientation and routing Orientation and routing answer different questions over the same topology. Orientation asks where the current structural context is: current object, current level, parent, containing Stack, Root Stack, and surrounding structure. Routing asks where the context may go next: parent, child, sibling, dependency, bridge, related Table, or another registered destination. CURRENT STRUCTURAL CONTEXT (conceptual) current object structural level containing stack parent / children / siblings root stack registered routes dependencies / bridges permission-relevant structural slice 5.3 Topology versus task-bounded traversal The same persistent structural graph can support different routes for different tasks. A human may browse from BRAIN through BIGFOOT into Reader structures. An AI that already holds an exact registered Table identity may route directly to that target. A migration process may systematically walk Root Stack -> Stack -> Table -> SPD. These are different traversals over one structural graph. TOPOLOGY PERSISTS • TRAVERSAL IS TASK-BOUNDED • ROUTE != AUTHORITY Figure 5. One Structural Graph, Several Traversal Paths. Human orientation, exact AI routing, and migration traversal can use different valid paths through one persistent topology. The route overlay changes with the task; the structural graph does not. 6. Topology and Navigation Projection A structural relationship is not interface geometry. The fact that a Table belongs to a Stack or that one Table routes to another does not prescribe whether a user must see a tree, a breadcrumb, a graph, a card hierarchy, or no visual representation at all. Geometry and presentation belong to the projection. The registered relationship remains part of the structural source. 6.1 One topology, many views Humans and machines can consume the same structural truth through different forms. A human-facing projection may emphasize hierarchy or current location. A relationship explorer may emphasize lateral connections. A machine-facing context packet may expose stable IDs, parent references, relation types, Root-Stack identity, and bounded routes. Different projections do not create different Bases. Tree View - useful for browsing nested containment. Breadcrumb - useful for compact current-path orientation. Relationship Explorer - useful for lateral and cross-Stack relations. AI Structural Context - useful for direct, machine-readable orientation and routing. 6.2 Permission-pruned structural views Structural information can itself disclose protected information through labels, counts, breadcrumbs, route hints, empty placeholders, or visible relationship endpoints. The authorized structural slice should therefore be determined before a projection is manifested. Hiding a forbidden node after constructing the complete view can still leak the existence or shape of restricted structure. TOPOLOGY != NAVIGATION PROJECTION | STRUCTURAL KNOWLEDGE != STRUCTURAL WIDGET Figure 6. Structural Truth and Navigation Projection. A tree, breadcrumb, relationship explorer, or AI context packet can be derived from one persistent VISOR topology. The projection is disposable; the registered structure remains. 7. Ownership and System Handoffs VISOR is intentionally broad in visibility but narrow in authority. It may know that a Table belongs to BIGFOOT, that a SOLAR Table is structurally reachable, that a QUIVER binding points toward a registered Table, or that DARTBOARD may need a structural route for the current task. None of those observations transfers semantic ownership to VISOR. 7.1 Ownership matrix Architecture Owns Does not own VISOR Structural registration, orientation, topology, routes, structural relationships, reconstruction context. Domain semantics merely because they are mapped; active manifestation; mutation authority. BRAIN / Root owners Functional territory and the system capability represented by each Root Stack. Every structural relation visible through VISOR. BIGFOOT / Readers Exact semantic structures, encoded state, and bounded Reader interpretation. VISOR structural geography or runtime interface manifestation. BOSS Governed symbolic language and symbolic use. Structural location or Table/Stack topology. SOLAR Lexical addressability and registered first-hop routes. VISOR topology or target semantic meaning. QUIVER Registered representation possibility and construction bindings. Canonical structural geography or active runtime manifestation. DARTBOARD Exact active task-bounded manifestation. Source structural truth or reusable semantic definitions. CERBERUS Shell Stable application territory. VISOR topology, semantic ownership, or representation scope. Action / Authority Permission to perform governed mutations. Structural meaning simply because a target is visible. 7.2 VISOR and QUIVER The mature boundary is simple: VISOR supplies structural terrain; QUIVER supplies governed representation capability over semantic structures located in that terrain. A breadcrumb or Stack explorer can be informed by VISOR because the structural route is known. The visible control or Panel that expresses that route does not have to be owned by VISOR. This removes the older ambiguity in which VISOR was described as a structural interface builder. 7.3 VISOR and DARTBOARD DARTBOARD may consume VISOR context when resolving a task-bounded manifestation: where the target is, what contains it, which related structures are valid candidates, and which structural paths remain after permission pruning. DARTBOARD still owns the active manifestation, not VISOR. VISOR topology remains available even when no interface is currently active. 7.4 Structural visibility is not authority Discovery, read, execution, and mutation are different capabilities. A user or AI may be permitted to know that a Table exists without being permitted to inspect its records. It may be permitted to read without being permitted to execute an Operator. It may be able to invoke an operation without being permitted to commit an unrestricted mutation. Structural reachability alone answers none of those authorization questions. VISOR LOCATES • OWNERS DEFINE • QUIVER REPRESENTS • DARTBOARD MANIFESTS REACHABILITY != AUTHORITY Figure 7. VISOR Ownership Boundary. VISOR exposes structural terrain and handoffs while semantic owners, representation systems, runtime manifestation, and mutation authority remain distinct. Broad structural reachability is not a transfer of control. 8. AI Orientation and Recursive Self-Mapping A major purpose of VISOR is to make unfamiliar structure legible to intelligence. An AI should not need to infer what a Table means from its name or from whichever screen happens to be open. VISOR gives it a deterministic structural route first; the owning system can then provide domain meaning at the correct destination. 8.1 Unknown-structure reconstruction 1. Locate the Table Registry record for the unfamiliar structural surface. 2. Resolve the containing Stack and the Table's local structural order and purpose. 3. Inspect parent/child Stack topology until the relevant Root Stack is known. 4. Use BRAIN for top-level system orientation when the Root-Stack boundary is reached. 5. Follow explicit relations for siblings, dependencies, bridges, and valid lateral routes rather than inferring them from labels or proximity. 6. Route to the owning system for semantic meaning, to QUIVER for representation possibility, to DARTBOARD for active manifestation, or to SPD when deeper implementation structure is required. 8.2 VISOR can map itself The Stack Registry and Table Registry are themselves registered structural surfaces. VISOR can therefore orient around VISOR: locate the VISOR Stack, locate the Table Registry, resolve its surrounding structure, descend into SPD when needed, and expose the route to the very structures that define the map. This recursive self-description is useful for bootstrapping, diagnostics, and migration. SELF-DESCRIPTION != SELF-AUTHORIZATION 8.3 Scaling law VISOR scales by registering more structure, not by inventing a new navigation theory for every domain. More Tables add registered surfaces. More Stacks add bounded groupings. Deeper organization adds parent/child topology. New cross-domain needs add explicit routes or bridges. The graph grows, while the core questions remain stable: what exists, where does it belong, how is it connected, and how deeply must it be resolved? 9. Native Reconstruction Architecture Native migration is where VISOR becomes more than a navigation convenience. A reconstructable Base must be able to separate architectural meaning from the material implementation that currently realizes it. Airtable can remain valuable as the source construction environment and evidence surface, but the Native Personal Core must be able to rebuild the structural system without treating Airtable record IDs, field widgets, or table UI as the architecture itself. 9.1 Reconstruction dependency FROZEN SOURCE RECONSTRUCTION RELEASE VISOR -> B1-B12 Root Stacks + Stacks + complete Table surface SPD -> Fields + types + links + cardinality + derivations + classifications PORT -> translate implementation material where necessary NATIVE PERSONAL CORE -> construct structural graph -> observe native graph independently -> compare against frozen source -> resolve discrepancies -> verify structural parity -> populate records only after the graph is verified 9.2 VISOR builds the skeleton The first structural pass creates the major territory: B1-B12 Root Stacks, subordinate Stacks, and the complete Table surface. That skeleton must exist before the native Base can safely accept its records because record meaning often depends on relationships whose targets and constraints need to exist first. 9.3 SPD resolves the implementation anatomy After the Table surface exists, SPD supplies the deeper schema description required to recreate Fields, Field types, links, cardinalities, derivations, classifications, and other structural behavior. A new database may realize these concepts with different material primitives. Structural equivalence is measured by whether the same governed relationships and behaviors are reconstructed, not whether the destination looks like Airtable. 9.4 Observe before promotion A native structure is not authoritative merely because the code runs. The reconstructed graph must be observed independently, compared against the frozen source, and checked for missing or altered Stacks, Tables, Fields, links, cardinalities, derivations, and classifications. A discrepancy remains a discrepancy until the correct owner resolves it. Successful execution is evidence of implementation, not proof of architectural parity. RECONSTRUCT STRUCTURE -> OBSERVE -> COMPARE -> VERIFY -> THEN POPULATE RECONSTRUCTABLE STRUCTURE != COPIED IMPLEMENTATION Figure 8. VISOR Native Reconstruction. VISOR recreates Root-Stack, Stack, and Table structure; SPD provides deeper Field-level reconstruction; PORT translates implementation material; independent comparison must verify the native relational graph before record population. 10. Development Boundaries A structurally self-describing Base becomes easier to repair because a failure can be routed to the system that actually owns the missing capability. VISOR should expose enough evidence to locate the structural problem without absorbing every development mechanism into itself. System Question answered Boundary VISOR What structure exists, where does it belong, and how is it connected? Maps and routes structure; does not invent missing semantic meaning or perform mutation. SPD What exact implementation structure realizes this Table or Stack? Describes Fields, types, links, cardinality, derivation, classification, and implementation meaning. PORT How can the preserved operational structure be represented in another material? Translates material implementation; does not redefine source architectural meaning. PATCH What existing structure is broken, ambiguous, redundant, or invalid? Temporary repair/refinement scaffold; canonical owners perform approved changes. BUILD What required structure does not yet exist? Uses bounded structural precedent to propose candidate construction; proposal is not authority. QUIVER How may governed semantics be represented? Representation possibility, not structural geography. DARTBOARD What exact valid manifestation is active now? Task-bounded actuality, not persistent structural source. Shell Where does the active application experience live? Stable territory, not structural ontology. 10.1 Structural gaps A structural gap is useful evidence. If VISOR registers a Table but cannot resolve its Stack, the structure is incomplete. If SPD says a Field links to a target that does not exist, the implementation description and observed Base disagree. If a source relation has no faithful target representation, PORT has a material translation gap. If the existing structure is wrong, PATCH is appropriate. If required structure does not exist, BUILD may be appropriate. STRUCTURAL GAP != PERMISSION TO INVENT 10.2 Repair without category collapse The purpose of these boundaries is not bureaucracy. They localize change. VISOR remains a reliable map because it does not silently become a repair engine, a schema generator, a representation engine, or a runtime manifestation layer whenever something is missing. The correct owner can change while the structural evidence remains inspectable. 11. Formal Invariant Registry The following laws are intended to survive database migration, interface redesign, graph growth, and future refinement. When an implementation contradicts one of them, either the implementation has drifted or an explicit architectural revision is required. TABLE != STACK != ROOT STACK != BRAIN IDENTITY != STRUCTURAL ADDRESS STRUCTURAL ADDRESS != NAVIGATION POSITION STRUCTURAL KNOWLEDGE != SEMANTIC OWNERSHIP STACK MEMBERSHIP != SEMANTIC OWNERSHIP CONTAINMENT != DEPENDENCY != ROUTE != BRIDGE TOPOLOGY != TRAVERSAL TRAVERSAL != DISPLAY STRUCTURAL RELATION != INTERFACE GEOMETRY REACHABILITY != AUTHORITY VISIBLE != WRITABLE DISCOVER != READ != EXECUTE != MUTATE FIELD INVENTORY != SPD PLATFORM IMPLEMENTATION != CANONICAL STRUCTURAL MEANING IMPLEMENTATION RELATION != RELATIONSHIP MEANING STRUCTURAL PROJECTION != STRUCTURAL SOURCE RECONSTRUCTABLE STRUCTURE != COPIED IMPLEMENTATION VISOR DESCRIPTION != CANONICAL MUTATION SELF-DESCRIPTION != SELF-AUTHORIZATION 12. Native Verification Checklist A native VISOR implementation earns authority after independent observation and verification. The tests below are intentionally structural. They do not prove every domain semantic; they prove that the map, hierarchy, relationships, and reconstruction boundaries have survived. 12.1 Root-Stack and Stack verification Exactly the governed B1-B12 Root-Stack identities are reconstructed. Root-Stack numeric position remains orientation rather than execution order. Stack identities, purposes, ordering, and parent/child relationships survive migration. Subordinate Stacks do not become Root Stacks merely because they are structurally deep or important. Stack membership does not alter the semantic identity of member Tables. 12.2 Table verification Every in-scope source Table has one resolvable native structural identity or an explicit documented exception. Table-to-Stack membership is preserved. Table purpose and lifecycle metadata remain distinguishable from Table contents. Cross-Table structural relationships resolve to the intended native targets. No Table relationship is inferred solely from naming similarity or visual adjacency. 12.3 SPD verification Field order and identity can be reconstructed where order is meaningful. Field types have faithful native representations or explicit PORT gaps. Link targets and cardinalities are preserved. Derived Fields remain derived rather than silently becoming manually authored state. Classifications and bounded list/code metadata retain their operational meaning. Field Inventory observations do not override governed SPD description without reconciliation. 12.4 Topology and routing verification Containment, dependency, route, bridge, and order remain distinguishable relation meanings. Human and machine projections can differ without changing the source topology. Task-bounded traversal does not create or delete structural relationships. Permission pruning occurs before protected structure is exposed through a projection. VISOR can derive a structural context around a selected Table without guessing missing edges. 12.5 Ownership verification VISOR can locate BIGFOOT, BOSS, SOLAR, QUIVER, DARTBOARD, and other systems without taking ownership of their semantics. QUIVER remains representation capability rather than VISOR topology. DARTBOARD remains active manifestation rather than persistent structural source. Visible structural controls do not grant mutation authority. VISOR can map its own registries without gaining unrestricted self-modification authority. 12.6 Reconstruction gate Observed state Required response Source and native graphs match at required structural resolution. PASS structural parity and proceed toward record population. A relationship is missing or points to the wrong target. STOP population for the affected scope; route discrepancy to the correct owner. Source relation has no faithful native material representation. Record a PORT gap; do not silently approximate. Existing source structure is invalid or obsolete. Use PATCH and owner review before freezing or promoting the corrected structure. Required structure does not exist in source architecture. Use BUILD to propose candidate structure; verify before promotion. Evidence is insufficient. Remain UNRESOLVED rather than inventing a plausible topology. 12.7 Reconstruction questions 1. What does VISOR own, and what remains outside VISOR authority? 2. What is the difference between a Table, Stack, Root Stack, and BRAIN? 3. What does the Stack Registry contribute that the Table Registry does not? 4. What does the Table Registry contribute that SPD does not? 5. When is Field-level SPD resolution actually required? 6. Why is Field Inventory not equivalent to SPD? 7. Why is structural address different from semantic identity? 8. How are containment, dependency, route, bridge, and ordering kept distinct? 9. Why can a navigation tree change without changing VISOR topology? 10. Why does exact AI routing not imply permission? 11. What changed in VISOR's relationship to QUIVER compared with the older interface-builder framing? 12. How can VISOR map itself without gaining self-authorizing mutation power? 13. What part does VISOR play in Native Personal Core reconstruction? 14. Why must the native relational graph be verified before record population? 15. What should happen when a required structural relationship cannot be proven? 13. Closing Orientation VISOR is straightforward once its ownership boundary is clear. The Base registers structural surfaces, groups them into bounded Stacks, resolves those Stacks into current Root-Stack territory, and preserves explicit relationships that can be traversed without being confused with semantic ownership. When more detail is needed, SPD resolves the implementation structure beneath the Table boundary. When a projection is needed, the structural truth can be manifested through whatever authorized interface is appropriate without turning the projection into a second topology. This architecture makes VISOR useful to humans, AI, development tooling, and migration for the same reason: the structure is explicit enough to inspect. A person can orient through a breadcrumb. An AI can receive a machine-readable structural context. PATCH can identify where existing structure is defective. BUILD can see where capability is missing. PORT can translate implementation material. Native reconstruction can rebuild the Root Stacks, Stacks, Tables, and Fields and then verify the resulting graph before data is allowed to move into it. 13.1 Compressed architecture BRAIN + ROOT-STACK TERRITORY + STACK REGISTRY + TABLE REGISTRY + EXPLICIT STRUCTURAL RELATIONSHIPS + SPD WHEN DEEPER FIELD RESOLUTION IS REQUIRED -> HUMAN / AI / SOFTWARE ORIENTATION -> AUTHORIZED TRAVERSAL AND PROJECTION -> NATIVE STRUCTURAL RECONSTRUCTION -> INDEPENDENT VERIFICATION -> RECORD POPULATION AFTER PARITY 13.2 Reconstruction success test A fresh human or AI has the core VISOR architecture when it can explain that BRAIN provides top-level territory; B1-B12 are the current Root Stacks; the Stack Registry organizes bounded groupings; the Table Registry registers structural surfaces; SPD resolves deeper Field-level implementation structure when required; explicit relationships preserve topology and routing; navigation views are derived projections rather than structural truth; ownership remains with the systems being mapped; and Native Personal Core reconstruction must recreate and independently verify this graph before record population. VISOR EXISTS SO CERBERUS STRUCTURE REMAINS EXPLICIT, TRAVERSABLE, INSPECTABLE, AND RECONSTRUCTABLE EVEN WHEN IMPLEMENTATION CHANGES. End of PASS 8 Verified Release.