CERBERUS TRIANGULATED SEMANTIC CONSISTENCY AND RESOLUTION Error Detection, Research Routing, and Approval-Governed Repair across Documentation, BIGFOOT, BOSS, and VISOR Documentation Narrative truth BIGFOOT Terminology truth BOSS Symbolic truth VISOR Structural truth Architecture and Implementation Specification Version 1.0 | 5 August 2026 Conceptual architecture specification for the CERBERUS reference prototype and future production runtime Document Purpose and Control This specification defines the semantic consistency architecture through which Documentation, BIGFOOT, BOSS, and VISOR independently represent the same system and validate one another. It also defines how detected discrepancies become structured issues, how missing evidence is researched, and how proposed corrections are presented as governed candidates for user or organizational approval. Table 1. Document control Control Value Document type Architecture and implementation specification System scope CERBERUS semantic documentation, terminology, Symbology, structural models, and resolution workflows Primary audience System architect, implementation partners, documentation authors, ontology stewards, AI agents, governance reviewers Current implementation context Airtable reference prototype; dedicated production runtime planned Authority model Canonical records remain governed by their owning Registries; AI may detect, research, and propose but does not silently rewrite canonical truth Status Conceptually complete architecture; implementation tables and workflows to be assembled and validated Version 1.0 Date 5 August 2026 Core thesis A self-documenting system becomes self-consistent only when its prose, terminology, symbols, and structural models can be compared as independent but linked claims. Agreement raises semantic confidence. Disagreement becomes a routable error. Executive Summary CERBERUS maintains several governed representations of the same architecture. Documentation explains the system in natural language. BIGFOOT stabilizes internal terminology and definitions. BOSS supplies BaseCodes, Symbol Keys, Families, operators, and close semantic relations. VISOR preserves explicit hierarchy, dependency, containment, sequence, and comparison relations. Together, these sources form a semantic checksum. An AI or validation process can inspect a document, resolve every internal term through BIGFOOT, resolve every symbol through BOSS, and compare every material relational claim against VISOR. A discrepancy is not treated as a vague editorial concern. It becomes a typed Consistency Issue with sources, affected versions, confidence, impact, missing evidence, and candidate owners. The architecture then routes the issue to a simple Consistency Resolution Workspace. The workspace presents the conflicting claims side by side, identifies the likely error class, generates scoped research prompts for missing evidence, records the research returned, and compiles one or more candidate corrections. A candidate can propose a Documentation patch, a BIGFOOT definition update, a BOSS symbolic correction, a VISOR relation change, or a coordinated multi-source repair. Nothing becomes canonical until the required user or organizational authority approves it. This produces an operational cycle in which system change, documentation, terminology, Symbology, and structure continually reconcile. The result is not the impossible claim that the system can never be wrong. The result is a system in which internal disagreement is explicit, classified, inspectable, researchable, and governable. Architecture at a Glance Figure 1. Triangulated semantic consistency loop SYSTEM CHANGE OR DOCUMENT REVIEW | v Documentation claims ---- BIGFOOT definitions ---- BOSS symbols/operators \ | / \ | / +------ VISOR structural relations ------------+ | v TRIANGULATED VALIDATION | agreement ------+------ discrepancy | | v v semantic confidence Consistency Issue | v Research and Evidence Routing | v Candidate Resolution Package | v User or Organizational Approval | v Synchronized Patch and Revalidation Governance boundary The architecture may automate detection, evidence gathering, comparison, prompt generation, impact analysis, and candidate drafting. Canonical changes remain subject to explicit authority, versioning, audit, and rollback rules. Table of Contents 1. Purpose, Scope, and Design Principles 5 2. Four Linked Sources of Semantic Truth 6 3. Triangulation as a Semantic Checksum 7 4. Consistency Rules and Machine-Testable Claims 8 5. Error Taxonomy 10 6. Detection and Classification Pipeline 11 7. Evidence, Confidence, and Version Alignment 12 8. Consistency Issue Registry 14 9. The Consistency Resolution Workspace 15 10. Research Prompt Routing 16 11. Candidate Resolution Generation 18 12. User and Organizational Approval 19 13. Routing through CERBERUS, BIGFOOT, BOSS, VISOR, and QUIVER 21 14. Worked Examples 22 15. Data Model and Implementation Schema 24 16. Governance, Security, and Failure Controls 26 17. Operations, Metrics, and Continuous Reconciliation 26 18. Future Implications 28 Appendix A. Error Detection Matrix 29 Appendix B. Research Prompt Templates 30 Appendix C. Candidate and Approval Templates 31 Glossary 32 Subject Index 36 Page references are tied to this edition. Canonical concepts remain addressable through BIGFOOT Terms, BOSS Symbol Keys, and VISOR relations even when pagination changes. 1. Purpose, Scope, and Design Principles 1.1 Purpose The purpose of this architecture is to make internal semantic consistency operational. It treats documentation claims, glossary definitions, symbolic identities, and structural relations as testable representations rather than isolated artifacts. The system can therefore locate disagreements, identify what kind of disagreement has occurred, assemble the evidence required to resolve it, and present a governed correction candidate. 1.2 Scope Internal terms, preferred names, aliases, definitions, examples, and deprecation history. BaseCodes, Symbol Keys, glyph bindings, operator semantics, Families, Communities, and close symbolic relations. Narrative claims made in Documentation, including purpose, behavior, hierarchy, sequence, dependency, and limitations. VISOR relations that explicitly state containment, dependency, routing, precedence, comparison, permission, and interface dynamics. Version alignment and propagation of approved changes across affected records and documents. Research prompts and evidence packets used to resolve missing, ambiguous, or conflicting information. Approval workflows for personal Bases, teams, organizations, and federated semantic environments. 1.3 Design principles Table 2. Consistency architecture design principles Principle Operational meaning Linked independence Each source remains authoritative for its own class of meaning while linking to the others. Explicit disagreement Conflicts are preserved as issues rather than silently normalized. Semantic comparison The validator checks meaning, relation, scope, and version, not only identical wording. Research before repair Missing evidence produces a scoped research task rather than a guessed correction. Candidate before canon AI-generated solutions are proposals until approved by the relevant authority. Synchronized resolution A conceptual change is not complete until all affected representations are reconciled. Inspectable provenance Every detection, research step, candidate, approval, and patch is traceable. Fail-closed ambiguity Unresolved meaning remains unresolved; the system does not invent certainty. 1.4 What the architecture does not claim Triangulation does not prove that the shared conclusion is objectively correct. Multiple sources can inherit the same mistaken assumption. The architecture instead raises the cost of unnoticed contradiction, identifies uncertainty, and creates a disciplined path for research and correction. External reality, implementation tests, domain evidence, and authorized human judgment remain necessary. Important distinction Internal consistency means that governed representations agree with one another at the declared version and scope. External validity means that the system also agrees with observed reality, verified sources, or operational results. The first can be tested internally; the second requires evidence beyond the internal graph. 2. Four Linked Sources of Semantic Truth The consistency architecture uses four primary sources because each reveals a different failure mode. Their value comes from both connection and separation. If one source merely copied another, agreement would provide little independent evidence. Table 3. Canonical responsibilities of the four validation sources Source Canonical role What it governs Characteristic errors Documentation Narrative explanation Purpose, context, examples, constraints, process, limitations Outdated prose, omitted caveats, reversed relations, ambiguous terminology BIGFOOT Governed terminology Preferred term, formal definition, aliases, contrasts, documentary footprints Definition drift, synonym collision, deprecated wording, undefined internal term BOSS Operational Symbology BaseCode, Symbol Key, glyph, Family, Community, operator behavior, close relations Wrong symbol, wrong operator, Family mismatch, glyph collision, semantic overreach VISOR Explicit structure Hierarchy, dependency, containment, routing, sequence, comparison, interface mapping Reversed dependency, false containment, missing bridge, incorrect process order 2.1 Documentation as narrative truth Documentation is the richest explanatory layer. It can describe why a component exists, how it developed, where it is useful, what assumptions it makes, and how it relates to examples. That richness also makes prose vulnerable to drift. A sentence can remain grammatically plausible long after the underlying architecture has changed. 2.2 BIGFOOT as terminology truth BIGFOOT gives each internally meaningful term a governed identity. Every term used in canonical Documentation should resolve to an active BIGFOOT record or an approved alias. The record identifies the preferred wording, formal definition, plain-language definition, term class, status, version, related terms, linked Documentation, and linked BOSS meaning. 2.3 BOSS as symbolic and operational truth BOSS governs symbolic identity and operational semantics. A symbol used in Documentation must resolve to the correct Symbol Key or BaseCode. The associated operator must perform the action claimed by the text, within the declared Community, Family, input type, output type, and scope. A visually similar glyph is not sufficient. 2.4 VISOR as structural truth VISOR states the relational architecture explicitly. A diagram may show a box above another box, but the machine-readable map must say whether the relation is CONTAINS, PRECEDES, DEPENDS-ON, ROUTES-TO, PRODUCES, BRIDGES, or merely APPEARS-NEAR. VISOR therefore prevents visual proximity from being mistaken for structural meaning. Figure 2. Example of a consistent cross-source concept DOCUMENTATION: "QUIVER selects applicable relations and sends them to VISOR." BIGFOOT: QUIVER = dynamic interface relation selection and assembly. BOSS: QUIVER {SELECTS, SCOPES, LOADS, ROUTES-TO} VISOR. VISOR: QUIVER PRECEDES VISOR; VISOR RECEIVES relation set. RESULT: Four representations agree at the same version and scope. 3. Triangulation as a Semantic Checksum 3.1 Why triangulation matters A single source can be internally coherent and still be wrong. Triangulation compares independent expressions of the same concept. When three or four sources converge, the system has stronger reason to treat the concept as stable. When they diverge, the pattern of divergence helps locate the likely error. 3.2 The semantic checksum Figure 3. Conceptual semantic checksum For each governed concept C: Term(C) = BIGFOOT preferred term and definition Symbol(C) = BOSS BaseCode, Symbol Key, and operator semantics Structure(C) = VISOR relations and dependency orientation Narrative(C) = Documentation claims and examples Consistency(C) exists when these claims are compatible at the same scope, status, and version. Any incompatible claim creates an issue. 3.3 Majority agreement is evidence, not automatic authority If Documentation, BIGFOOT, and BOSS agree while VISOR differs, VISOR is a strong error candidate. However, the system should not automatically overwrite VISOR. The structural model may contain the newly approved architecture while the other sources are stale. The discrepancy pattern identifies where to investigate first; version, provenance, approval state, and implementation evidence determine the correction. 3.4 Bilateral, triangular, and quadrilateral checks Table 4. Levels of semantic validation Check type Coverage Use Limitation Bilateral Two sources compared Fast local validation, such as Documentation term against BIGFOOT Can miss a shared error or a structural conflict elsewhere Triangular Three sources compared Locates an outlier and provides stronger semantic confidence May omit the fourth class of evidence Quadrilateral All four sources compared Full terminology-symbol-structure-narrative reconciliation Requires complete linkage and version metadata 3.5 Consistency state Consistent: no material incompatibility is detected for the declared version and scope. Consistent with caveat: the claims agree, but one or more sources are intentionally less specific. Pending propagation: a canonical change is approved but not yet reflected in every linked source. Conflicting: two or more active claims cannot simultaneously be true. Incomplete: required links or evidence are missing. Version-skewed: claims may be correct for different versions but are currently compared without alignment. Unresolved: the system lacks enough evidence or authority to determine a canonical repair. 4. Consistency Rules and Machine-Testable Claims The architecture becomes operational through rules that can be evaluated by AI, formulas, scripts, automations, or runtime services. Rules may generate warnings, blocking errors, or research requirements depending on severity and governance policy. Table 5. Core consistency rules Rule Machine-testable requirement Primary issue R-01 Every internally defined term in canonical Documentation resolves to an active BIGFOOT Term or approved Alias. Undefined Term R-02 Every canonical BIGFOOT Term links to at least one defining Documentation source. Undocumented Term R-03 Every symbol used operationally in Documentation resolves to an active BOSS Symbol Key or BaseCode. Unresolved Symbol R-04 The documented meaning of a symbol is compatible with the linked BOSS definition and Family. Symbol Meaning Mismatch R-05 Every material hierarchy or dependency claim in Documentation is represented or explicitly excepted in VISOR. Structural Mismatch R-06 Every VISOR component label resolves to BIGFOOT or an approved public term. Unresolved Model Label R-07 Documentation, BIGFOOT, BOSS, and VISOR records compared together share a compatible version scope. Version Conflict R-08 Deprecated terms and symbols are not used in active Documentation unless marked as historical references. Deprecated Usage R-09 Operational behavior claimed in Documentation is supported by the BOSS operator contract. Operational Mismatch R-10 An approved semantic change identifies and reconciles all affected linked sources. Propagation Failure R-11 AI-generated candidate repairs retain evidence, confidence, assumptions, and approval status. Untraceable Candidate R-12 No candidate becomes canonical without the authority required by its target Registry and scope. Approval Violation 4.1 Rule severity Table 6. Severity model Severity Meaning Examples Informational Potential enrichment or non-blocking gap Missing example, no Visual Model, weak plain-language definition Warning Likely inconsistency that does not yet threaten execution Alias drift, minor version lag, missing secondary link Error Material contradiction or unresolved semantic identity Wrong definition, wrong symbol, reversed dependency Critical Could cause unauthorized action, incorrect compilation, or widespread semantic corruption Approval bypass, executable operator mismatch, permission-bearing relation error 4.2 Exceptions must be explicit Documentation may intentionally simplify a concept for a beginner, use a historical term, or omit a relation irrelevant to the current audience. Such variance is valid only when marked with scope, audience, rationale, and the canonical link. An explicit exception is not an error; an unexplained contradiction is. 5. Error Taxonomy Typed errors make the resolution pathway predictable. The same detection surface can route a terminology issue to a glossary steward, a symbolic issue to BOSS governance, a structural issue to VISOR review, or a coordinated issue to several owners. Table 7. Primary semantic consistency error taxonomy Class Error type Detection condition Typical response Terminology Undefined Internal Term A term appears in Documentation or VISOR but has no BIGFOOT resolution. Create or link a BIGFOOT record; determine whether the phrase is internal or public language. Terminology Definition Mismatch Documentation implies a meaning incompatible with the canonical BIGFOOT definition. Review scope and version; patch prose or revise definition through approval. Terminology Alias Collision Two terms are treated as synonyms although they refer to distinct concepts. Separate terms, establish preferred names, and add contrast relations. Terminology Deprecated Usage An active document uses a deprecated term as though it were current. Replace or mark historical use; preserve provenance. Symbolic Unresolved Symbol A glyph or token appears without a BOSS Symbol Key or BaseCode. Link existing symbol or mint a governed BaseCode. Symbolic Symbol Meaning Mismatch The same glyph is interpreted using the wrong Community, Family, or contextual meaning. Correct context binding; add fallback label and scope. Symbolic Operator Contract Mismatch Documentation claims an operator accepts inputs or produces outputs not allowed by BOSS. Correct claim or version the operator contract. Symbolic Glyph Collision Two distinct symbolic objects render identically without sufficient disambiguation. Add context, alternate rendering, or confusable-glyph warning. Structural Hierarchy Mismatch Documentation and VISOR disagree about containment or parent-child orientation. Verify owning structure and update the out-of-date source. Structural Dependency Reversal A source states A depends on B while another states B depends on A. Research causal and implementation evidence; correct relation direction. Structural Sequence Mismatch Process order differs between Documentation and VISOR. Confirm actual runtime or approved process sequence. Structural Missing Relation A material relation is documented but absent from VISOR, or vice versa. Create relation or mark it illustrative/non-canonical. Versioning Version Skew Sources are accurate for different versions but treated as contemporaneous. Align version scope or update lagging source. Versioning Propagation Failure An approved change reached only some linked records. Generate affected-object list and complete synchronized patch. Coverage Orphaned Glossary Term A BIGFOOT term has no defining Documentation or current use. Document, defer, deprecate, or archive. Coverage Undocumented Symbol A BOSS symbol lacks explanatory Documentation or learning context. Create documentation and examples. Evidence Unsupported Claim A material statement lacks evidence, source, or implementation confirmation. Generate research prompt and attach findings. Evidence Conflicting Evidence Credible sources support incompatible resolutions. Preserve plurality; escalate to authority or scoped versioning. Governance Approval Violation A canonical record changed without required authority. Rollback, quarantine change, and investigate audit trail. Governance Permission-Scope Leak Validation or resolution interface exposes unpermitted terms, relations, or records. Prune unauthorized subgraph before display or research. 5.1 Compound errors A single inconsistency may span categories. A renamed component can produce deprecated terminology, a stale BaseCode label, an outdated VISOR relation, and several documentation mismatches. The issue should preserve one root incident with linked sub-issues rather than creating disconnected tickets that hide the shared cause. 5.2 False positives The validator should distinguish contradiction from simplification, audience-specific language, metaphor, example data, future-state design, historical description, and intentional version comparison. Each claim therefore benefits from metadata such as claim type, scope, audience, temporal state, implementation status, and canonicality. 6. Detection and Classification Pipeline Figure 4. End-to-end consistency detection and repair pipeline 1. INGEST Read Documentation, BIGFOOT, BOSS, and VISOR records. 2. EXTRACT Identify terms, symbols, relations, claims, versions, and scopes. 3. RESOLVE Link terms to BIGFOOT and symbols/operators to BOSS. 4. COMPARE Test narrative and model claims against VISOR relations. 5. CLASSIFY Assign issue type, severity, source pattern, and likely owner. 6. SCORE Record confidence, evidence completeness, and potential impact. 7. ROUTE Create or update a Consistency Issue and select a resolution view. 8. RESEARCH Generate prompts when evidence or context is missing. 9. PROPOSE Compile one or more candidate repair packages. 10. APPROVE Present candidates to authorized users or organizational roles. 11. APPLY Patch approved sources through controlled actions. 12. REVALIDATE Re-run all affected consistency checks and close or reopen. 6.1 Claim extraction The system identifies more than nouns. It extracts definitions, equivalence statements, exclusions, input-output claims, sequence statements, causal claims, dependency directions, version references, permission conditions, and modal language such as must, may, planned, deprecated, and active. 6.2 Resolution order Resolve explicit IDs, Symbol Keys, BaseCodes, and linked-record references first. Resolve exact BIGFOOT preferred terms and approved aliases. Resolve BOSS close relations, broader and narrower terms, and contextual Families. Use semantic similarity only when direct identifiers are absent. Mark low-confidence matches as candidates and request clarification rather than asserting identity. 6.3 Comparison patterns Table 8. Discrepancy patterns and routing logic Pattern Meaning Response Agreement All active claims are compatible Record validation timestamp and confidence. Single outlier Three sources converge and one differs Prioritize the outlier for review, but check version and provenance. Two-versus-two split Two compatible clusters conflict Research implementation evidence and approval history. All divergent Each source expresses a different claim Treat as architectural ambiguity; suspend automatic repair. Missing source One or more canonical links absent Create coverage issue before semantic comparison. Version split Claims align within versions but not across them Create version-aware Crosswalk or propagate current version. 6.4 Idempotent detection Repeated scans should update the existing open issue rather than create duplicates. A stable Issue Fingerprint can combine affected Concept ID, source pair, rule, version, and claim signature. New evidence becomes an event on the same issue unless the underlying conflict has materially changed. 7. Evidence, Confidence, and Version Alignment 7.1 Evidence hierarchy Table 9. Evidence hierarchy for semantic resolution Evidence class Examples Use Direct implementation evidence Runtime behavior, verified table schema, code contract, permission test, approved Registry record Highest operational authority for implemented behavior Approved architecture record Current VISOR relation, BOSS operator contract, BIGFOOT definition, signed decision Canonical internal design authority Current Documentation Published specification tied to current version Strong explanatory authority Historical provenance Prior versions, decisions, deprecated records, change logs Useful for intent and evolution; not automatically current External research Standards, domain evidence, public definitions, test results Required when internal sources are insufficient or external validity matters Inference AI synthesis or human interpretation not yet approved Candidate evidence only; must be labelled 7.2 Confidence dimensions Identity confidence: certainty that the phrase or symbol resolves to the intended governed object. Claim confidence: certainty that the extracted statement accurately represents the source text or model. Comparison confidence: certainty that the two claims are materially comparable at the same scope. Resolution confidence: certainty that a candidate repair addresses the root cause. Impact confidence: certainty about which linked documents, symbols, relations, Interfaces, or workflows are affected. 7.3 Version alignment Every comparison should record source version, effective date, status, and scope. A current Documentation statement should not be marked wrong merely because it differs from an archived BIGFOOT definition. Instead, the system asks whether the document is describing the archived version or whether the link should be updated to the current term. Figure 5. Minimum alignment metadata for reliable comparison Comparison Key - Concept ID - Source type - Source record ID - Semantic version - Effective date - Status - Audience or scope - Implementation state: Planned / Prototype / Production - Canonicality: Canonical / Illustrative / Historical / Candidate 7.4 Evidence gaps become research requirements The validator should never hide a gap inside a confidence score. It explicitly lists what is unknown: actual runtime behavior, intended ownership, approved term, operator input contract, external standard, or historical decision. These gaps become the inputs to research prompt generation. 8. Consistency Issue Registry Detected discrepancies become first-class records. The Issue Registry prevents semantic problems from remaining trapped in comments, chat messages, or memory. It also gives CERBERUS a durable operational history of how its own language and structure were repaired. Table 10. Consistency Issue Registry fields Field Purpose Issue ID Stable unique identity Issue Fingerprint Deduplication key based on concept, rule, source pair, version, and claim signature Title Human-readable summary Error Type Linked taxonomy record Severity Informational, Warning, Error, Critical Concept / NodeKey Primary semantic object affected Source Claims Linked claim records extracted from Documentation, BIGFOOT, BOSS, and VISOR Conflicting Sources Source records currently incompatible Agreement Sources Sources that currently converge Scope and Version Comparison boundary Evidence Attached internal and external findings Evidence Gaps Unknowns that block resolution Research Prompts Generated or approved prompt records Candidate Resolutions One or more proposed repair packages Impact Set Potentially affected terms, symbols, relations, documents, Interfaces, and workflows Owner Responsible person, role, team, or AI service Approval Policy Required authority and quorum Status Lifecycle state Audit Events Detection, review, research, approval, patch, rollback, and revalidation history 8.1 Issue lifecycle Figure 6. Consistency Issue lifecycle Detected -> Triaged -> Research Required -> Researching -> Candidate Drafted -> Under Review -> Approved / Rejected / Deferred -> Applying -> Revalidating -> Closed / Reopened / Rolled Back 8.2 Parent and child issues A root issue can own several source-specific sub-issues. For example, renaming a system component may create one parent semantic change with child tasks for Documentation, BIGFOOT, BOSS, VISOR, QUIVER, and onboarding material. Closing the root issue requires all mandatory child repairs to pass revalidation. 8.3 Impact radius The Issue Registry should calculate an impact radius through linked records. A definition change may affect documents, prompt templates, Symbol Sets, VISOR labels, saved QUIVERs, AI Skills, learning examples, and external Crosswalks. Impact does not imply all objects must change; it identifies what must be reviewed. 9. The Consistency Resolution Workspace The resolution experience can be presented as a simple interface even when the underlying graph is deep. QUIVER selects the relevant Issue, claims, evidence, linked terms, symbols, relations, prompts, and actions. VISOR arranges the authorized components into a coherent workspace. Table 11. Consistency Resolution Workspace components Workspace panel Function Issue Header Issue type, severity, status, concept, owner, version, approval policy Claim Comparison Side-by-side source claims from Documentation, BIGFOOT, BOSS, and VISOR Semantic Resolution Resolved Terms, BaseCodes, Symbol Keys, Families, Communities, and related operators Structural Context Relevant VISOR hierarchy, dependency, sequence, and interface relations Evidence and Gaps Current evidence, confidence dimensions, missing facts, and contradictions Research Prompt Builder Scoped prompts generated from the exact missing evidence Candidate Solutions Alternative repair packages with rationale and expected impact Impact Preview Records, documents, symbols, models, and Interfaces likely to change Approval Controls Approve, request changes, reject, defer, assign, or escalate Patch and Revalidation Authorized mutation actions, validation results, rollback, and audit trail 9.1 Permission-scoped display The workspace is generated from an authorized subgraph. A reviewer sees only the source records, fields, relations, evidence, and actions permitted to that reviewer. Hidden data is not loaded and then concealed; it is excluded before interface composition. This is especially important when a terminology issue crosses private personal memories, organizational policy, proprietary code, or restricted domain evidence. 9.2 Decision-oriented simplicity The primary interface should not overwhelm the reviewer with every linked record. It should first show the contradiction, why it matters, what evidence is missing, and what decisions are available. Progressive disclosure opens deeper Documentation, BIGFOOT, BOSS, and VISOR context only when needed. Figure 7. Conceptual layout of the resolution interface TOP: Issue, severity, affected concept, current status LEFT: Documentation and BIGFOOT claims RIGHT: BOSS and VISOR claims CENTER: Detected discrepancy and confidence explanation BELOW: Evidence gaps -> research prompts -> candidate repairs BOTTOM: Approval actions, patch preview, audit, revalidation 9.3 Interface actions Open canonical source record. Confirm or reject term resolution. Mark a claim as historical, illustrative, planned, or scoped exception. Request research for a specific evidence gap. Generate or edit a candidate repair. Compare candidates and inspect semantic remainders. Preview affected records and permission impact. Approve, reject, defer, escalate, or request revision. Apply authorized patch set and revalidate. 10. Research Prompt Routing When internal sources cannot resolve a discrepancy, the system creates a research task instead of guessing. The prompt is generated from the issue record, exact claims, missing evidence, permitted sources, and acceptance criteria. Table 12. Research Prompt Packet Prompt field Purpose Research Question The exact unknown that prevents resolution. Context Packet Relevant Documentation excerpts, BIGFOOT definitions, BOSS Symbol Keys, VISOR relations, versions, and scope. Competing Claims Each claim stated separately without flattening. Required Evidence Implementation test, decision record, external standard, subject-matter review, user intent, or historical source. Allowed Sources Internal Registries, connected Documentation, external primary sources, interviews, runtime tests, or designated repositories. Exclusions Sources or data the researcher may not access; interpretations that must not be assumed. Verification Criteria What would count as sufficient evidence for each candidate conclusion. Output Contract Structured findings, quotations or links where permitted, confidence, unresolved gaps, and recommended next step. Permission Scope Data and relations the research process may inspect or disclose. 10.1 Types of research prompts Table 13. Research prompt classes Research type Typical objective Internal provenance Find the decision or change event that introduced the current term or relation. Implementation verification Test which relation or operator the current prototype/runtime actually executes. Definition reconciliation Compare competing internal definitions and identify shared core and semantic remainder. External standards Verify terminology, notation, or constraints against authoritative external sources. User intent Ask the system owner or affected user which interpretation reflects intended meaning. Organizational policy Determine which approved policy, role, or governance rule controls the decision. Empirical evaluation Run observations, simulations, or tests to compare candidate models against results. 10.2 Prompt example Figure 8. Example issue-specific research prompt Research objective: Determine whether QUIVER or VISOR owns selection of applicable interface relations. Internal claims: - Documentation A states VISOR selects relations. - BIGFOOT defines QUIVER as dynamic relation selection and assembly. - BOSS binds SELECTS and SCOPES to QUIVER. - VISOR model states VISOR receives a relation set and renders it. Required evidence: 1. Current architectural decision record. 2. Prototype behavior or table ownership. 3. Most recent approved QUIVER and VISOR specifications. Output: - Best-supported ownership assignment. - Evidence for and against each claim. - Version or scope conditions. - Candidate records requiring revision. - Remaining uncertainty. 10.3 Research results are evidence, not automatic truth The research process returns findings to the Issue Registry. It may resolve the gap, narrow the candidate set, or reveal a deeper architectural question. The result is labelled by source, method, date, scope, and confidence. Approval authority decides whether it becomes part of the canonical repair. 11. Candidate Resolution Generation A candidate resolution is a synchronized proposal for restoring consistency. It should explain the root cause, state the intended canonical meaning, identify every affected source, preserve semantic remainders, and provide reversible patch instructions. Table 14. Candidate Resolution Package Candidate field Purpose Candidate ID Stable proposal identity Resolution statement Concise description of the proposed canonical meaning Root-cause hypothesis Why the discrepancy occurred Evidence basis Research and internal records supporting the proposal Documentation patch Exact sections or claims to revise BIGFOOT patch Definition, term status, alias, contrast, or link changes BOSS patch BaseCode, Symbol Key, glyph binding, operator, Family, or relation changes VISOR patch Hierarchy, dependency, sequence, bridge, or interface relation changes QUIVER impact Saved or dynamic relation sets that may render differently Version plan New versions, effective date, migration, and deprecation rules Impact set Records and users affected Risks and alternatives Potential side effects and competing candidates Rollback plan How to restore the prior canonical state Approval requirement Authority, quorum, or named owner 11.1 Candidate types Documentation-only correction: the architecture is stable; prose is wrong or stale. Terminology correction: BIGFOOT needs a revised definition, alias, status, or concept separation. Symbolic correction: BOSS mapping, operator contract, Family, or rendering is wrong. Structural correction: VISOR relation direction, containment, sequence, or dependency is wrong. Version reconciliation: all claims are valid but must be scoped to different versions. Coordinated semantic migration: several canonical sources change together because the concept itself evolved. Intentional plurality: competing meanings remain active in different Bases, Communities, lenses, or contexts and require Crosswalks rather than unification. 11.2 Multiple candidates The system should preserve alternatives when evidence does not justify one obvious repair. Candidate comparison can show semantic fit, implementation cost, backward compatibility, impact radius, evidence strength, and alignment with system principles. A rejected candidate remains in provenance so the same debate does not need to be reconstructed from memory. 11.3 Patch preview Before approval, the interface should show a redline-like preview of every proposed change. For relational changes, it should display before and after edges. For BOSS changes, it should show BaseCode and operator effects. For BIGFOOT changes, it should show definition and alias consequences. For Documentation, it should show exact affected sections. For QUIVER, it should show which generated or saved Interfaces may change. 12. User and Organizational Approval The architecture separates semantic competence from semantic authority. An AI may detect a contradiction and produce an excellent candidate. That does not grant it the right to redefine a system component, change an organizational policy term, or alter an executable operator. Table 15. Approval roles Authority Typical responsibility Personal Base owner Approves personal terminology, private models, preferences, and local BaseCodes. Term steward Approves BIGFOOT preferred terms, definitions, aliases, and deprecations. Symbology steward Approves BaseCodes, Symbol Keys, Families, operator contracts, and rendering changes. Architecture steward Approves VISOR structural relations and system-boundary changes. Documentation owner Approves publication changes and canonical explanatory text. Security or permission owner Approves changes affecting visibility, authorization, or protected data. Organizational governance body Approves high-impact, shared, regulated, or cross-team semantic changes. Implementation owner Confirms runtime and schema changes are feasible and correctly applied. 12.1 Approval policies Table 16. Approval policy patterns Policy Mechanism Use Single owner One designated authority can approve Local personal term or low-impact documentation correction Dual approval Two roles must approve Term and symbol change; architecture and implementation change Quorum A defined group threshold is required Organizational terminology or shared standard Sequential Approvals occur in a required order Research -> domain review -> security review -> publication Conditional Approval depends on impact or severity Critical changes require expanded review Time-bounded provisional Candidate becomes active for a trial period Prototype behavior or experimental operator 12.2 Approval receipt Approval should create a durable receipt containing candidate version, approver identity or role, timestamp, decision, comments, conditions, affected scope, and effective date. The receipt links to the applied patch and post-application validation results. 12.3 Rejection and deferral are informative outcomes A rejected candidate records why it failed. A deferred candidate records what evidence, implementation, or authority is still required. This prevents the system from repeatedly presenting the same unsupported repair and helps future AI distinguish a known rejected interpretation from a genuinely new proposal. 12.4 Emergency correction Critical errors affecting permissions, executable operators, or safety may allow immediate containment: pause the affected status, disable the relation, revert to the last approved version, and open an emergency issue. Permanent semantic repair still requires the normal approval and revalidation process. 13. Routing through CERBERUS, BIGFOOT, BOSS, VISOR, and QUIVER The resolution architecture is not a separate application layered above CERBERUS. It is assembled from the responsibilities of the existing system family. Table 17. System-component responsibilities Component Role in consistency resolution CERBERUS Stores and guards Registry truth, permissions, versions, issue records, evidence, and approved mutations. BIGFOOT Resolves natural language to governed terminology and documentary footprints. BOSS Resolves symbols, operators, near-semantic relations, and shared logical meaning. VISOR Supplies and validates the explicit structural map; renders the resolution workspace. QUIVER Queries the issue context and dynamically loads the relevant authorized relations, records, components, and actions. CRT Compiles linked context into scoped summaries, evidence packets, prompts, and candidate packages. Liminal Bridges Connect independent Registries or Bases without transferring ownership of their source records. THE EDIFICE Allows multiple PIECE lenses to analyze ambiguous issues and compare candidate models through DICE. 13.1 Query-to-resolution flow Figure 9. Natural-language query to governed resolution User or AI asks: "Why do these documents describe QUIVER differently?" BIGFOOT -> resolves QUIVER, VISOR, interface, relation, dynamic generation BOSS -> resolves SELECTS, LOADS, RENDERS, PRECEDES, DEPENDS-ON QUIVER -> loads linked documents, terms, symbols, models, versions, issues CERBERUS -> applies permissions and returns authorized records VISOR -> builds the comparison and resolution workspace CRT -> compiles context and evidence gaps AI -> proposes research prompts and candidate repairs Authority-> approves, rejects, or requests revision CERBERUS -> applies approved patch and triggers revalidation 13.2 Multi-lens analysis For complex disputes, several PIECEs may examine the same issue through documentation, ontology, implementation, safety, user-experience, or organizational lenses. DICE compares their predictions and recommendations against evidence. BOSS allows the lenses to exchange operators and semantic mappings without forcing identical internal ontologies. The approval interface can therefore present not only one AI answer, but a structured comparison of several scoped analyses. 13.3 Resolution as an Interface generated from the issue Because the Issue record already links claims, evidence, terms, symbols, relations, prompts, candidates, and permissions, QUIVER can assemble the exact environment needed for that issue. VISOR then renders it using approved panels and controls. The interface is custom to the problem but generated from stable building blocks. 14. Worked Examples 14.1 Ownership mismatch: QUIVER versus VISOR A document states that VISOR selects applicable Interface relations. BIGFOOT defines QUIVER as the dynamic selector and assembler of interface relation sets. BOSS binds SELECTS and SCOPES to QUIVER, while VISOR is bound to ORIENTS and RENDERS. VISOR itself states that it receives the relation set after QUIVER. Table 18. Claims in the QUIVER/VISOR mismatch Source Claim Documentation VISOR selects applicable relations and generates the interface. BIGFOOT QUIVER selects and assembles applicable, permission-scoped relations. BOSS QUIVER SELECTS/SCOPES/LOADS; VISOR ORIENTS/RENDERS. VISOR QUIVER PRECEDES VISOR; VISOR RECEIVES relation set. Classification: Operational Mismatch and Structural Mismatch. Likely outlier: Documentation. Research: confirm latest architecture decision and prototype ownership. Candidate: patch the document to state that QUIVER selects the relation set and VISOR renders it. Approval: Documentation owner plus architecture steward. Revalidation: all four sources agree. 14.2 Symbol used with the wrong Community meaning A square glyph appears in a calendar document and is interpreted as a generic container because the same glyph is also used structurally. BOSS shows that the calendar occurrence resolves to a temporal Phase Symbol in the Calendar Family, not the Structural Container Family. Classification: Symbol Meaning Mismatch. Candidate: bind the occurrence to the correct Symbol Key, add a textual fallback label, and ensure the document metadata includes the Calendar Community. No glyph redesign is required because contextual polysemy is valid when the Symbol Key is explicit. 14.3 Definition drift after a component evolves BIGFOOT defines a saved Interface as a saved relation set. Later Documentation expands QUIVER to include dynamic query-based Interface generation, but the BIGFOOT definition remains limited to saved configurations. BOSS and VISOR already reflect the broader function. Classification: Definition Mismatch and Propagation Failure. Candidate: revise the BIGFOOT definition so dynamic generation is primary and saved environments are persisted QUIVER resolutions. Update the affected Documentation passages that still imply a storage-only role. Version the term because its scope has materially expanded. 14.4 Reversed dependency in a Visual Model Documentation correctly states that a BOSS Port depends on symbol definitions and Crosswalks. A VISOR model accidentally states that Symbology depends on the BOSS Port. The mistake could alter generated interface ordering and AI explanation. Classification: Dependency Reversal. Research: inspect source tables and runtime data flow. Candidate: reverse the VISOR edge, re-render affected models, and test generated Interfaces. Severity may be Error or Critical depending on whether the relation affects executable routing. 14.5 All sources agree but reality disagrees Documentation, BIGFOOT, BOSS, and VISOR all state that a component preserves source provenance during merge. A runtime test shows provenance is lost. Internal consistency passes, but external validity fails. Classification: Implementation Defect and Unsupported Implementation Claim. The architecture opens an issue against the implementation rather than rewriting the conceptual sources. If the behavior is intentionally changed, then a coordinated semantic migration is required. This example demonstrates why triangulation must be paired with observation and testing. 14.6 Conflicting evidence with no immediate winner Two organizational groups use the same term for related but non-equivalent approval processes. Their Documentation, BIGFOOT, and BOSS records are internally consistent within each Base. Cross-Base comparison reveals a semantic difference. Classification: Intentional Plurality, not error. Candidate: preserve both terms in their owning Bases, create a Crosswalk marked near-semantic rather than exact, and document the semantic remainder. BOSS Ports can then communicate the distinction without forcing premature unification. 15. Data Model and Implementation Schema 15.1 Recommended Registries Table 19. Recommended consistency Registry set Registry Purpose Consistency Rules Machine-testable requirements, severity, source classes, and remediation policy. Semantic Claims Normalized claims extracted from each source, with type, subject, predicate, object, scope, and version. Consistency Issues Detected discrepancies and lifecycle state. Issue Evidence Internal and external findings linked to issues and claims. Evidence Gaps Explicit missing information that blocks resolution. Research Prompts Scoped tasks generated to obtain missing evidence. Research Results Structured findings, provenance, confidence, and unresolved questions. Candidate Resolutions Alternative repair packages. Candidate Patches Source-specific proposed mutations. Approvals Decisions, authority, conditions, and receipts. Revalidation Runs Post-patch tests and outcomes. Consistency Events Immutable audit history across the lifecycle. 15.2 Semantic Claim record Table 20. Semantic Claim fields Field Purpose Claim ID Stable identity Source Type / Source ID Documentation, BIGFOOT, BOSS, VISOR, implementation, or external evidence Subject NodeKey, Term, BaseCode, component, or relation endpoint Predicate DEFINES, IS-A, CONTAINS, DEPENDS-ON, PRECEDES, SELECTS, RENDERS, and so forth Object Target concept, value, state, or endpoint Claim Class Definition, identity, relation, behavior, constraint, example, status, permission Scope Base, Community, Family, audience, use case, or permission context Version Semantic and source version Canonicality Canonical, illustrative, historical, candidate, inferred Evidence Supporting records and extraction location Confidence Identity, extraction, and comparison confidence Status Active, superseded, disputed, unresolved 15.3 Airtable prototype implementation In Airtable, linked-record fields can connect each Issue to source records, terms, symbols, relations, evidence, prompts, candidates, approvals, and affected objects. Rollups can display source claims and status counts. Formula fields can create Issue Fingerprints and human-readable comparison summaries. Automations can open issues when rules fail, generate prompt fragments, update lag indicators, and trigger revalidation after an approved patch. 15.4 Production runtime implementation A dedicated runtime can normalize claims into a graph or relational store, run rule evaluation incrementally, compile permission-scoped issue contexts, and expose mutation actions through typed APIs. The conceptual model remains implementation-independent: canonical sources, claim extraction, typed discrepancies, evidence routing, candidate generation, approval, patching, and revalidation. 15.5 Status fields Table 21. Example lifecycle statuses Object Example statuses Rule Draft, Testing, Active, Paused, Deprecated Claim Active, Historical, Superseded, Disputed, Unresolved Issue Detected, Triaged, Researching, Candidate Drafted, Review, Applying, Revalidating, Closed Prompt Draft, Approved, Running, Completed, Insufficient, Cancelled Candidate Draft, Ready for Review, Approved, Rejected, Deferred, Applied, Rolled Back Patch Proposed, Authorized, Applied, Failed, Reverted 16. Governance, Security, and Failure Controls 16.1 Semantic injection An untrusted document or message could attempt to redefine an internal term, bind a misleading symbol, or assert false relations. Source type, authority, signature, permission, and canonicality must therefore be checked before a claim can influence validation or candidate generation. Untrusted text may create a claim for analysis but cannot silently become BIGFOOT, BOSS, or VISOR truth. 16.2 Permission leakage Consistency checking can reveal that a protected term, document, relationship, or count exists. The permission layer must prune unauthorized source records and derived metadata before the workspace is generated. Research prompts must not include protected excerpts or hints beyond the researcher’s scope. 16.3 Automated mutation boundaries Low-risk formatting or broken-link repairs may be eligible for pre-approved automation. Semantic definitions, operator contracts, structural relations, permissions, and organizational policy require explicit approval. The system should classify each target field by mutation risk and authority requirement. 16.4 Correlated error Several sources may agree because they were generated from the same mistaken record. The validator should preserve provenance and source independence. A Documentation paragraph generated directly from BIGFOOT is useful, but its agreement with BIGFOOT is not independent confirmation. Confidence models should record derivation relationships. 16.5 Rollback and quarantine Every approved semantic repair should preserve the prior version, approval receipt, and reverse patch. A failed revalidation can automatically quarantine the new version, restore the last stable state, and reopen the issue with the failed checks attached. 16.6 Avoiding overformalization Not every sentence requires symbolic normalization. The system should formalize terms, symbols, relations, constraints, and operations that materially affect understanding or execution while leaving expressive prose free to communicate nuance. BIGFOOT and BOSS are anchors, not replacements for human language. Safety principle AI may accelerate the path from discrepancy to evidence and from evidence to candidate. It must not collapse evidence, authority, and approval into one opaque step. 17. Operations, Metrics, and Continuous Reconciliation 17.1 Operational cadence On document creation or revision: scan terms, symbols, relations, version, and links. On BIGFOOT change: identify affected documents, symbols, models, prompts, and Interfaces. On BOSS change: identify all symbolic occurrences, operator bindings, Crosswalks, and learning assets. On VISOR change: identify affected Documentation, dependency claims, generated Interfaces, and permissions. On approved patch: run targeted checks on the impact set, then broader regression checks. On scheduled audit: scan orphaned records, stale versions, unresolved issues, and unreviewed planned components. 17.2 Metrics Table 22. Consistency operations metrics Metric Meaning Term resolution coverage Percentage of internal terms in active Documentation resolved to BIGFOOT. Symbol resolution coverage Percentage of operational symbols resolved to BOSS. Structural claim coverage Percentage of material hierarchy/dependency claims represented in VISOR. Consistency pass rate Percentage of concepts passing current rules at aligned versions. Open issues by severity Current unresolved semantic risk. Mean time to triage Speed from detection to classified ownership. Mean time to evidence Speed from research request to sufficient findings. Mean time to approval Governance throughput. Propagation completeness Percentage of approved changes reflected in all mandatory sources. Reopen rate Percentage of closed issues that fail later validation. False-positive rate Rules generating non-material discrepancies. Unresolved semantic debt Planned, deferred, or ambiguous concepts awaiting crystallization. 17.3 Consistency dashboard A dashboard can show the health of Documentation, BIGFOOT, BOSS, and VISOR by Base, Stack, Community, Family, document set, version, or owner. Users can drill from a high-level score into specific issues, then open the generated resolution workspace. 17.4 Documentation as a development instrument When the system evolves, the act of reconciling Documentation, BIGFOOT, BOSS, and VISOR exposes unclear concepts and unowned relations. Better documentation improves brainstorming; better brainstorming improves architecture; the next architectural change then generates a new consistency cycle. Documentation is therefore part of the development loop, not merely its record. 18. Future Implications 18.1 Self-explaining evolving systems Systems can evolve and diverge without becoming inexplicable when every new concept links to governed terminology, symbolic meaning, structural models, and documentary context. A forked Base can preserve its own definitions and operators while BOSS Crosswalks explain its relation to other Bases. 18.2 Semantic continuous integration The architecture resembles continuous integration for meaning. Code repositories test whether software still compiles; semantic repositories can test whether Documentation, terminology, Symbology, and structural models still agree. A failed check becomes a reviewable issue before confusion spreads into Interfaces, AI behavior, or organizational practice. 18.3 AI-supported institutional memory Approval receipts, rejected candidates, research results, and semantic migrations preserve why terminology and structures changed. Future collaborators and AI agents can inspect the decision path rather than rediscovering the same ambiguity. 18.4 Cross-Base and cross-intelligence consistency Within THE EDIFICE, different PIECEs may maintain divergent ontologies. Internal consistency can be checked inside each Base, while BOSS Ports and Crosswalks compare meanings between Bases. A difference may be an error, a version split, or legitimate cognitive divergence. The same issue architecture can preserve that distinction. 18.5 Candidate repair as a general coordination protocol The research-candidate-approval pattern extends beyond terminology. It can govern schema changes, operator evolution, permission changes, interface component contracts, educational content, organizational policies, and shared symbolic standards. The system can therefore evolve quickly without confusing proposal with authority. 18.6 A living semantic checksum As CERBERUS grows, the linked representations form a continually updated checksum across language, symbol, structure, and operation. The goal is not a frozen ontology. The goal is a living architecture capable of noticing when its explanations, terms, symbols, and relations no longer describe the same system. Final architectural principle Documentation explains what the system says. BIGFOOT governs what its words mean. BOSS governs what its symbols and operators mean. VISOR governs how its components relate. CERBERUS turns disagreement among them into evidence, research, candidate repair, approval, and renewed consistency. Appendix A. Error Detection Matrix Table A1. Error detection and default routing matrix Detection condition Issue type Sources Default action Term in Documentation; no BIGFOOT link Undefined Internal Term Documentation + BIGFOOT Create/link term; classify as public or internal Definition differs materially Definition Mismatch Documentation + BIGFOOT Check scope/version; patch or approve revised definition Alias points to distinct concepts Alias Collision BIGFOOT Split terms; add contrasts and preferred labels Deprecated term in active content Deprecated Usage Documentation + BIGFOOT Replace or mark historical Glyph has no Symbol Key Unresolved Symbol Documentation + BOSS Link or mint BaseCode Glyph uses wrong context Symbol Meaning Mismatch Documentation + BOSS Correct Community/Family binding Operator inputs/outputs conflict Operator Contract Mismatch Documentation + BOSS Research contract; patch claim or operator version Same glyph, unsafe ambiguity Glyph Collision BOSS Add disambiguation or alternate rendering Parent/child claims differ Hierarchy Mismatch Documentation + VISOR Verify canonical containment Dependency arrow reversed Dependency Reversal Documentation + VISOR Verify data/process flow Process order differs Sequence Mismatch Documentation + VISOR Inspect approved workflow/runtime Relation only appears in one source Missing Relation Documentation + VISOR Add relation or mark illustrative Sources reference different versions Version Skew All Align scope or create migration Approved change not propagated Propagation Failure All Generate impact set and synchronized patch Term has no defining document Orphaned Glossary Term BIGFOOT + Documentation Document, plan, deprecate, or archive Symbol has no explanation Undocumented Symbol BOSS + Documentation Create explanation and examples Claim lacks evidence Unsupported Claim Any + Evidence Generate research prompt Evidence remains incompatible Conflicting Evidence Any + Evidence Preserve candidates; escalate Canonical change lacks approval Approval Violation Registry + Approvals Rollback and investigate Unauthorized source appears in view Permission-Scope Leak Permissions + QUIVER/VISOR Prune before generation Appendix B. Research Prompt Templates Table B1. Reusable research prompt templates Prompt class Template Definition conflict Compare the competing definitions of [TERM] across the linked Documentation and BIGFOOT records. Identify their shared core, incompatible claims, version scope, source authority, and any semantic remainder. Return evidence and candidate reconciliation paths without selecting a canonical definition unless the evidence is decisive. Symbol conflict Resolve the occurrence [SYMBOL/OCCURRENCE] to the correct BOSS Symbol Key and BaseCode. Compare Community, Family, input/output contract, related symbols, and documented use. Identify whether the issue is wrong binding, glyph collision, outdated symbol version, or insufficient context. Structural conflict Compare the relation [A RELATION B] as described in Documentation with the current VISOR relation records and implementation evidence. Determine direction, cardinality, dependency, temporal order, and scope. List affected models and Interfaces. Version conflict Determine whether the competing claims are valid for different versions. Build a timeline of definition, symbol, and relation changes; identify effective dates and approval records; recommend alignment, migration, or version-specific Crosswalks. External validity Test the internally consistent claim [CLAIM] against observed runtime behavior, empirical results, or authoritative external sources. Separate internal consistency from external validity and identify whether the implementation or the conceptual model should change. Approval history Locate the decision records, approval receipts, and change events governing [CONCEPT]. Summarize who had authority, what was approved, what conditions applied, and whether the current sources reflect that decision. Prompt output contract Restate the exact question and scoped concepts. List sources inspected and access limitations. Present findings for each competing claim. Separate direct evidence, inference, and unresolved uncertainty. Identify affected versions, Bases, Communities, and permissions. Recommend candidate options rather than silently altering canonical records. Return links or stable IDs for every cited internal record. State what additional evidence would change the recommendation. Appendix C. Candidate and Approval Templates C.1 Candidate Resolution Summary Table C1. Candidate resolution template Field Entry Issue [Issue ID and title] Proposed canonical meaning [Concise statement] Root cause [Drift, version skew, incorrect mapping, missing relation, implementation defect, other] Evidence [Linked findings] Documentation changes [Documents and sections] BIGFOOT changes [Terms, definitions, aliases, statuses] BOSS changes [BaseCodes, Symbol Keys, Families, operator contracts] VISOR changes [Relations, models, component mappings] QUIVER impact [Dynamic and saved interface relation sets] Risks and alternatives [Summary] Rollback [Reverse patch or prior version] Required approvals [Roles/quorum] C.2 Approval Receipt Table C2. Approval receipt template Field Entry Candidate ID and version Decision Approved / Approved with Conditions / Rejected / Deferred Approver identity or role Authority basis Conditions Effective date Patch set Revalidation requirement Comments Timestamp and signature Glossary The glossary below defines the terms used in this specification. In the implemented system, each internally governed term should resolve to a BIGFOOT record and, where appropriate, to BOSS Symbology and VISOR relations. Table G1. Glossary of semantic consistency terms Term Definition Active A status indicating that a governed record is current and available for ordinary use. Agreement Source A source whose claim is compatible with other claims in a Consistency Issue. Alias An approved alternate term that resolves to a BIGFOOT preferred term. Approval Policy The authority, sequence, quorum, or conditions required before a candidate can become canonical. Approval Receipt A durable record of an approval decision, authority, conditions, effective date, and patch set. Approval Violation A canonical change made without the authority required by the target record or scope. Authorized Subgraph The components, relations, records, fields, and actions a viewer is permitted to access. Base A governed CERBERUS environment with its own records, terminology, Symbology, permissions, and versions. BaseCode A stable, Base-scoped identity assigned by BOSS to a symbolic object independently of its rendering. BIGFOOT Base Internal Glossary Facilitating Ontology-Oriented Terminology; the Liminal Bridge between Documentation and Symbology. BOSS BaseCode Operational Symbolic System; the governed system for symbolic identity, meaning, relations, and operations. BOSS Port A semantic communication boundary that resolves and exchanges BOSS meanings across systems or Bases. Candidate Patch A source-specific proposed mutation contained within a Candidate Resolution Package. Candidate Resolution A governed proposal for restoring consistency across affected sources. Canonical Approved as authoritative for the declared scope and version. Canonicality Metadata indicating whether a claim is canonical, illustrative, historical, inferred, or proposed. CERBERUS The Registry-backed architecture that stores, connects, governs, and executes the system. Claim A normalized assertion about identity, definition, relation, behavior, constraint, state, or permission. Claim Signature A normalized representation used to compare and deduplicate claims. Community A high-order BOSS domain or namespace containing related Symbol Families. Consistency Issue A first-class record representing a detected incompatibility, gap, or governance failure. Consistency Resolution Workspace The permission-scoped interface used to compare claims, research gaps, review candidates, and approve repair. Consistency Rule A machine-testable requirement that defines expected agreement or linkage among sources. Consistency State The current result of semantic validation, such as Consistent, Conflicting, Incomplete, or Version-Skewed. Crosswalk An explicit mapping between concepts or symbols in different Bases, versions, or ontologies. CRT CERBERUS Rollup Traversal; the compilation of scoped linked context into summaries, prompts, and packets. Deprecated A status indicating that a record is retained for history or compatibility but is no longer preferred. Discrepancy Pattern The distribution of agreement and conflict across compared sources. Documentation Governed narrative material explaining system concepts, purposes, relations, examples, and constraints. Documentary Footprint A linked occurrence of a BIGFOOT term within Documentation. DICE Divergent Intelligence Competition Engine; the environment that compares PIECE analyses and predictions. EDIFICE Evolutionarily Divergent Intelligence Forms Interoperating through Competitive Evaluation. Evidence Gap A specifically stated unknown that prevents reliable resolution. Evidence Hierarchy The ordered classes of evidence used to evaluate competing claims. External Validity Agreement between the system and observed reality, verified implementation, or authoritative outside evidence. Family A local BOSS semantic neighbourhood containing related symbols or operators. Glyph The visible rendering of a symbolic object; distinct from its BaseCode and contextual meaning. Glyph Collision A condition in which distinct symbolic objects render identically or confusingly without adequate context. Impact Radius The linked set of records, documents, symbols, models, Interfaces, or users potentially affected by a change. Implementation Evidence Verified behavior, code contract, schema, test, or runtime result demonstrating what the system actually does. Internal Consistency Compatibility among governed internal representations at the same scope and version. Issue Fingerprint A stable key used to deduplicate repeated detections of the same inconsistency. Liminal Bridge A record or system that connects independent Registries while preserving endpoint ownership. Near-Semantic Relation A meaningful similarity that preserves non-equivalence and semantic remainder. Ontology A structured account of entities, categories, relations, properties, and operations in a domain. Operator Contract The BOSS definition of an operator’s inputs, outputs, constraints, and behavior. Orphaned Record A governed record lacking required links, use, ownership, or documentation. Permission-Scope Leak Exposure of a record, relation, label, count, route, or inference outside authorized scope. PIECE Perspective-Indexed Experimental Cognitive Engine; an independently scoped intelligence lens. Propagation Failure Failure to reflect an approved semantic change across all mandatory linked sources. QUIVER Queryable Universal Interface Viewer Embedding Registries; dynamic selection and assembly of interface relations from Registry structure. Revalidation Re-running consistency rules after a patch to confirm the issue is resolved and no new conflicts appear. Research Prompt Packet A structured request containing the exact unknown, context, competing claims, allowed sources, and verification criteria. Research Result Evidence returned from an approved research task, with method, provenance, confidence, and unresolved gaps. Rollback Reversal to a prior approved semantic or structural state. Semantic Checksum Cross-source comparison of terminology, symbols, structure, and narrative claims for a concept. Semantic Claim A normalized, addressable assertion extracted from a governed source. Semantic Injection An attempt by untrusted content to alter or impersonate canonical meaning. Semantic Migration A coordinated, versioned change to a concept across multiple canonical sources. Semantic Remainder The meaningful difference preserved when two concepts are similar but not equivalent. Severity The operational importance of an issue: Informational, Warning, Error, or Critical. Source Claim A claim tied to its originating record, location, version, scope, and provenance. Structural Operator A BOSS operator expressing relations such as CONTAINS, DEPENDS-ON, PRECEDES, or BRIDGES. Symbol Key A stable key identifying a contextual BOSS Symbology meaning. Symbology The BOSS layer that binds symbols to contextual meaning, Families, Communities, examples, and operations. Term Steward The authority responsible for BIGFOOT terminology governance. Triangulation Comparison of independently governed representations to identify agreement, outliers, and uncertainty. Undefined Internal Term A term used internally without a BIGFOOT resolution or approved public-language exception. Version Skew A discrepancy caused by comparing claims that belong to different versions or effective periods. VISOR Visual Information System Orienting Relationships; the explicit structural map and interface-rendering system. Visual Model A human-readable representation linked to an explicit VISOR relational map. Subject Index Page references identify the principal discussions in this edition. Related concepts may also appear elsewhere through examples, tables, and the glossary. Agreement sources 7, 14 Definition mismatch 10, 23-24, 29 Permission leakage 11, 16, 26, 29 AI candidate generation 18-19 Deprecated terminology 9-11, 29 PIECE 22, 28, 34 AI communication 21-22, 28 Dependency reversal 11, 23, 29 Propagation failure 11, 23-24, 29 Aliases 9-10, 32 Detection pipeline 11-12 QUIVER 15-16, 21-24 Approval policies 19-21 DICE 22, 28, 32 Revalidation 12, 15, 21, 25-27 Approval receipts 20, 28, 31 Documentation 2-3, 5-9, 21-24 Research prompts 16-18, 24-25, 29-30 Approval violations 11, 26, 29 Documentary footprints 6, 32 Research results 17-18, 25, 28 Authorized subgraph 16, 21, 26 EDIFICE 22, 28, 32 Resolution confidence 13 BaseCode 6-7, 21, 32 Error severity 9, 14, 32 Rollback 19, 21, 26 BIGFOOT 2-3, 6-7, 21-24, 32 Error taxonomy 10-11, 29 Semantic checksum 7-8, 28 BOSS 2-3, 6-7, 21-24, 32 Evidence gaps 13, 17-18, 24-25 Semantic claim 11-12, 24-25 Candidate patches 18-19, 31 Evidence hierarchy 12-13 Semantic continuous integration 28 Candidate resolutions 18-21, 31 External validity 5, 13, 23, 28 Semantic injection 26 Canonicality 12-13, 25, 32 False positives 11 Semantic migration 19, 24, 28, 35 CERBERUS 2-3, 21-22, 24-26 Glyph collision 10, 29, 33 Semantic remainder 22, 24, 28, 30, 35 Claim extraction 11-12 Impact radius 15, 19, 25, 34 Sequence mismatch 11, 29 Claim signature 12, 14, 25, 33 Implementation evidence 13, 23-26, 34 Structural mismatch 10-11, 23, 29 Compound errors 11 Internal consistency 5-8, 23-24, 34 Structural Operators 7, 21-22, 35 Consistency dashboard 27 Issue fingerprint 12, 14, 34 Symbol meaning mismatch 10, 23, 29 Consistency Issue Registry 14-15, 24-25 Issue lifecycle 14-15 Symbol Keys 6-7, 17, 21-24 Consistency Resolution Workspace 15-16 Liminal Bridges 21, 34 Symbology 6-7, 21, 32, 35 Consistency rules 8-9, 24-25, 29 Machine-testable claims 8-9 Triangulation 7-8, 23-24, 35 Consistency states 8, 32 Metrics 26-27 Undefined terms 9-10, 29 Correlated error 26 Multi-lens analysis 22 Version alignment 12-13 Cross-Base consistency 28 Near-semantic relations 22, 24, 28, 34-35 Version skew 11-13, 23-24, 29 Crosswalks 22, 24, 28, 32 Operator contracts 7, 10, 13, 26 VISOR 2-3, 6-7, 21-24 CRT 21-22, 32 Orphaned records 11, 29, 34 Worked examples 22-24