5 - CERBERUS_SOLAR_GROOVE_Semantic_Recovery_Formal_Specification_v0.1.docx

CERBERUS SOLAR–GROOVE Semantic Recovery Corpus-Assisted Resolution from Natural Language to BIGFOOT through Accreted Semantic Evidence CORE SYSTEM STATEMENT SOLAR resolves registered language exactly. GROOVE supplies source-grounded semantic evidence for the long tail that SOLAR does not yet know. BIGFOOT remains the canonical identity substrate. RESOLVE EXACTLY WHEN POSSIBLE. TRIANGULATE WHEN NECESSARY. PRESERVE THE EVIDENCE CHAIN. Formal System Specification v0.1 15 August 2026 | CERBERUS / SOLAR / GROOVE / BIGFOOT Semantic Infrastructure Status: Draft formal specification for prototype semantic recovery, AI integration, corpus experiments, and governance testing. Document Control Field Value Document CERBERUS SOLAR–GROOVE Semantic Recovery — Formal Specification Version 0.1 Date 15 August 2026 System CERBERUS / SOLAR / GROOVE / BIGFOOT semantic architecture Specification role Defines a corpus-assisted semantic recovery cascade for unresolved or partially resolved natural language. Primary source basis CERBERUS SOLAR Formal Specification v0.1; BIGFOOT 4 Tables Details; GROOVE and Routing-SK specifications in the current documentation stack. Canonical identity rule GROOVE evidence can support a candidate semantic route; BIGFOOT and governed registries remain authoritative for canonical identity. Lexical governance rule Using a candidate for one request does not create a SOLAR Alias. Alias promotion remains a separate governed lifecycle. Normative vocabulary MUST, MUST NOT, SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY Abstract This specification defines SOLAR–GROOVE Semantic Recovery as a bounded fallback architecture for translating long-tail human expressions into inspectable candidate CERBERUS semantics when exact SOLAR lexical routes are missing or insufficient. The architecture begins with strict SOLAR resolution, preserves any exact typed targets, carries unresolved spans forward, and then uses authorized GROOVEd corpora as accumulated semantic evidence. Matching Observable Entries already contain multifactor Routing-SK classifications; their saved semantic states can therefore be aggregated to estimate which BitWords, BitGroups, Bits, Models, Operators, or candidate compositions most consistently characterize the unresolved expression. The process is evidence-producing rather than identity-producing: corpus support and enrichment may prioritize candidates, but only governed semantic records establish canonical identity. SPECIFICATION THESIS SOLAR does not need exhaustive lexical coverage to remain useful. It can stay precise and governed while GROOVE provides a progressively richer, source-grounded recovery surface for language outside the registered vocabulary. Core normative laws ID Normative law SGR-L01 Exact registered SOLAR resolution SHALL outrank probabilistic corpus inference. SGR-L02 Unresolved lexical material SHALL remain explicitly unresolved until a candidate route is supported and selected under a declared evidence state. SGR-L03 GROOVE corpus evidence MAY support candidate resolution but SHALL NOT by itself establish canonical identity or a SOLAR Alias. SGR-L04 Routing-support counts SHALL preserve multifactor semantics and MUST NOT be presented as mutually exclusive probabilities unless the governing Routing SK is itself exclusive. SGR-L05 Candidate recovery MAY terminate at BitWord, BitGroup, Bit, Model, Operator, Rule, or a composed candidate structure according to evidence granularity. SGR-L06 Corpus evidence SHOULD be evaluated against an appropriate baseline before raw frequency is treated as diagnostically meaningful. SGR-L07 Source reopening SHALL remain available so a GROOVE-supported candidate can be traced back to Observable Entries and relevant locations. SGR-L08 Current-request acceptance SHALL NOT mutate SOLAR, BIGFOOT, Routing SKs, or the source corpus. SGR-L09 Repeated stable recoveries MAY generate SOLAR Candidate records; activation SHALL require SOLAR governance. SGR-L10 Permission filtering SHALL occur before candidate counts, semantic distributions, hidden targets, or source evidence are disclosed. Contents at a Glance Part Focus Part I Foundations and system position Part II Resolution modes and evidence precedence Part III Corpus Semantic Triangulation Part IV BIGFOOT operand recovery and candidate construction Part V Accretive recovery, SOLAR coverage, and lexical promotion Part VI Interface architecture Part VII Worked example: moisture-responsive material query Part VIII Governance, failure modes, and conformance Appendices Reference schemas, formulas, test fixtures, and glossary Companion specifications CERBERUS SOLAR — System Operational Lexical Alias Registry v0.1: exact registered lexical resolution, native typed targets, ambiguity preservation, parsing provenance, and AI integration boundaries. BIGFOOT semantic identity spine: stable Bit, BitGroup, BitWord, and Compound BitWord identities with explicit composition and reuse by reference. Routing Semantic Kernels: bounded semantic routing structures capable of multifactor route activation and recursive semantic narrowing. GROOVE — Grounded Relations Over Observable Versioned Entries: persistent source-grounded semantic routing, accreted projections, and cross-corpus reuse. Semantic Grooving and GROOVE Routing SK add-on: model-conditioned saved projections, multifactor corpus discretization, branch factorization, and reusable semantic evidence. SOURCE BOUNDARY This paper extends the documented SOLAR and BIGFOOT roles. It does not redefine the canonical identity responsibilities of those systems. Illustrative IDs and category names in examples are placeholders unless already registered elsewhere. 0. Executive Summary SOLAR already provides a strict lexical front end for CERBERUS: registered words and phrases resolve to one exact typed target, ambiguity is preserved when several authorized candidates remain, and AI likelihood cannot silently manufacture canonical identity. BIGFOOT, in turn, provides the stable semantic operands that SOLAR addresses: Bits, BitGroups, BitWords, and Compound BitWords exist as durable identities rather than labels reconstructed from prose. The remaining problem is the long tail of human expression. A user may describe a known phenomenon with an unregistered synonym, historical term, metaphor, partial mechanism, or idiosyncratic phrase. The intended semantic structure may already exist in BIGFOOT even though SOLAR has never registered the language used to reach it. SOLAR–GROOVE Semantic Recovery addresses that gap by treating a GROOVEd corpus as accumulated semantic evidence rather than as a second ontology. Figure 1. Semantic recovery cascade. Figure explanation. The system first attempts strict SOLAR resolution. Exact typed targets proceed directly to BIGFOOT. Unresolved spans can trigger authorized GROOVE search, multifactor routing aggregation, semantic triangulation, selective source reopening, and a bounded current-request decision. Stable repeated recoveries may later propose a SOLAR Alias Candidate under normal governance. The result is a layered semantic entry strategy: exact address when known; reconstruction from registered operands when partially known; corpus-assisted triangulation when language outruns the registry; and explicit unresolved state when evidence remains insufficient. The fallback therefore expands practical language coverage without weakening the precision rules that make SOLAR useful. SHORT FORM SOLAR remembers the words CERBERUS has formally learned. GROOVE remembers where the other words have tended to lead. PART I — Foundations and System Position 1. Purpose and Scope This specification defines the runtime and documentation architecture for corpus-assisted semantic recovery. It applies when a natural-language request contains material that cannot be resolved exactly through authorized SOLAR Aliases, or when several exact lexical operands exist but the higher-order semantic construction remains insufficiently constrained. The architecture covers query decomposition, SOLAR candidate assembly, GROOVE corpus search, aggregation of saved multifactor Routing-SK states, semantic support and enrichment, progressive resolution from broad BitWords toward BitGroups and Bits, source reopening, current-request selection, recovery logging, and candidate lexical promotion. It does not make corpus frequency a source of canonical truth and does not bypass the existing SOLAR, BIGFOOT, Rule, Operator, permission, or governance contracts. 2. Architectural Boundary: Language, Evidence, and Identity Three layers must remain distinct. SOLAR owns registered lexical correspondence. GROOVE owns persistent source-grounded interpretation over Observable Entries. BIGFOOT and specialist registries own canonical semantic identity. A recovery event may traverse all three layers, but no layer silently becomes another. Layer Primary question Authority boundary SOLAR What exact registered semantic object can this lexical expression address? Lexical route only; Alias does not own target meaning. GROOVE Where has similar language or meaning tended to land in an authorized corpus? Evidence and routing projection; does not create canonical identity. BIGFOOT / registries What is this semantic object, how is it factorized, and what relationships does it have? Canonical semantic identity and composition. CORE SEPARATION Lexical similarity may retrieve evidence. GROOVE correspondence may support a candidate. Canonical identity still belongs to the registered target. 3. Why a Recovery Layer Is Necessary A precise lexical registry should not attempt to pre-register every possible paraphrase, historical expression, discipline-specific term, metaphor, spelling variant, or user-created phrase. Doing so would trade semantic stability for vocabulary explosion. Conversely, forcing every unregistered phrase to remain permanently unusable would make the natural-language layer brittle. Corpus-assisted recovery resolves the tension by allowing the system to exploit literature and prior documents as a noncanonical evidence layer. The same phrase can also describe a composition rather than a single object. “Biological material that detects damage and grows back” may involve a Materials Model, a Biology Model, one or more transformation Operators, and a stopping Rule. The recovery system therefore searches for the appropriate semantic granularity rather than assuming that every human phrase must map to one BitWord. 4. Formal System Position Figure 15. Cybernetic semantic recovery loop. Figure explanation. Human language first enters SOLAR. Exact addresses can route directly to BIGFOOT and registered behavior. Unresolved material may use GROOVE triangulation, source verification, and a current-request decision. Repeated stable recoveries accumulate in a separate recovery log and may propose a governed Alias Candidate. Only validated promotion shortens the future path back into SOLAR. PART II — Resolution Modes and Evidence Precedence 5. Mode A — Exact SOLAR Address Resolution Mode A is the highest-authority path. The parser identifies a registered lexical span, applies language, target type, prefix, lexical role, SCREEN, Routing, domain context, permissions, and other declared constraints, and terminates at an exact authorized SOLAR target. No GROOVE search is needed merely because corpus evidence might also exist. Examples include a canonical name, validated synonym, abbreviation, technical phrase, command phrase, multilingual Alias, or qualified Model name. The output retains the target class: Bit, BitGroup, BitWord, Compound BitWord, Routing SK, Model, Rule, Operator, Color, Symbol, Learning Object, or another approved native target. 6. Mode B — Lexical Operand Recovery When the whole expression does not resolve, the parser preserves every exact span it can recover. These spans form a Candidate Operand Set, while the unresolved remainder stays visible. The LLM may segment the request, rank registered candidates, and propose likely grammatical roles, but it does not promote a candidate into canonical certainty by likelihood alone. Figure 3. SOLAR operand trace. Figure explanation. The exact word “wet” can resolve to a registered moisture target while “material” remains ambiguous and “clamps tighter” remains unresolved. The parser carries these facts forward as candidate semantic ingredients instead of replacing the full request with one opaque probabilistic guess. LEXICAL OPERAND RECOVERY The recovery of registered semantic candidates from resolvable lexical spans contained within an otherwise unresolved expression. 7. Mode C — GROOVE Corpus Semantic Triangulation Mode C begins only when exact and composite SOLAR information is insufficient. The system constructs a bounded retrieval plan from the unresolved remainder and any already-resolved operands, searches authorized GROOVEd corpora, and inspects the saved semantic coordinates of matching Observable Entries. Because the Entries were previously GROOVEd, the system can reason over compact routing states before reopening the original documents. CORPUS SEMANTIC TRIANGULATION The use of multiple GROOVEd Observable Entries sharing lexical or semantic material with an unresolved expression to estimate which registered Routing SK positions, BitWords, BitGroups, Bits, or other semantic objects most consistently characterize that expression. 8. Evidence Precedence Level Evidence class Use E5 Explicit semantic address User supplies a canonical ID, registered notation, or equally explicit semantic address. E4 Exact SOLAR resolution Registered Alias resolves to one authorized typed target. E3 Registered operand reconstruction Several exact SOLAR spans strongly constrain a candidate semantic construction. E2 GROOVE corpus triangulation Authorized corpus evidence strongly favors one or more registered semantic coordinates. E1 LLM / embedding similarity Candidate retrieval, search-plan generation, and ranking only. E0 Unresolved Evidence insufficient for a bounded candidate decision. PRECEDENCE LAW Lower evidence may enrich or challenge a higher-level interpretation, but it may not silently override an exact registered route. A SOLAR/corpus disagreement is a diagnostic condition to inspect, not permission to rewrite SOLAR. 9. Recovery Mode versus SOLAR Resolution State Recovery Mode is an orchestration property and must not overwrite SOLAR’s own resolution vocabulary. An interaction can therefore record Mode = GROOVE_ASSISTED while individual lexical spans remain EXACT, AMBIGUOUS, or UNRESOLVED under SOLAR. The candidate target may additionally carry an Evidence State such as GROOVE-SUPPORTED or PROPOSED. Dimension Illustrative values Meaning SOLAR Resolution State EXACT, CONTEXT-RESOLVED, AMBIGUOUS, UNRESOLVED Status of one lexical route under SOLAR. Recovery Mode DIRECT_SOLAR, OPERAND_RECONSTRUCTION, GROOVE_ASSISTED How the overall request is being resolved. Evidence State REGISTERED, GROOVE-SUPPORTED, PROPOSED, REJECTED Authority/evidence status of a candidate semantic target or construction. PART III — Corpus Semantic Triangulation 10. Query Decomposition and Retrieval Planning The LLM is most useful here as a search-plan designer. It can preserve the original request, identify exact SOLAR spans, isolate the unresolved remainder, propose bounded paraphrase features, infer likely semantic target classes, and generate several retrieval populations instead of one monolithic similarity query. For “material that clamps tighter when wet,” a retrieval plan might include exact features such as material and wet; candidate paraphrase features such as moisture, water, swelling, contraction, clamping, and tightening; a relational feature such as moisture → structural change; and expected target classes such as scientific domain, material property, state-change mechanism, Model, or Operator. Each feature remains traceable to the original request or to an explicitly marked AI proposal. Figure 4. GROOVE corpus match explorer. Figure explanation. A bounded GROOVE search can combine exact lexical features and AI-proposed retrieval features. The result is not a semantic answer yet; it is a set of authorized Observable Entries whose existing GROOVE states can be analyzed without immediately reopening every full source. 11. Permission-Bounded Evidence SOLAR already requires permission filtering before hidden candidate names or counts are disclosed. The same principle applies to GROOVE evidence. Corpus support must be calculated from Entries and semantic targets visible to the active permission context. A hidden corpus cannot influence a displayed count in a way that leaks its existence. The permission context therefore becomes part of the Recovery Record. Two authorized users can legitimately receive different support distributions from the same query if their corpus visibility differs. This is not semantic inconsistency; it is an explicit evidence-scope difference. 12. Multifactor Routing Support A Routing SK can activate several compatible factors for one Entry. Aggregating GROOVE states must preserve that property. If 2,046 matching documents produce 1,806 Materials activations, 721 Biology activations, and 488 Food Sciences activations, the counts may overlap because a single Entry can contribute to several semantic branches. Figure 5. Multifactor semantic distribution. Figure explanation. The matched corpus can support several broad scientific regions simultaneously. The interface explicitly warns that counts overlap and are not mutually exclusive probabilities. This preserves the meaning of multifactor Routing SK analysis. MULTIFACTOR EVIDENCE LAW A document can support several semantic routes. Corpus support measures how often a route is active among matching Entries; it does not force the corpus into one-label classification. 13. Semantic Support and Semantic Enrichment Raw support identifies common routes among matching Entries. Diagnosticity requires a baseline. A route that appears in 88% of query matches is highly informative if it appears in only 35% of the relevant corpus, but much less informative if 84% of the corpus already occupies that route. For route r, query-matched set M, and baseline corpus C, a simple diagnostic can be written as: REFERENCE FORMULAS Support(r | q) = active Entries in M for route r ÷ |M| Baseline(r | C) = active Entries in C for route r ÷ |C| Semantic Enrichment(r | q, C) = Support(r | q) ÷ Baseline(r | C) Semantic Enrichment is not a probability that the route is true. It is a comparative measure of overrepresentation. Baseline selection is itself a governed methodological choice: the whole database, a relevant collection, a time-bounded corpus, or another declared reference population may be appropriate depending on the query. Figure 6. Support versus corpus baseline. Figure explanation. The Materials route is strongly overrepresented among the query matches relative to the example corpus baseline. The display frames enrichment as a diagnostic measure, not a truth probability. 14. Lexical Conditional Enrichment Single words are often broad. The interaction between terms can be substantially more diagnostic. The system can therefore compare GROOVE evidence for “wet,” “tighten,” and “wet + tighten,” or more generally for several conditionally combined lexical features. A sharp increase in enrichment only when terms co-occur identifies a semantic neighborhood that neither term isolates alone. Figure 9. Lexical conditional enrichment. Figure explanation. The same candidate BitGroup has weak-to-moderate enrichment for the individual terms but strong enrichment when the terms co-occur. This signal can prioritize a more focused semantic branch for deeper inspection. 15. Co-Activation and Branch-Aware Evidence A query can also exploit co-activation patterns inside one Routing SK. If Materials + Biology repeatedly co-activate in the matching set, the system may construct a new semantic surface for a dedicated pass without asserting that the Routing SK itself has changed. Corpus co-activation belongs to the GROOVE evidence layer, not to the canonical Router definition. Cross-GROOVE evidence is distinct: the same Entry may independently resolve under SCIENCE, FOOD, HISTORY, or other published Routing SK templates. Shared Entry identity makes these saved projections composable. Query-time recovery can therefore intersect evidence surfaces such as SCIENCE:Materials with FOOD:Fermentation, provided the operation remains traceable to the source projections and permissions. 16. Progressive Semantic Resolution Broad support can seed branch-specific higher-resolution analysis. A strong Materials route does not end the process; it provides context for a MATERIALS-64 or MATERIALS-256 pass, or for inspecting reusable BitGroups inside the resulting Model family. Higher semantic resolution increases available precision, not epistemic certainty. The process may stop early when the source evidence does not justify finer classification. Figure 7. Progressive BIGFOOT / Routing drilldown. Figure explanation. A broad SCIENCE-16 Materials route narrows to Responsive Materials, then Moisture-Responsive structure, and finally a reusable BitGroup. Each node remains inspectable and may expose support, baseline, enrichment, provenance, source coverage, and next permissible resolution. PART IV — BIGFOOT Operand Recovery and Candidate Construction 17. Multi-Level Candidate Recovery BIGFOOT’s separate registries for Bits, BitGroups, BitWords, and Compound BitWords matter directly to semantic recovery. The system should rank candidates at the level supported by the evidence rather than flattening everything into one text label. A phrase may denote a whole semantic word, a reusable group shared by several Models, an atomic Bit, or a composition of several objects. Figure 8. Multi-level candidate ranking. Figure explanation. Candidate evidence is grouped by semantic target class. The interface can explicitly recommend BitGroup granularity when that is more diagnostic than any whole BitWord or individual Bit. 18. Candidate Semantic Construction Some unresolved requests are structurally composite. Rather than forcing one winner, the recovery engine can assemble a candidate construction from several registered or GROOVE-supported operands. Each component retains its own evidence state. The semantic construction layer then evaluates type compatibility, Rules, Model contracts, and permissions just as it would for an exact-SOLAR request. Figure 10. Candidate semantic construction. Figure explanation. A cross-domain request can resolve to a Materials Self-Repair Model, a Biology Regeneration Model, a proposed Directed Growth Operator, and a proposed stopping Rule. The interface preserves which parts are GROOVE-supported versus merely proposed. COMPOSITION BOUNDARY Canonical operands do not make a generated composition canonical. A candidate semantic construction must still satisfy its applicable Rules, permissions, type constraints, and target-specific contracts. 19. From Recovered Operand to Semantic Neighborhood Once the request reaches a candidate or exact BIGFOOT operand, the system can regain the normal CERBERUS graph: Models that use the Bit or BitGroup, Operators that transform relevant state, Rules that constrain those transformations, Routing SKs that expose related territory, FASKs and FRINGE structures exploring nearby possibilities, and GROOVEd documents independently classified into the same semantic neighborhood. This is the practical payoff of the recovery cascade. A messy human phrase does not merely return a document. It can recover a semantic address from which the system knows what formal structures already exist and what operations are available. 20. Source Reopening and Verification GROOVE makes broad corpus reasoning cheap because previously generated descriptions and routing states can be read quickly. Consequential resolution should still support selective descent into original documents, images, diagrams, or other Observable Entries. Reopening is targeted: the system inspects a diverse, high-support subset rather than rereading the entire corpus. Figure 11. Source evidence browser. Figure explanation. The candidate BitGroup opens into supporting sources with branch context and exact relevant locations. The user or AI can reopen the observable source before using the candidate in a consequential semantic construction. 21. Current-Request Decision After source inspection, the system can use the candidate for the current request, compare alternatives, or preserve unresolved state. This decision belongs to the parse or working context. It does not mutate SOLAR, BIGFOOT, a Routing SK, or the source corpus. Figure 12. Recovery decision panel. Figure explanation. The interface separates candidate evidence from the action taken. “Use for request” affects only the current parse; “compare” exposes alternatives; “keep unresolved” preserves uncertainty. A permanent Alias requires a later governed promotion workflow. PART V — Accretive Recovery, SOLAR Coverage, and Lexical Promotion 22. Semantic Recovery Records A successful or unsuccessful recovery event can itself be persisted as a compact, versioned, noncanonical record. This lets future systems reuse the semantic work rather than repeating the entire retrieval experiment. The Recovery Record is not a SOLAR Alias and not a BIGFOOT identity; it is operational evidence about how one expression was resolved under a particular corpus, permissions, Model versions, and decision state. Field Purpose Recovery ID Stable operational identity for the recovery event. Original expression Unmodified user input or source span. Exact SOLAR operands Registered targets resolved before fallback. Unresolved remainder Material that triggered recovery. Corpus / scope Authorized GROOVE corpus and version used. Search plan Exact features, AI-proposed features, and constraints. Matched Entry count Size of the evidence population. Top Routing support Broad semantic coordinates and counts. Baseline + enrichment Diagnostic comparison against declared corpus prevalence. Top BIGFOOT candidates BitWord, BitGroup, Bit, Model, Operator, or composition. Reviewed sources Observable Entries reopened during validation. Current-request decision Accepted, compared, rejected, or unresolved. Alias promotion state None, Candidate proposed, reviewed, validated, etc. 23. Repeated Stable Recoveries If the same expression repeatedly resolves through the same corpus-supported semantic route across different requests, users, corpora, or contexts, that pattern becomes useful evidence that SOLAR may be missing a stable lexical doorway. The recovery system can aggregate these events without silently promoting them. Figure 13. Repeated recovery to SOLAR Alias Candidate. Figure explanation. A recurring phrase with a stable dominant target can produce a reviewable Alias Candidate. The candidate enters the normal SOLAR governance lifecycle and is not Active merely because the recovery statistics are strong. 24. SOLAR Coverage Diagnostics Recovery telemetry can reveal how much user language resolves directly, how often composite registered operands are sufficient, which domains rely heavily on GROOVE fallback, and which repeated phrases are strong Alias opportunities. This creates a usage-driven lexical development pathway rather than forcing designers to guess which synonyms deserve registration in advance. Figure 14. SOLAR coverage dashboard. Figure explanation. The dashboard separates exact SOLAR, composite SOLAR, GROOVE-assisted, and unresolved requests, then exposes recurring fallback phrases as review opportunities. The metrics diagnose lexical coverage; they do not automatically modify the registry. 25. Retroactive Improvement without Corpus Rewrite A newly validated Alias can shorten future resolution without changing the historical recovery record or source corpus. Likewise, improved Routing SKs, better GROOVE projections, or newly published Models can increase the precision of future recovery. Existing Recovery Records retain their original versions and provenance, allowing impact analysis and optional recompilation rather than silent reinterpretation. ACCUMULATIVE PROPERTY The corpus stays stable while the semantic infrastructure around it improves: new Models refine GROOVE; GROOVE exposes recurring lexical patterns; governance promotes useful routes into SOLAR; future requests become cheaper and more exact. PART VI — Interface Architecture 26. Design Goals for the Recovery Interface The interface should make semantic recovery feel inspectable rather than magical. Users should be able to see what SOLAR resolved exactly, which spans remain unknown, what corpus was searched, how many Entries matched, which Routing SK factors were supported, how baseline enrichment affected ranking, what BIGFOOT target class is being proposed, and which original sources justify the result. A conforming interface may compress these details for ordinary use, but the full evidence trace should be available on demand. Hidden chain-of-thought is unnecessary; the system can expose the operational evidence objects, registered routes, counts, source locations, and explicit rules that produced the candidate. 27. Semantic Resolution Console Figure 2. Semantic Resolution Console. Figure explanation. The console presents one unresolved request, a SOLAR trace, GROOVE evidence, the candidate target, and the available decisions in one screen. Status labels distinguish exact registered evidence from GROOVE-supported candidates. 28. Corpus Evidence Explorer The corpus explorer should support query features, selected corpus/version, permission scope, matched source types, and an explicit action to analyze saved routing states. It should also let the user reopen individual source Entries without implying that every retrieved source supports the final candidate equally. 29. Semantic Distribution and Enrichment Views The distribution view should default to multifactor support counts, not normalized pie charts. A separate enrichment view should compare query support to corpus baseline and identify which semantic coordinates are unusually concentrated. This separation prevents a common visualization error: making overlapping multifactor categories appear mutually exclusive. 30. Progressive Drilldown View The drilldown interface should allow the user to click from a broad route into a branch-specific finer Routing SK, then into BitGroups or Bits. Each node should expose the local support count, baseline frequency, enrichment, source coverage, version, and next permissible routing or BIGFOOT inspection paths. 31. Candidate Inspector and Decision Surface The candidate inspector should display target type, stable ID, human-readable name, evidence state, exact SOLAR operands supporting the route, relevant GROOVE distributions, source review coverage, alternative candidates, and downstream Models/Operators/Rules that would become available if the candidate is used. The decision surface should make “use for this request” visually distinct from “create SOLAR Candidate.” 32. Alias Promotion Queue A separate governance interface should aggregate repeated stable recoveries and allow a reviewer to open the expression, target, source evidence, cross-corpus stability, acceptance history, and conflicts before creating a Candidate Alias record. Candidate generation is therefore evidence-rich but still subject to SOLAR’s normal validation and target-exclusivity rules. 33. Interface Status Vocabulary Status badge Meaning Recommended visual treatment REGISTERED Exact governed SOLAR or canonical target relationship. Teal / navy; solid. GROOVE-SUPPORTED Candidate has source-grounded corpus support but is not canonical lexical correspondence. Gold / purple; solid outline. PROPOSED AI or human hypothesis requiring review. Purple; lighter fill. AMBIGUOUS Multiple authorized compatible candidates remain. Gold warning. UNRESOLVED No sufficiently supported candidate. Red warning. HIDDEN Not displayed; authorization filtering occurs before counts or hints. No visible badge — information is not disclosed. PART VII — Worked Example: Moisture-Responsive Material Query 34. Source Request User request: “What’s the material thing that clamps tighter when wet?” The phrase is intentionally informal. It does not assume that the user knows the registered technical term, the target class, or whether the phenomenon is represented as a whole Model, a BitGroup, or a transformation Operator. 35. SOLAR Pass The parser resolves wet to an authorized moisture semantic target. Material returns several authorized candidates because the word is broad. Clamps tighter has no exact registered phrase in the current SOLAR scope. Recovery Mode therefore becomes GROOVE_ASSISTED while the exact SOLAR moisture target is preserved. 36. Retrieval Plan The LLM proposes a bounded retrieval plan containing the exact features material and wet, candidate features moisture, water, clamping, contraction, tightening, and dimensional change, plus an expected semantic neighborhood around materials and state-change mechanisms. These candidate features are search aids, not canonical synonyms. 37. Corpus Evidence The authorized Materials Research Archive returns 2,046 matching Observable Entries. Their saved SCIENCE-16 GROOVE states show 1,806 Materials activations, 721 Biology activations, 488 Food Sciences activations, and 341 Chemical Sciences activations. The counts overlap because the Entries are multifactor. Compared with a 35% Materials baseline in the selected corpus, the 88% query support corresponds to approximately 2.51× enrichment. 38. Branch Drilldown The system follows the Materials branch into a finer Routing SK. Responsive Materials appears in 1,014 matching Entries, then a Moisture-Responsive region in 783. Within that region, BitGroup BG-00812 has the strongest diagnostic support and 4.92× enrichment relative to its baseline prevalence. The recovery engine recommends BitGroup granularity rather than inventing a whole new Model name. 39. Source Reopening The system reopens a diverse subset of high-support sources: papers, diagrams, and a book section. Eighteen of twenty reviewed sources are compatible with the candidate interpretation, while two use the same lexical surface for a different mechanism. Those two are retained as alternative evidence rather than discarded. 40. Current-Request Resolution The candidate is presented as GROOVE-SUPPORTED. If the user accepts it for the request, the working parse may use BG-00812 and immediately inspect the Models, Operators, Rules, and other GROOVEd literature that relate to that canonical semantic neighborhood. The acceptance does not create or modify any SOLAR Alias. 41. Later Lexical Promotion Over time, the phrase “hygroscopic response” repeatedly produces the same target across several authorized corpora and a high proportion of reviewed current-request decisions. The system proposes a Candidate Alias pointing to BG-00812. A human or governed validation process reviews the lexical role, language, target exclusivity, corpus evidence, and potential collisions. Only after validation may the new Alias become Active and future requests resolve directly through SOLAR. WORKED-EXAMPLE RESULT The recovery system did not make literature canonical. It used literature that was already GROOVEd to recover a likely canonical operand, verified that candidate against selected sources, and kept lexical registration as a separate governed act. PART VIII — Governance, Failure Modes, and Conformance 42. Evidence Is Not Identity Corpus frequency, semantic enrichment, co-activation, source agreement, or LLM confidence can justify attention and support a bounded current-request candidate. None of these creates a new canonical identity. The architecture is deliberately asymmetric: canonical records can structure corpus interpretation, while corpus interpretation can only propose routes back toward canonical records. 43. Corpus Bias and Baseline Choice A specialized archive can make its dominant domain appear semantically likely for almost every query. Enrichment must therefore declare the baseline population, and interfaces should expose corpus composition when it materially affects interpretation. Cross-corpus stability can provide additional evidence, but differences between corpora may be meaningful and should not be averaged away automatically. 44. Stale GROOVE Evidence A saved GROOVE Projection is versioned interpretation. If the Routing SK, Model family, source corpus, or GROOVE Pass configuration changes, downstream Recovery Records may become stale. Implementations should preserve the original evidence lineage and mark affected recoveries for optional re-evaluation rather than silently rewriting historical results. 45. Adversarial and Noisy Corpora A large corpus can be poisoned by repeated copied text, low-quality AI-generated documents, coordinated terminology abuse, or duplicated sources. Raw frequency therefore should not dominate candidate ranking. Source diversity, provenance quality, deduplication, publication independence, and branch consistency can be included as configurable diagnostics. These factors remain evidence controls, not hidden canonical rules. 46. Failure Modes and Required Corrections Failure mode Why it fails Required correction Treat GROOVE frequency as canonical truth Popularity replaces registered identity. Return a candidate evidence state and preserve source trace. Normalize multifactor counts to 100% Overlapping semantic factors become falsely exclusive. Show independent support counts and state that totals may exceed corpus size. Ignore corpus baseline Dominant corpus categories appear falsely diagnostic. Calculate or disclose an appropriate baseline and enrichment. Force one target class A phrase may denote a BitGroup, Bit, Model, Operator, or composition. Rank at multiple BIGFOOT target classes. Promote current-use acceptance into SOLAR One local decision silently rewrites lexical truth. Keep request decision separate from Alias Candidate governance. Use hidden corpus evidence in visible counts Permissions leak through statistics. Filter authorization before retrieval, counts, and explanations. Discard conflicting sources The evidence chain becomes artificially clean. Preserve alternative routes and ambiguous evidence. Use embeddings as semantic identity Similarity bypasses SOLAR and BIGFOOT governance. Use embeddings/LLM only for retrieval and candidate ranking. 47. Conformance Requirements ID Requirement SGR-C01 A conforming implementation SHALL attempt authorized exact SOLAR resolution before GROOVE fallback for the same material span. SGR-C02 Exact SOLAR targets SHALL remain typed and traceable to the selected Alias record. SGR-C03 Unresolved spans SHALL remain explicit in the parse trace. SGR-C04 AI-proposed retrieval features SHALL be distinguishable from exact source tokens and registered SOLAR Aliases. SGR-C05 GROOVE corpus retrieval SHALL be permission-bounded before counts or target identities are disclosed. SGR-C06 Routing-support aggregation SHALL preserve multifactor semantics. SGR-C07 A candidate ranking SHOULD expose baseline prevalence or document why baseline comparison is not applicable. SGR-C08 The system MAY rank BitWords, BitGroups, Bits, Models, Operators, Rules, or candidate compositions; it SHALL preserve target class. SGR-C09 A GROOVE-supported candidate SHALL remain distinguishable from REGISTERED evidence. SGR-C10 Selected source Entries SHOULD be reopenable from the recovery trace. SGR-C11 Accepting a candidate for one request SHALL NOT create or mutate a SOLAR Alias. SGR-C12 Repeated recovery MAY produce a SOLAR Candidate but SHALL NOT bypass normal Alias governance. SGR-C13 Recovery Records SHOULD preserve corpus version, Routing SK / Model versions, search plan, evidence counts, and decision state. SGR-C14 A SOLAR/corpus disagreement SHALL be surfaced as a diagnostic rather than silently resolved by corpus frequency. SGR-C15 If evidence remains insufficient, the result SHALL remain ambiguous or unresolved. 48. Reference Test Fixtures Fixture Focus Setup Expected result T-01 Exact Alias precedence Input contains an exact Active SOLAR Alias and a corpus distribution favoring another target. Exact Alias remains authoritative; corpus disagreement is diagnostic. T-02 Partial operand recovery One phrase contains one exact SOLAR span plus one unresolved relation. Exact operand is preserved and only the remainder enters fallback. T-03 Multifactor support Matched Entries activate several SCIENCE routes. Support counts overlap and are not normalized to exclusive probabilities. T-04 Baseline diagnostic A route has high query support but is also dominant in the corpus. Enrichment shows limited diagnostic value. T-05 BitGroup termination BitGroup is more enriched than any BitWord candidate. Resolver may recommend BitGroup granularity. T-06 Current-use acceptance User accepts GROOVE-supported candidate for one request. Working parse uses it; SOLAR remains unchanged. T-07 Alias promotion Repeated recovery pattern meets review threshold. System creates Candidate Alias only; Active remains governed. T-08 Permission isolation Hidden corpus contains strong competing route. Hidden evidence does not affect disclosed counts or candidate names. T-09 Source contradiction Reviewed sources include incompatible mechanism. Contradiction remains visible; candidate evidence state may weaken or remain ambiguous. T-10 No sufficient evidence Corpus support is diffuse and low enrichment. System remains unresolved rather than forcing a target. 49. Conclusion SOLAR–GROOVE Semantic Recovery allows CERBERUS to remain strict at its lexical and semantic core while becoming much more tolerant of the way people actually speak, write, remember, and search. The system does not need a pre-registered Alias for every human expression. It needs a disciplined way to preserve exact known operands, use accumulated semantic evidence when the vocabulary runs out, return to observable sources, and keep the resulting candidate separate from canonical identity until governance says otherwise. FINAL PRINCIPLE Exact address when known. Compose registered operands when partially known. Triangulate through GROOVEd literature when language outruns the registry. Promote recurring recoveries only when they earn registration. Appendix A — Reference Semantic Recovery Record Field Example Recovery ID SGR-R000184 Original expression material that tightens when wet Recovery Mode GROOVE_ASSISTED Exact SOLAR operands BIT-MOISTURE Unresolved remainder tightens when wet Corpus Materials Research Archive v12 Matched Entries 2,046 Top broad route SCIENCE-16: Materials — 1,806 Top finer route MATERIALS-256: Moisture-Responsive — 783 Top BIGFOOT candidate BG-00812 Enrichment 4.92× against declared baseline Evidence State GROOVE-SUPPORTED Reviewed sources 20 Current-request decision Accepted SOLAR Alias state None Appendix B — Reference Candidate Ranking Inputs Implementations may use a configurable ranking function, but this specification intentionally does not prescribe one universal weighted score. Useful evidence dimensions include: Exact SOLAR operand compatibility. Routing support among matched GROOVE Entries. Semantic Enrichment relative to a declared corpus baseline. BitWord / BitGroup / Bit specificity and resolution depth. Cross-corpus stability of the candidate route. Source diversity and deduplication. Reviewed-source compatibility ratio. Branch consistency with the already-resolved operands. Target-type compatibility with the grammatical or tool position. Conflicting evidence and unresolved alternatives. RANKING BOUNDARY A configurable score may order candidates for inspection. The score SHALL NOT be represented as canonical semantic certainty unless a separate governed contract explicitly defines such an interpretation. Appendix C — Glossary Term Definition Corpus Semantic Triangulation Use of multiple GROOVEd Entries and their saved semantic states to estimate likely registered semantic coordinates for unresolved language. Evidence State Status describing how a candidate is supported, such as REGISTERED, GROOVE-SUPPORTED, or PROPOSED. Lexical Conditional Enrichment Increase in semantic diagnosticity when several query features are evaluated jointly rather than independently. Lexical Operand Recovery Recovery of registered semantic candidates from resolvable spans within an otherwise unresolved expression. Recovery Mode Overall orchestration path used for a request: direct SOLAR, operand reconstruction, GROOVE-assisted, or unresolved. Semantic Enrichment Overrepresentation of a semantic route among query-matched Entries relative to a declared corpus baseline. Semantic Recovery Record Versioned operational record of one recovery event, its corpus evidence, candidate targets, and current-request decision. GROOVE-Supported Resolution A bounded current-request candidate supported by GROOVEd corpus evidence and source inspection but not equivalent to a registered SOLAR Alias. Current-Request Resolution A local working decision for the current parse or task; it does not mutate canonical registries. Alias Promotion Candidate A proposed SOLAR Alias derived from repeated stable recovery evidence and submitted to normal governance. Appendix D — Source Basis and Compatibility Notes This specification is designed to remain compatible with the existing SOLAR and BIGFOOT documents used as source material for this paper. The following points are treated as inherited constraints rather than redefined here: SOLAR Alias is an address to meaning, not meaning itself; an Active Alias resolves through one exact typed target field. Ambiguous or unresolved lexical material remains explicit; AI likelihood may rank suggestions but may not manufacture canonical identity. SOLAR preserves native target class for Bit, BitGroup, BitWord, Compound BitWord, Routing SK, Model, Rule, Operator, and other approved target types. BIGFOOT registers stable semantic identities for Bits, BitGroups, BitWords, and Compound BitWords and exposes their composition and reuse by reference. Shared semantic identity is distinct from shared mutable runtime state; this paper likewise keeps corpus evidence, lexical correspondence, and canonical identity as separate layers. The new architectural contribution of this paper is the recovery cascade that operates between unresolved lexical material and canonical semantic operands. It uses GROOVEd literature as evidence while preserving the existing authority boundaries of SOLAR and BIGFOOT.