CERBERUS SOLAR Persistent Lexical Routing and Semantic Recall Names, Aliases, Native Typed Routes, SOLAR Neighborhoods, GROOVE Accretion, and Semantic Recall CORE ARCHITECTURE STATEMENT SOLAR is the persistent lexical routing and semantic recall surface of CERBERUS. A SOLAR Record binds a governed Name and its Aliases to explicit native registered routes. Those routes make familiar language a reusable entry point into semantic territory without transferring ownership of the targets. GROOVE may recover and validate useful new paths when the known neighborhood is insufficient, allowing repeated semantic work to become cheaper to traverse rather than repeatedly rediscovered. Version 0.2 • August 2026 • SOLAR Reconstruction Architecture B10 - SOLAR Primary question: What familiar language gets me into registered semantic territory, and where has that language already learned to lead? Executive Summary SOLAR gives flexible human language a persistent place to enter CERBERUS. People and AI do not naturally operate by recalling every Bit ID, Registry key, Semantic Kernel address, Thread identity, or symbolic record. They use words, phrases, abbreviations, shorthand, and remembered concepts. SOLAR makes those lexical forms durable routing coordinates while keeping canonical semantic identity in the systems that actually own it. The current canonical implementation is broader than the historical Alias Registry prototype. The live SOLAR table stores a primary Name, alternate Alias forms, and a wide set of native linked-record route fields. A single SOLAR Record may therefore expose several legitimate registered destinations at once. The record is the lexical address; each native route remains explicitly typed; the destination remains authoritative for its own meaning. The same structure supports two different kinds of retrieval. For a human, SOLAR is a find-again surface: remembering Food, VISOR, Thread, or another familiar expression can reveal the system structures already associated with it. For an AI, the same lexical cue becomes a high-information entry coordinate into a previously explored graph. The first encounter with a semantic territory may require broader search and evidence work; later encounters can begin from the established SOLAR Neighborhood. GROOVE supplies the accretive half of this architecture. When exact SOLAR information is insufficient, governed recovery can search source-grounded evidence, preserve unresolved material, and identify useful candidate routes. Successful discovery does not silently become registry truth. Validation and governance remain the boundary between evidence and registration. Once a useful path is retained, future search can reuse that routing work while still checking unresolved or changed deltas. CURRENT ARCHITECTURE UPDATE The current live SOLAR table is canonical for implementation. The earlier one-Alias-record/one-target design remains important historical provenance, but its target-exclusivity rule is superseded. Current SOLAR records combine Name + Aliases + multiple native typed routes. The foundational law survives: lexical form is an address to meaning, not the owner of meaning. Section Index Part Focus A Foundations - purpose, problem, definition, and ownership B Canonical SOLAR Architecture - live table, record anatomy, route typing, neighborhoods, examples C Lexical Resolution and Recall - ingress, multiplicity, context, ambiguity, human and AI retrieval D Accretive Semantic Recovery - SOLAR/GROOVE boundary, discovery, validation, and reuse E CERBERUS Interoperability - component ownership, FULL LOOP, and execution boundary F Governance, Evolution, and Reconstruction - Lenses, provenance, laws, source evolution, and test Appendices Source map, implementation notes, and unresolved/future register Part A - Foundations 1. Purpose and Reconstruction Target This artifact reconstructs SOLAR as a current CERBERUS root capability rather than as a frozen copy of its earliest Alias Registry prototype. The live Airtable table is authoritative for current implementation. The earlier SOLAR specification supplies foundational lexical laws and historical architecture; SOLAR-GROOVE supplies the evidence-recovery boundary; FULL LOOP supplies source-side traversal boundaries; and the Semantic Lenses specification supplies a designed extension path rather than current implementation fact. A successful reconstruction must preserve five ideas simultaneously: language can remain flexible; SOLAR routes must remain explicit and inspectable; multiple native semantic destinations may coexist from one lexical record; target systems retain ownership of their own meaning; and previously solved semantic routing should be reusable rather than repeatedly inferred from scratch. RECONSTRUCTION TARGET A fresh intelligence should be able to receive an expression, find the relevant SOLAR Record, inspect its registered typed routes, use context and permissions to select the relevant territory, recover missing information through GROOVE when necessary, and explain why none of those operations makes SOLAR the owner of the semantic objects it reaches. 2. The Problem SOLAR Solves CERBERUS gains stability by placing semantics in durable registered structures. That stability creates an interface problem: ordinary people do not normally speak in internal Registry IDs, BitWord keys, BOSS record identities, or BOOTSTRAP Thread keys. They say Math, Screen Viewer, Dad, Knowledge Steps, Body Tracker, Food, or thousands of other familiar expressions. Without a persistent lexical layer, every consumer must repeatedly infer what those expressions probably mean. Figure 1 shows the first separation. Mathematics, Math, and Maff are language. The registered semantic structures they lead toward remain independent objects. SOLAR sits between those surfaces and preserves the route without claiming that the word itself is the semantic identity. Figure 1. Language Is Not the Registry. Flexible lexical forms enter stable registered structure through SOLAR; the lexical surface does not become the Registry object. The second problem is duplicated interpretation work. A human search interface, an AI assistant, a parser, and a voice system may all encounter the same phrase. If each consumer performs its own unrecorded semantic guess, the architecture recreates drift at the very boundary SOLAR is meant to stabilize. Figure 2 contrasts repeated guessing with a shared registered lexical routing surface. Figure 2. Without SOLAR, Every Consumer Guesses Again. Persistent lexical routing lets multiple consumers reuse one governed correspondence layer instead of rebuilding the same guesswork independently. PERSISTENCE PRINCIPLE Register the lexical correspondence once so that future consumers can resolve it repeatedly. Inference remains available for the long tail, but known routing work should not disappear after every interaction. 3. Formal Definition of Current SOLAR Current SOLAR is the CERBERUS lexical routing layer whose records bind governed Names and Alias forms to explicit native relationships across registered system structures. A record can be written conceptually as: SOLAR Record = Name + Aliases + Registered Routes The registered routes form a reusable lexical routing surface. SOLAR therefore persists two different kinds of information: how people may name an entry point and where that entry point is already registered to lead. The destination is not copied into the lexical record. The record stores addressability. Figure 3 uses Food as the conceptual example. The word is not a container holding every food-related object. It is a persistent address from which registered routes can expose relevant semantic territory. The displayed Food neighborhood is illustrative of the approved search principle, not a claim that those exact Food routes already exist in the current live table. Figure 3. Language as Persistent Address. A familiar expression can remain a lightweight lexical coordinate while the registered structures it reaches remain independently governed. 4. Ownership and Non-Ownership SOLAR owns lexical addressability. It owns the primary Name stored on a SOLAR Record, its registered Alias forms, and the existence of the SOLAR links that radiate from that record. It does not become the semantic authority for the destination objects merely because it points to them. SOLAR owns the lexical entry and the registered correspondence represented by each SOLAR Route. SOLAR owns discoverability from that lexical entry and the direct SOLAR Neighborhood exposed by its routes. BIGFOOT and specialist registries retain canonical semantic identity and factorization. BOSS retains ownership of symbolic and semantic language structures registered there. BOOTSTRAP retains ownership of governed acquisition structures such as Threads, Cords, Sheets, and Folds. GROOVE retains ownership of source-grounded recovery evidence rather than canonical target identity. FULL LOOP retains source anchoring, source provenance, and deterministic return mechanics. Execution systems, Rules, Operators, and permission contracts retain authority over action. Figure 4 uses the sun metaphor carefully. SOLAR owns the rays - the lexical routes - while the destination boxes remain separate semantic systems. No orbital hierarchy is implied. A direct SOLAR link is an addressable relationship, not ownership of the target. Figure 4. SOLAR Owns the Rays, Not the Planets. SOLAR owns lexical adjacency; the destination systems retain semantic ownership of the objects reached by those routes. Part B - Canonical SOLAR Architecture 5. The Canonical SOLAR Table The current canonical implementation is the live SOLAR Airtable table. At the production evidence lock used for this document, the table contained 34 fields: two lexical fields, 31 direct linked-record route fields, and one derived lookup. The table is deliberately wide because SOLAR is horizontal infrastructure across the semantic environment rather than another vertical identity stack. Field family Current role Fields / examples Lexical Primary lexical entry and alternate forms Name; Alias Registry / Memory Routes into CERBERUS Registry and memory structures 0, X, 00, XX, 000, XXX, 0000, XXXX, 00000, XXXXX, 000000, XXXXXX BRAIN / Interface Routes into system/interface/table structures BRAIN; Interface; Table; Registry BIGFOOT Routes into Bits, BitGroups, BitWords and related collections Bit; BitGroup; BitWord; Compound / Family / Community / World forms BOSS Routes into symbolic language structures BOSS record; Family; Community; World Derived BOSS lookup Rebuildable symbol projection, not a direct route Symbol lookup BOOTSTRAP Routes into knowledge-acquisition Fabric Thread; Cord; Sheet; Fold Figure 8 expresses the architectural consequence of that field layout. SOLAR spans multiple vertical systems as a horizontal lexical surface. A new route family may be added when a genuine semantic distinction needs native preservation; the existence of a field does not require every SOLAR Record to populate it. Figure 8. SOLAR Is Horizontal Infrastructure. The current table crosses Registry, BRAIN, BIGFOOT, BOSS, BOOTSTRAP, and other structures without becoming another semantic depth. 6. SOLAR Record Anatomy The atomic current object is the SOLAR Record. Its primary Name provides the governed lexical entry, Alias stores alternate lexical forms, and the native linked fields expose registered routes. A record may be sparse or richly connected. Its identity does not depend on filling every route family. Figure 5 uses the current Mathematics record: Name = Mathematics, Aliases = Math and Maff, with a registered route to the Mathematical Operators BOSS Family. This is already enough to show that the record is more than an Alias row; it is a lexical hub. Figure 5. Anatomy of a SOLAR Record. A current SOLAR Record combines primary Name, alternate Alias forms, and native registered routes. Two different cardinalities coexist in this object. Aliases converge on one lexical address; routes diverge from the address into the semantic environment. Figure 6 uses the live Addition record. Addition, Add, Plus, and More converge on the same SOLAR Record. The direct BOSS route reaches B000, while the visible plus sign is produced through the derived symbol lookup rather than another direct SOLAR route. Figure 6. Aliases Converge; Routes Diverge. Lexical convergence and semantic route divergence are separate relationships; derived lookup output is not silently redrawn as a direct route. STRUCTURAL DISTINCTION Aliases answer: What expressions enter this SOLAR Record? Routes answer: Where can this lexical address directly lead? Those are different relationships and must remain separately inspectable. 7. Native Route Typing The historical SOLAR paper was correct to resist a single generic Target text field. Current SOLAR extends that idea: relationship class remains visible through the linked field itself. A route into a BOSS Family is not the same relationship type as a route into a BitWord, Registry table, BOOTSTRAP Thread, personal record, or other native structure. The database schema therefore carries semantic information. The current table also contains a derived symbol lookup. That lookup can expose a symbol associated with a linked BOSS record, but it is rebuildable from the direct relationship and must not be mistaken for another native outbound route. Figure 7 makes that canonical/derived boundary explicit. Figure 7. Native Route Types Remain Explicit. SOLAR preserves route family as first-class information; the derived symbol lookup is displayed differently from direct linked-record routes. NATIVE TYPING LAW Do not flatten a semantic distinction the registry can preserve natively. Route class is part of the meaning of a SOLAR relationship. 8. SOLAR Neighborhoods A SOLAR Neighborhood is the set of direct registered semantic destinations available from one SOLAR Record. It is intentionally a first-hop concept. Downstream CERBERUS relationships may make much more territory reachable, but those later graph edges do not become SOLAR Routes merely because they are reachable from a SOLAR target. Figure 9 uses the current VISOR record because it demonstrates a genuinely multi-route neighborhood. The lexical entry Screen Viewer resolves to the VISOR SOLAR Record, which currently exposes registered relationships into BOSS/BRAIN/table/BOOTSTRAP territory. The derived symbol lookup is shown separately, and the larger downstream graph remains outside the Neighborhood ring. Figure 9. The SOLAR Neighborhood. The neighborhood is direct registered lexical adjacency, not every graph edge downstream of the destinations. NEIGHBORHOOD BOUNDARY SOLAR Neighborhood = registered first-hop lexical adjacency. It is not ownership, not the entire reachable graph, and not a permanently closed set. 9. Current Canonical Examples The live table already contains examples across mathematical language, root systems, BOOTSTRAP structure, personal language, temporal language, Registry naming, and Semantic Kernel terminology. These examples are useful because they demonstrate the same routing grammar across very different content domains. Name Aliases Current relevant route pattern Addition Add / Plus / More BOSS B000; derived symbol lookup + Multiplication Times / Product BOSS B003; derived symbol lookup x Mathematics Math / Maff BOSS Family -> Mathematical Operators VISOR Screen Viewer BOSS/BRAIN/Table/Thread routes; derived symbol lookup CERBERUS CERBERUS Matryoshka / Weird Egg Matrix BOSS/BRAIN/Table/Thread routes; derived symbol lookup Thread Knowledge Steps BOOTSTRAP-related route and BOSS identity; derived Thread notation Time - BitWord / Calendar System / Temporal Languages routes Father Dadio / Dad Personal/Registry route -> P234H549 NodeKey Registry Noun Registry / Thing Collection Registry route -> 0 BODY-128 Body Tracker / Body Matrix BitWord route The variety matters more than the count. SOLAR is not restricted to synonyms for technical terms. It can preserve colloquial forms, system nicknames, personal shorthand, formal names, and cross-system lexical addresses as long as the relationships remain explicit and governed. Part C - Lexical Resolution and Recall 10. Language Ingress Operational resolution begins with an expression, not with a semantic target. The system first seeks a Name or Alias match, obtains one or more SOLAR Record candidates, inspects the registered route set, and then applies current context, SCREEN/routing bounds, and permissions to determine which semantic territory is relevant. This updates the earlier word-to-one-target pipeline into a record-first, route-aware process. Figure 10 shows the sequence without claiming that every deployment must implement it as one monolithic parser. The important semantic order is that lexical matching identifies the registered address before contextual selection chooses among the routes made available by that address. Figure 10. Lexical Resolution Pipeline. Modern SOLAR resolves the lexical record first, then narrows the registered route set according to context and authority. 11. Synonymy, Overload, and Two Kinds of Multiplicity SOLAR must distinguish lexical multiplicity from route multiplicity. Lexical multiplicity occurs when several expressions enter the same SOLAR Record. Route multiplicity occurs when one SOLAR Record exposes several native registered destinations. Both are legitimate, but they answer different questions. The current Mathematics and VISOR records make the distinction concrete. Mathematics, Math, and Maff converge on one lexical entry. VISOR demonstrates one lexical entry with several system routes. Figure 11 places those patterns side by side so that a fresh implementation does not collapse them into one generic notion of ambiguity. Figure 11. Lexical Multiplicity vs Route Multiplicity. Many expressions entering one address is not the same relationship as one address exposing many routes. Overload remains possible as well. The same text can legitimately participate in different SOLAR Records or different mapping contexts. Text equality alone never establishes semantic identity. When more than one viable registered interpretation remains, the system preserves the alternatives rather than silently merging them. 12. Contextual Selection Context reduces the set of relevant interpretations. It may include lexical role, prefix or namespace, SCREEN, Routing SK scope, active task, expected target type, permissions, nearby operands, or an explicit user selection. Context is therefore a selector over registered possibilities rather than an editor of the underlying SOLAR data. Figure 12 shows a neighborhood containing routes A, B, C, and D while a current context highlights only B and D. A and C remain registered. When the context changes, they may become relevant again. This preserves the original SOLAR law that context narrows candidates but does not rewrite target identity. Figure 12. Context Narrows; It Does Not Rewrite. Current context can select a relevant subset of a registered neighborhood without deleting or mutating the other routes. 13. Ambiguity and Unresolved Language A conforming lexical system must be allowed to stop short of certainty. Exact resolution, context-resolved selection, ambiguity, and unresolved input are all legitimate states. The existence of an AI model does not change that epistemic boundary. Model confidence can rank possibilities, but registration and evidence remain different from likelihood. Figure 13 therefore gives ambiguity and no-match states first-class visual status. Exact input can traverse. Several viable candidates remain visible and may request more context. No registered match remains unresolved or can enter a governed recovery path. Nothing in that flow requires the system to fabricate a target simply to avoid returning uncertainty. Figure 13. Ambiguity Can Remain Unresolved. Exact, ambiguous, and unresolved are all valid outcomes; uncertainty is represented rather than hidden. 14. Human Recall SOLAR also functions as a semantic find-again surface. Human memory often preserves a topic word, nickname, approximate phrase, or personal shorthand long after the person has forgotten which Registry, Thread, Semantic Kernel, or table contained the desired object. Searching the remembered word can recover the SOLAR Record first, then expose the known registered neighborhood around it. This turns lexical recall into structural recall. The human does not need to remember whether the desired object lived in DRAGON, BOSS, BIGFOOT, BOOTSTRAP, a personal record, or another system. The lexical cue can become the stable re-entry point into the accumulated semantic territory. 15. AI Semantic Traversal The same mechanism has a different benefit for AI. When a familiar lexical cue resolves to a well-developed SOLAR Neighborhood, the model does not need to begin with broad corpus rediscovery or reconstruct every semantic association from prose. It can start from registered adjacency and traverse the governed graph from a known coordinate. Figure 14 places the human and AI uses on opposite sides of the same address. The analogy is functional, not cognitive: human remembering and machine traversal are not claimed to be the same process. What they share is a durable lexical entry surface. Figure 14. One Address, Two Forms of Recall. For a human, SOLAR supports find-again recall; for AI, the same address supports rapid entry into previously registered semantic territory. RECALL PRINCIPLE You do not always need to remember where something was stored. If you remember what it was about, SOLAR can preserve the lexical path back into that territory. Part D - Accretive Semantic Recovery 16. Direct Resolution vs Semantic Recovery SOLAR and GROOVE form a deliberate precedence relationship. Known registered lexical territory should resolve through SOLAR directly. GROOVE is used when the registered lexical surface is insufficient or when a larger semantic construction remains unresolved. GROOVE contributes source-grounded evidence; it does not become a second canonical ontology. Evidence level Class Operational use E5 Explicit semantic address User supplies a canonical ID, notation, or equivalent exact address. E4 Exact SOLAR resolution Registered lexical address yields an authorized route. E3 Registered operand reconstruction Several exact SOLAR spans constrain a larger construction. E2 GROOVE corpus triangulation Authorized source-grounded evidence supports candidate semantic territory. E1 LLM / embedding similarity Search planning and ranking only. E0 Unresolved Evidence remains insufficient for a bounded candidate decision. Figure 15 captures the boundary: a known expression follows its registered route; an unresolved remainder can enter GROOVE recovery. A recovery result remains evidence or a candidate until a separate governed transition establishes a reusable SOLAR relationship. Figure 15. Known Route vs Semantic Recovery. Registered routes are traversed directly; unresolved territory enters a source-grounded recovery process rather than being guessed into canonical status. 17. Discovery vs Traversal A first encounter with a semantic territory may be expensive because the useful routing topology is not yet fully established. The system may need to inspect registered relations, query GROOVEd sources, compare route candidates, reopen evidence, and determine which discovered relationships are useful enough to preserve. That work is discovery. Figure 16 uses Food as an intentionally illustrative search. The starting SOLAR address may already know some routes while other useful territory must be discovered. The figure does not claim that the displayed Food routes currently exist in the live table; it formalizes the approved operational principle that first-use search can cut a trail through the governed semantic environment. Figure 16. First Search: Cutting the Trail. A first search may spend substantial compute exploring relevant semantic territory because useful routes have not yet been established. DISCOVERY LAW Discovery finds useful structure. Traversal reuses established structure. The architecture should not pay full discovery cost every time it enters familiar semantic territory. 18. GROOVE Accretion Discovery is not the same thing as registration. A GROOVE-supported candidate may be useful for the current request without becoming a permanent SOLAR route. Repetition, source support, human review, conformance checks, or another governing mechanism may justify retention, but the transition must remain explicit. The recovered object may also be more than an Alias. In the current architecture, a successful recovery can reveal a useful new Alias for an existing record, a useful new native route from an existing lexical address, a source relationship that should remain only in GROOVE, or a temporary contextual interpretation that should not be persisted. Figure 17 therefore places validation between discovery and accretion. Figure 17. GROOVE Accretion into the SOLAR Neighborhood. Useful discovery can enlarge a SOLAR Neighborhood only after validation and governance; inference does not become registry fact by accident. 19. The Semantic Efficiency Law Once a route is established, future search should begin from the accumulated topology. The system can still inspect changed evidence, newly available objects, permission changes, or unresolved deltas, but it no longer needs to rediscover every known path from raw language or source prose. Figure 18 shows the payoff. A later Food search enters the known SOLAR Neighborhood immediately and can route toward already registered SK, BOSS, DRAGON, memory, or other destinations. Additional compute is concentrated on what is new, changed, unresolved, or contextually relevant. Figure 18. Familiar Search: Follow the Groove. Repeated search begins from established routing and spends additional effort primarily on changed or unresolved deltas. SEMANTIC EFFICIENCY LAW Repeated semantic work should accrete reusable routing structure rather than force repeated rediscovery from prose. Discovery may be expensive. Addressed traversal should become cheap. Part E - CERBERUS Interoperability 20. Component Responsibility Matrix SOLAR is useful because it connects systems without collapsing them. Each neighboring capability owns a different persistence or authority problem. The table below defines the minimum responsibility boundary a reconstructed SOLAR must preserve. Component Owns SOLAR relationship CERBERUS Registries Operational records and state Provides lexical routes into registered operational objects. BIGFOOT Canonical Bit, BitGroup, BitWord, and related semantic identity Provides lexical access to stable semantic operands. BOSS Symbolic and semantic language organization Provides familiar lexical entry into symbolic/semantic identities. BOOTSTRAP Governed acquisition structures Provides lexical recall into Threads, Cords, Sheets, Folds, and knowledge routes. GROOVE Persistent source-grounded evidence Recovers when direct SOLAR information is insufficient. SCREEN / Routing Finite active semantic territory and route scope Narrows the registered routes relevant to the current task. DRAGON Learning organization and learner-state structures Reuses lexical continuity without redefining subject identity. FULL LOOP Source anchors, source traversal, and deterministic return Uses SOLAR as lexical entry while preserving source-side mechanics. Figure 19 turns the same matrix into a visual boundary map. SOLAR is not the universal owner in the middle. It is a lexical service that preserves addressability while the surrounding systems keep their own contracts. Figure 19. Component Responsibility Matrix. SOLAR interoperates broadly while Registry, BIGFOOT, BOSS, BOOTSTRAP, GROOVE, Routing, DRAGON, and FULL LOOP retain distinct responsibilities. 21. FULL LOOP Integration FULL LOOP extends persistent source artifacts with addressable semantic traversal. A source occurrence remains part of the source artifact. FULL LOOP creates or preserves the Surface Anchor, applies lexical resolution through SOLAR, traverses into governed CERBERUS semantic territory, and retains the path needed to return to the original source location. Figure 20 therefore keeps the source side visibly separate from SOLAR. SOLAR supplies lexical addressability. FULL LOOP owns source anchoring and return. The semantic destination remains owned by the canonical CERBERUS system that defines it. This separation allows a document to become semantically traversable without being rewritten into a CERBERUS record. Figure 20. FULL LOOP Uses SOLAR; SOLAR Does Not Become FULL LOOP. SOLAR addresses the meaning; FULL LOOP preserves source-side position, provenance, traversal, and return. 22. Resolution Is Not Execution Lexical reachability must not be mistaken for operational authority. Resolving the word Multiply to an Operator, finding a Rule by name, or locating a mutable object does not execute the Operator, activate the Rule, or mutate the object. The lexical system tells the runtime what registered semantic object is being addressed; another governed system decides whether an action is permitted and valid. Figure 21 places an explicit authorization boundary after lexical resolution. This boundary is essential because SOLAR may be used by AI, voice, search, command, and document systems. A powerful lexical layer becomes unsafe if recognition is silently treated as permission. Figure 21. Resolution Is Not Execution. A resolved route identifies an object; it does not grant authority to execute, activate, or mutate that object. AUTHORITY BOUNDARY Rule found is not Rule activated. Operator resolved is not Operator executed. Object found is not Object mutated. Part F - Governance, Evolution, and Reconstruction 23. Current SOLAR Core vs Future Semantic Lenses The current canonical implementation is one SOLAR routing surface built around Name, Alias, native route fields, contextual resolution, and GROOVE-assisted discovery. The Semantic Lenses specification proposes a future extension in which separately identified SOLAR translation networks can preserve different Mapping Contracts, versions, scopes, and interpretive purposes over the same or overlapping lexical territories. Those ideas are architecturally compatible with current SOLAR but are not current table facts. Lens Profiles, Lens Switching, Lens Stacks, Semantic Parallax, and SOLAR Differentials therefore remain in a designed/future region. Their core value is that perspective can become an explicit governed relationship rather than an invisible assumption. Figure 22. Current SOLAR vs Future SOLAR Lenses. The current canonical routing surface remains distinct from the designed extension toward multiple governed mapping networks and Lens application. Future Lens concept Purpose Mapping Contract Declares why a SOLAR mapping network exists, what it may assert, and under which scope and governance rules. Lens Profile Optional persisted configuration for applying a selected SOLAR to a task or surface. Lens Switching Changes the selected mapping network without rewriting source text or canonical identities. Lens Stack Makes several SOLAR mapping networks available in parallel while preserving independent provenance. Semantic Parallax Records the observable difference produced when the same lexical surface resolves differently under different Lenses. SOLAR Differential Derived comparison of coverage, targets, mapping classes, status, scope, or version across SOLAR networks. 24. Governance and Provenance The current live table is intentionally lean compared with the large governance schema proposed in the historical SOLAR specification. The reconstruction artifact therefore distinguishes governance requirements from live storage fields. A conforming implementation must be able to keep registered relationships distinguishable from AI inference, preserve enough provenance to audit important routes, respect permission boundaries, and prevent candidate discovery from silently becoming canonical lexical routing. A current-request interpretation may be accepted without mutating SOLAR. GROOVE recovery may produce evidence without producing identity. A repeated phrase may become a useful Alias candidate without immediate activation. A new native route may be proposed without becoming current until the appropriate governing transition accepts it. The exact lifecycle fields remain an implementation decision, but the epistemic separation is not optional. GOVERNANCE PRINCIPLE A plausible relationship is not a registered relationship. A useful current-request interpretation is not necessarily a permanent SOLAR route. Registration is an explicit transition. 25. Failure Modes and Common Misunderstandings Anti-pattern Failure Corrective principle SOLAR = dictionary Treats the system as definitions stored under words. SOLAR stores lexical addressability; target systems own meaning. SOLAR = ontology Turns lexical routing into another canonical semantic layer. Keep lexical correspondence separate from canonical identity. Alias text = identity Assumes matching strings prove semantic sameness. Text equality is evidence of lexical form, not semantic identity. Every reachable graph edge = SOLAR Route Explodes the Neighborhood into the entire graph. Only direct registered lexical adjacency belongs to the SOLAR Neighborhood. Context rewrites the record Deletes or changes routes that are not currently relevant. Context narrows selection; the registry remains stable. AI guess = registration Promotes likelihood into canonical correspondence. Keep inference, evidence, proposal, and registration distinct. GROOVE = second ontology Lets source frequency manufacture identity. GROOVE supplies evidence; canonical registries establish identity. Resolution = execution Fires an Operator or mutates an object merely because it was recognized. Resolve first; authorize and execute through the owning runtime. Every search starts from zero Throws away accumulated semantic routing work. Start from the known SOLAR Neighborhood and inspect only needed deltas. 26. Canonical SOLAR Laws The following laws compress the current architecture into reconstructive invariants. They replace the historical one-target conformance rule while retaining the original separation between lexical form and semantic identity. ID Law SOLAR-L01 Lexical form is not semantic identity. SOLAR-L02 A SOLAR Record is a persistent lexical entry into registered structure. SOLAR-L03 Aliases converge on a SOLAR Record; registered routes diverge from it. SOLAR-L04 One SOLAR Record may expose multiple native typed routes. SOLAR-L05 The destination system retains ownership of destination meaning. SOLAR-L06 Native route type remains explicit and shall not be flattened without semantic equivalence. SOLAR-L07 Context narrows available interpretation; it does not rewrite registered objects. SOLAR-L08 Unregistered inference remains distinguishable from registered routing. SOLAR-L09 Resolution does not grant execution authority. SOLAR-L10 Discovery and traversal are distinct operations. SOLAR-L11 Reusable discovery should accrete rather than require repeated reconstruction. SOLAR-L12 Permission boundaries apply before hidden routes, targets, or evidence are disclosed. 27. Source Evolution and Historical Corrections SOLAR evolved without discarding its foundational semantic discipline. The historical August 2026 specification modeled one stable Alias record with exactly one typed target. The live table now uses one SOLAR Record containing Name, Alias, and multiple native route fields. The routing cardinality changed; the address principle did not. Earlier design Current treatment Status One lexical expression per Alias record One SOLAR Record contains primary Name plus alternate Alias forms. Superseded implementation model Exactly one typed target per Active Alias One SOLAR Record may expose multiple native typed routes. Superseded cardinality rule Target Count = 1 Direct route families coexist on one record. Historical invariant only Native typed target fields Native route typing remains explicit and expands across current systems. Retained and expanded Alias is not semantic identity Lexical address remains separate from target meaning. Retained Context narrows; does not rewrite Current context selects relevant registered routes. Retained AI inference != registration Recovery/proposal remains separate from governed registration. Retained Candidate/Validated/Active lifecycle fields Governance goal remains useful; exact live storage is not asserted here. Historical/design pattern One global SOLAR Current live table represents the present canonical routing surface. Current Multiple SOLAR Lenses Kept as designed/future mapping-network architecture. Future / not current table fact Figure 23 makes the correction explicit so later readers cannot accidentally re-import the obsolete one-target architecture as current. The old paper remains valuable provenance because several of its strongest laws continue to govern the new implementation. Figure 23. Historical SOLAR Model vs Current SOLAR Model. The lexical-address principle survives while record cardinality expands from one target per Alias record to multiple native routes per SOLAR Record. 28. Reconstruction Test A fresh AI or human reader has reconstructed SOLAR successfully when it can answer the following scenario without collapsing lexical routing, semantic ownership, recovery evidence, or execution authority: What happens when the expression Screen Viewer is searched, and why might searching it later be faster? Recognize Screen Viewer as an Alias of the current VISOR SOLAR Record. Open the registered SOLAR Neighborhood of VISOR rather than treating the Alias text itself as canonical meaning. Preserve the native route types exposed by that record instead of flattening them into one generic target. Use current context, SCREEN/routing scope, and permissions to determine which route is relevant now. Traverse into the owning semantic system without claiming SOLAR owns that destination. If the known neighborhood is insufficient, preserve the unresolved remainder and use GROOVE or other governed evidence sources for recovery. Keep recovered evidence distinct from registered SOLAR relationships until validation/governance accepts a persistent Alias or route. On later searches, begin from the established VISOR topology and spend additional effort primarily on changed, unresolved, or newly relevant deltas. Do not execute, mutate, or disclose protected objects merely because lexical resolution succeeded. Figure 24 closes the reconstruction by placing lexical entry, native routes, Neighborhood, context, human/AI recall, GROOVE accretion, and authority boundaries around the same SOLAR core. Future Lenses remain outside the current-core boundary. Figure 24. SOLAR Reconstruction Map. Reconstruction succeeds when lexical entry, routing, recall, GROOVE recovery, and authority boundaries remain distinct but interoperable. FINAL PRINCIPLE Language enters through SOLAR. Registered routes preserve where that language can lead. Semantic territory remains governed by the systems SOLAR reaches. Appendix A - Canonical Source and Authority Map The reconstruction follows an explicit authority order. Current implementation follows the live SOLAR Airtable table. Companion documents supply architectural principles, historical provenance, recovery behavior, source-surface traversal, and designed future extensions. Source Role in this reconstruction Authority treatment Live Airtable table: SOLAR Current Name/Alias schema, current native route families, current examples. Canonical current implementation CERBERUS SOLAR - System Operational Lexical Alias Registry v0.1 Lexical-address principle, ambiguity, context, permissions, parsing, native typing, historical one-target model. Foundational + historical CERBERUS SOLAR-GROOVE Semantic Recovery v0.1 Evidence precedence, recovery boundary, source-grounded triangulation, candidate promotion discipline. Companion recovery architecture CERBERUS FULL LOOP v0.1 Source anchoring, semantic surface traversal, deterministic return, resolution/execution boundary. Dependent interoperability source CERBERUS SOLAR-Powered Semantic Lenses v0.1 Mapping Contracts, Lens Profiles, Lens Stacks, Parallax, Differential, multiple SOLAR networks. Designed future extension Appendix B - Current Implementation Notes The current live table is intentionally a practical routing surface rather than a complete governance database. The following implementation facts are important for reconstructing what is current without overclaiming what is already formalized. The table currently has 34 fields: Name, Alias, 31 direct linked-record route fields, and one derived symbol lookup. Direct route fields span Registry/Memory, BRAIN/interface structures, BIGFOOT, BOSS, and BOOTSTRAP. The symbol lookup is derived and should remain visually and semantically distinguishable from direct linked-record routes. A SOLAR Record may be sparse; no rule requires every route family to be populated. The current table demonstrates multi-route records directly, including VISOR and CERBERUS. The Food discovery diagrams are architectural illustrations of GROOVE-forming search, not snapshots of a current Food record. The exact persistence mechanics for validating and adding newly discovered routes remain a governance implementation concern. Appendix C - Unresolved and Future Register Area Current boundary Route validation workflow The semantic requirement is explicit, but the exact current Airtable fields/status lifecycle for candidate-to-registered promotion are not fixed by this artifact. Route versioning / aging Future implementations may need route history, supersession, and reproducibility without silently rewriting prior traversal history. Permission-scoped neighborhoods Permissions must apply before disclosure; exact per-route permission storage remains implementation-specific. Personal/private SOLAR routing Personal shorthand can be useful, but future scoping must avoid silently globalizing private mappings. GROOVE-to-SOLAR promotion Repeated stable recoveries may justify Aliases or routes, but frequency alone must never establish canonical truth. Multiple SOLAR networks / Lenses Architecturally designed but not asserted as current live SOLAR implementation. Semantic Parallax / Differentials Remain future comparative capabilities associated with Lens architecture. RECONSTRUCTION CHECK If a future revision changes the current table, update the current implementation sections and figures first. Preserve historical source provenance separately. Do not silently rewrite the earlier specifications or treat a later table shape as proof that earlier architecture never existed.