5 - CERBERUS_Linked_Semantics_SCREEN_CALL_Formal_Specification_v1.0.docx

CERBERUS LINKED SEMANTICS SCREEN and CALL Formal System Specification Core system statement SCREEN reduces the global CERBERUS semantic graph to the finite semantic nexus relevant to the user’s present engagement. CALL exposes the exact registered correspondences inside that SCREEN without inventing, mutating, or silently broadening canonical meaning. CALL GLYPH 1:=:1 one resolved semantic object • registered correspondence • one resolved semantic object Version 1.0 | Formal Architecture Specification | 13 August 2026 Status: Foundational specification for prototype, implementation, learning, and conformance. DOCUMENT CONTROL Field Value Document CERBERUS Linked Semantics: SCREEN and CALL Version 1.0 System CERBERUS Matryoshka Primary components SCREEN — Semantic Context Resolution Engagement Evaluation Nexus; CALL — CERBERUS Active Lens Links Universal page glyphs (?) for page-local help; (1:=:1) for CALL Status Formal architecture specification Scope Semantic screening, active-context resolution, cross-page correspondence, documentation routing, Thought Rail participation, permissions, and conformance Date 13 August 2026 Abstract CERBERUS Linked Semantics defines a bounded runtime mechanism for making semantic relationships visible while a user works across records, pages, Semantic Kernels, Bit Groups, Bits, and Bitlinks. SCREEN provides the active semantic boundary and resolution. CALL provides the relation projection. Thought Rails provide continuity of cognition by determining which preserved page-like contexts are active participants and which are suspended outside the present evaluation. The system is explicitly non-generative at its canonical layer. CALL does not ask an AI to guess what two pages “seem related to.” It resolves normalized, predefined CERBERUS fields and registered semantic relations. The result is a traceable nexus that can descend from page or record context to exact SK, Bit Group, Bit, Bitlink, and bounded Bitlink path documentation. This specification also establishes the 1:=:1 glyph, six SCREEN Levels, the distinction between Active and Suspended Thought Rails, multi-page behavior, permission-first evaluation, no-link behavior, deterministic provenance, learning integration, and formal conformance requirements. Design summary GLOBAL CERBERUS SEMANTIC GRAPH | | current engagement + viewer permissions v SCREEN Semantic Context Resolution Engagement Evaluation Nexus | | SCREEN Level 0..5 v BOUNDED SCREEN NEXUS | v CALL 1:=:1 | +--> exact matches +--> Bit Group intersections +--> exact Bits +--> direct Bitlinks +--> bounded Bitlink paths +--> level-matched documentation TABLE OF CONTENTS Section Page 1. Purpose and Scope 5 2. Terminology and Normative Language 6 3. Architectural Context 6 4. CALL Glyph and Universal Page Controls 7 5. SCREEN Definition and Model 8 6. Thought Rails and Engagement 9 7. SCREEN Levels 0–5 11 8. Semantic Normalization and Selection 13 9. CALL Resolution Pipeline 14 10. Relationship Classes and Result Types 15 11. Documentation Resolution 16 12. Multi-Page and Multi-Window Cognition 17 13. FAMILIAR and Resonant Familiarity 17 14. DRAGON Learning Integration 19 15. Permission and Privacy 19 16. Non-Inference and Candidate Links 20 17. Runtime State, Performance, and Caching 21 18. Failure States and No-Link Results 22 19. Formal Laws 22 20. Conformance Requirements 24 21. Worked Examples 25 22. Implementation Checklist 26 23. Extension Points 27 Glossary 28 Subject Index 31 Reading path Sections 1–7 define the semantic contract and SCREEN Levels. Sections 8–12 define runtime resolution. Sections 13–16 integrate learning, Commons, permissions, and epistemic discipline. Sections 17–23 define implementation, conformance, examples, and extension rules. 1. Purpose and Scope This specification defines CERBERUS Linked Semantics: the combined behavior of SCREEN and CALL when a user is simultaneously engaged with one or more semantic-bearing pages, records, selections, and Thought Rails. Its purpose is to make explicit semantic relationships visible at the moment they are cognitively relevant, while keeping the global CERBERUS graph bounded, permission-safe, deterministic, and comprehensible. The system is designed for a world in which CERBERUS records may contain Semantic Kernels and related semantic records through predefined fields. Because these fields are already structured, the runtime can normalize them into selections rather than reinterpreting arbitrary prose. CALL therefore acts as a semantic resolver over declared structure, not as an unconstrained similarity engine. 1.1 In scope • Persistent page controls — the (?) help control and the (1:=:1) CALL control. • SCREEN — the bounded semantic context, resolution, engagement, evaluation, and nexus model. • SCREEN Levels — six resolution levels from record/context through bounded Bitlink path. • Thought Rails — how Active and Suspended Thought Rails enter or leave the current SCREEN. • Semantic normalization — conversion of predefined SK, Bit Group, Bit, and Bitlink fields into runtime selections. • CALL results — exact matches, group intersections, exact Bits, direct Bitlinks, bounded paths, and supporting semantic documentation. • Permissions — viewer authorization is applied before semantic resolution to prevent existence leakage. • Learning — how CALL can expose known semantic bridges and Resonant Familiarity without inventing analogies. • Conformance — behavioral requirements and tests for implementations. 1.2 Out of scope • Authoring the underlying Semantic Kernel contracts themselves. • Redefining Thought Rail persistence outside the participation semantics required by SCREEN. • Using concurrent viewing as evidence that a new canonical Bitlink should exist. • Inferring unrestricted semantic similarity from arbitrary natural language. • Replacing QUIVER/VISOR, DRAGON Learning, SK Reader, or other CERBERUS systems; CALL consumes their registered outputs and routes into their documentation where applicable. Core boundary CALL reveals registered semantics. It does not create canonical semantics merely because two things appear together on a screen. 2. Terminology and Normative Language This specification uses normative requirement terms to distinguish required behavior from recommended or optional behavior. The terms are intentionally used in the engineering sense so that CALL implementations can be tested against a stable contract. Term Meaning SHALL / MUST Required for conformance. SHALL NOT / MUST NOT Prohibited for conformance. SHOULD Recommended default; deviations require a defensible implementation reason. SHOULD NOT Normally avoided; allowed only with a defensible implementation reason. MAY Optional capability compatible with the core specification. 2.1 Foundational distinctions Concept Meaning in this specification Canonical semantic state Registered CERBERUS meaning, state, relation, or contract that exists independently of the current interface. Projection A derived representation of canonical state. SCREEN and CALL are projections, not source-of-truth registries. Engagement The subset of available workspace context currently admitted to SCREEN. Resolution The semantic granularity at which SCREEN evaluates and CALL presents relationships. Nexus The bounded intersection or bridge structure produced from engaged semantic selections. Correspondence A registered relationship, identity, containment, inheritance, or bounded path between resolved semantic objects. It does not automatically mean equivalence. 3. Architectural Context CERBERUS may contain an enormous semantic graph, but a user rarely needs the entire graph at once. Linked Semantics treats current cognition as a finite working set. Pages and Active Thought Rails contribute semantic context; SCREEN filters that context to the current resolution; CALL exposes exact relationships inside the resulting nexus. PERSISTENT CERBERUS canonical Registries, SKs, Bit Groups, Bits, Bitlinks, Models, Rules | | permission pruning v VIEWER-AUTHORIZED SEMANTIC GRAPH | | engaged pages + Active Thought Rails v SCREEN CONTEXT | | SCREEN Level v SCREEN NEXUS | | CALL resolution v 1:=:1 RESULTS + DOCUMENTATION This architecture separates durable meaning from transient cognition. Canonical CERBERUS records persist. Thought Rails preserve or suspend workspace context. SCREEN represents the present bounded cognitive evaluation. CALL is the visible linked-semantic projection of that evaluation. 3.1 System role separation Component Primary question Role (?) Help What is this page? Opens documentation for the page or interface surface itself. Thought Rails What am I keeping in mind? Preserve page-like cognitive context and determine whether it is active or suspended. SCREEN What semantic context is eligible, and at what resolution? Screens the authorized graph to a finite active nexus. CALL — 1:=:1 How does this connect to what else I am engaged with? Exposes exact registered correspondence and routes to level-matched documentation. 4. CALL Glyph and Universal Page Controls 4.1 The CALL glyph: 1:=:1 1:=:1 The CALL glyph represents one specific resolved semantic object in correspondence with another specific resolved semantic object. The two “1” operands are intentionally resolution-independent. A “1” may be a page-level record at SCREEN-0, a Semantic Kernel at SCREEN-1, a Bit Group at SCREEN-2, an exact Bit at SCREEN-3, a Bitlink at SCREEN-4, or an endpoint within a bounded path at SCREEN-5. Glyph law 1:=:1 indicates a specific registered correspondence at the active SCREEN Level. It does not specify object size, semantic granularity, relation direction, relation type, confidence, or equivalence. 4.2 Why the glyph is intentionally abstract • The glyph must remain valid as the user changes SCREEN Level. • The glyph must not imply that both sides have the same datatype or word width. • The glyph must not imply that the relationship is symmetric. Directionality is carried by the registered relation itself. • The glyph must not imply semantic identity. CALL can surface containment, inheritance, translation, contrast, causality, shared grouping, or other registered relationship types. • The glyph communicates “inspect the explicit relation,” not “these things are the same.” 4.3 Persistent page controls Control Universal meaning Documentation scope (?) Explain this page. Page-local: purpose, source, fields, interface behavior, relevant help. (1:=:1) Relate this page to the current SCREEN. Relational: SKs, Bit Groups, Bits, Bitlinks, paths, and registered linked documentation across current engagement. Every compatible CERBERUS page SHOULD expose both controls in a stable location. Their visual placement may vary by runtime, but their semantics SHALL remain stable. The (?) control resolves inward to the page. The (1:=:1) control resolves outward into the active semantic context. 5. SCREEN Definition and Model 5.1 Name and expansion SCREEN Semantic Context Resolution Engagement Evaluation Nexus SCREEN is the finite semantic boundary through which CALL operates. Its name describes both the system’s function and its ordinary-language behavior: it screens out most available information so the runtime can render the nexus points that matter to what the user is currently engaged in and evaluating. Word Formal role Semantic Only registered semantic references and authorized relation metadata enter the canonical CALL result layer. Context The current page/record selections and Active Thought Rails that define the user’s present workspace. Resolution The selected SCREEN Level, from broad record context to exact path detail. Engagement The inclusion rule determining which available contexts are currently participating. Evaluation Deterministic comparison and traversal across normalized selections. Nexus The bounded set of shared points, mappings, direct links, or allowed paths produced for CALL. 5.2 SCREEN Context versus SCREEN Nexus SCREEN CONTEXT current page(s) selected record(s) Active Thought Rails | | normalize + permission-check + resolve at Level N v SCREEN NEXUS shared semantic addresses Bit Group intersections exact Bit correspondences direct Bitlinks bounded Bitlink paths SCREEN Context is the input. SCREEN Nexus is the derived output of screening and evaluation. This distinction prevents the active workspace itself from being confused with the set of semantic connections CALL ultimately displays. 5.3 SCREEN is transient, canonical semantics are durable A SCREEN can change every time the user opens a page, changes a selection, activates or suspends a Thought Rail, changes permission context, or changes SCREEN Level. None of those actions alter the underlying Semantic Kernels or Bitlinks. SCREEN state is therefore recomputable workspace state, not a new canonical semantic registry. 6. Thought Rails and Engagement Thought Rails provide continuity of cognition across pages. Within this specification, a Thought Rail is treated as a page-like or context-bearing workspace object whose participation state determines whether its semantic selections enter SCREEN. This specification does not redefine the broader storage or lifecycle semantics of Thought Rails beyond their relationship to SCREEN. 6.1 Active Thought Rail Active Thought Rail A preserved thought context that currently contributes its authorized semantic selections to SCREEN and therefore participates in CALL evaluation. 6.2 Suspended Thought Rail Suspended Thought Rail A preserved thought context that remains available for later resumption but is excluded from current SCREEN evaluation. It behaves like a suspended page: remembered, not presently engaged. 6.3 State effect Workspace state Preserved? Included in SCREEN? Effect on CALL Current / engaged page Yes Yes Its semantic selections participate. Active Thought Rail Yes Yes Its semantic selections participate as part of current cognition. Suspended Thought Rail Yes No No CALL relationships are produced from it while suspended. Reactivated Thought Rail Yes Yes SCREEN is recomputed and newly applicable CALL results may appear. 6.4 Activation and suspension are projection changes PAGE / THOUGHT CONTEXT | +--> ACTIVE THOUGHT RAIL ----> INCLUDED IN SCREEN ----> CALL | | | +--> Suspend | v +--> SUSPENDED THOUGHT RAIL <---- EXCLUDED FROM SCREEN | +--> Reactivate ----> recompute SCREEN + CALL Activating or suspending a Thought Rail SHALL NOT create, delete, or modify canonical semantic relations. The operation changes only the set of contexts currently admitted to SCREEN. 6.5 Example: deliberate cognitive re-entry A user is reading cardiac physiology. A previously preserved Thought Rail about musical phase relationships is suspended. At that moment CALL does not compare the music material against the cardiac page. The user activates the Thought Rail. Its MUSIC timing and phase references enter SCREEN; CALL can now expose registered bridges through shared or Bitlinked phase concepts. Suspending the rail again removes those CALL results without deleting either domain or their Bitlinks. 7. SCREEN Levels 0–5 SCREEN Levels specify resolution, not truth strength. Increasing the level increases semantic granularity and explicit relational detail. It does not make a relationship “more true.” A valid SCREEN-1 Kernel-level connection may be sufficient for orientation; SCREEN-3 or SCREEN-4 may be required for exact explanation; SCREEN-5 may be required to show a bounded multi-step bridge. Level Name Primary unit Question answered SCREEN-0 Record / Context Page, record, selection, or context object Which active records or contexts are involved, and where is semantic-bearing material present? SCREEN-1 Semantic Kernel SK identity / version / family Which Semantic Kernels connect or overlap across the engaged contexts? SCREEN-2 Bit Group Declared SK Bit Group Which semantic groups create the relevant intersection? SCREEN-3 Bit Exact semantic primitive / bit address Which exact semantic primitives match, differ, or map? SCREEN-4 Bitlink Direct registered Bitlink What explicit registered relation directly connects the resolved endpoints? SCREEN-5 Bitlink Path Finite ordered path of registered links What bounded chain of registered relations connects otherwise non-adjacent endpoints? 7.1 SCREEN-0 — Record / Context SCREEN-0 is the broadest level. It retains page, record, and selected-context identity so the user can understand which active surfaces are contributing to the CALL evaluation. It is useful when a user wants orientation before descending into semantic internals. SCREEN-0 Page A: Shoulder Injury Memory 1:=:1 Page B: Tennis Serve Analysis Reason shown at this level: Both pages contain registered semantic-bearing references eligible for deeper SCREEN resolution. 7.2 SCREEN-1 — Semantic Kernel SCREEN-1 collapses record-specific detail into Semantic Kernel identity. If two active records both reference BODY-128, or one references BODY-128 and another references a prefix-compatible descendant, CALL can expose the relevant Kernel-level relationship without yet enumerating groups or bits. SCREEN-1 BODY-128 1:=:1 MOVEMENT-256 FIT-128 1:=:1 BODY-128 TIME-128 1:=:1 FIT-128 7.3 SCREEN-2 — Bit Group SCREEN-2 resolves which declared Bit Groups are responsible for the connection. Different exact Bits may still belong to a common group, and a registered group-to-group mapping can be useful before exact primitive inspection. SCREEN-2 BODY-128 :: Orientation 1:=:1 MOVEMENT-256 :: Laterality 7.4 SCREEN-3 — Bit SCREEN-3 resolves exact semantic primitives. The interface may show exact bit addresses, decoded labels, or both. This is the appropriate level for atomic explanation, debugging, conformance checks, and precise learner-facing correspondence. SCREEN-3 BODY-128:B032 [LEFT] 1:=:1 MOVEMENT-256:B071 [LEFT-LATERAL REFERENCE] 7.5 SCREEN-4 — Bitlink SCREEN-4 exposes the direct registered Bitlink that connects the resolved endpoints. The CALL glyph does not define the Bitlink’s semantics; the Bitlink record does. A direct link may be directional or bidirectional, equivalence-like or transformational, descriptive or operational, depending on its declared contract. SCREEN-4 Source: BODY-128:B032 Bitlink: BL-00218 Relation: anatomical laterality -> movement laterality Target: MOVEMENT-256:B071 CALL display: BODY-128:B032 1:=:1 MOVEMENT-256:B071 7.6 SCREEN-5 — Bitlink Path SCREEN-5 permits bounded traversal across multiple registered Bitlinks when the two active endpoints are not directly linked. Every hop remains inspectable. Automatic path search SHALL be finite and implementation-bounded. A recommended default is to prioritize the shortest low-hop paths and require explicit user action for deeper traversal. SCREEN-5 MUSIC :: Phase | | Bitlink v MATH :: Phase / Periodicity | | Bitlink v CARDIAC :: Cycle Phase No step is inferred. Each hop is a registered relation. 7.7 Minimum sufficient relation resolution Resolution rule CALL SHOULD initially present the lowest SCREEN Level that is sufficient to explain why the current contexts are linked, while allowing the user to descend to deeper registered detail on demand. This keeps CALL cognitively lightweight. A user should not receive hundreds of Bit-level edges when a single Kernel- or Group-level explanation is sufficient. Conversely, exact Bits and Bitlinks remain immediately reachable when precision is needed. 8. Semantic Normalization and Selection CALL is practical because CERBERUS semantic references are represented through predefined fields. A participating page does not need to be reread as unstructured prose. The runtime can normalize declared fields into comparable selections. 8.1 Semantic-bearing fields • Semantic Kernel identity and version. • Bit Group identity or address range. • Exact Bit or semantic primitive address. • Bitlink identity and endpoint references. • Record-to-SK bindings and current bit-word state where relevant. • Supporting Model, Model Key, Operator, Normative, Reader, or Learning Package references when exposed by the source contract. 8.2 Normalized selection shape Normalized Semantic Selection - source context: page / record / Thought Rail - source record identity - semantic object type - semantic address - SK version / contract identity - decoded label, if registered - current state/value, if relevant - relation IDs, if declared - provenance - viewer permission state The exact storage schema may vary by runtime. The required behavior is that semantically equivalent registered references normalize to the same canonical identity before CALL comparison. Runtime-local IDs SHALL NOT replace canonical semantic identity in cross-system reasoning. 8.3 Normalization does not reinterpret Normalization is a selection and identity-resolution step. It SHALL NOT silently redefine a Bit, merge different SK versions, or convert an inferred similarity into a canonical relation. If a source field is ambiguous or unresolvable, CALL must preserve that uncertainty as a failure or unresolved state rather than guessing. 9. CALL Resolution Pipeline CALL is invoked from the persistent 1:=:1 control, but its result is derived from the current SCREEN. The clicked page may act as the focus context, while the rest of the active SCREEN supplies comparison context. 1. Identify the focus page, record, selection, or CALL object context. 2. Collect currently engaged pages and Active Thought Rails. 3. Apply viewer authorization before semantic comparison or traversal. 4. Normalize predefined semantic-bearing fields into canonical selections. 5. Apply the selected SCREEN Level and collapse irrelevant lower-resolution detail. 6. Build the SCREEN Nexus from exact intersections and eligible registered relations. 7. Resolve CALL results, prioritizing direct and lower-complexity explanations before deeper bounded paths. 8. Attach provenance and resolution-matched documentation targets. 9. Render the CALL projection without mutating canonical semantic state. FOCUS + ENGAGED CONTEXTS | v PERMISSION PRUNING | v SEMANTIC NORMALIZATION | v SCREEN LEVEL RESOLUTION | v SCREEN NEXUS | v CALL RESULTS | +--> relation type +--> endpoints +--> exact provenance +--> documentation +--> optional learning context 9.1 Focused versus all-context evaluation A CALL invocation from a page SHOULD default to focused evaluation: “How does this page relate to my current SCREEN?” A runtime MAY also provide an all-context mode that displays relationships among every engaged context. The distinction is a projection preference, not a change to underlying semantics. 10. Relationship Classes and Result Types The CALL glyph is intentionally relation-neutral, so every displayed result must expose its actual registered relation class. Implementations should avoid collapsing all results into the word “match.” Class Description Typical SCREEN Level Identity match The same canonical semantic address is present in multiple engaged contexts. 1–3 Prefix / inheritance relation One semantic object preserves or extends a lower-resolution prefix or declared inherited contract. 1–3 Group intersection Different semantic primitives resolve within the same declared Bit Group or mapped groups. 2 Exact primitive correspondence Two exact Bits are identical or explicitly mapped. 3 Direct Bitlink A registered Bitlink directly connects the endpoints. 4 Bounded Bitlink path A finite ordered chain of registered Bitlinks connects the endpoints. 5 Supporting Model relation A shared or linked Model explains or computes the relationship. Supporting metadata Supporting Operator relation The objects participate in a shared or linked Operator/action structure. Supporting metadata Supporting Normative relation The objects are governed by the same or linked Rules/Normatives. Supporting metadata 10.1 Correspondence is not equivalence A CALL result may mean “same semantic primitive,” but it may also mean “specializes,” “depends on,” “is transformed by,” “contrasts with,” “is governed by,” “translates to,” “inherits,” or another registered relation. CALL SHALL display enough relation metadata to prevent the 1:=:1 glyph from being misread as mathematical equality. 10.2 Result grouping When many primitive-level results exist, CALL SHOULD group them by the lowest meaningful common structure: SK, Bit Group, relation class, or path family. The interface may show a count badge, but the count SHOULD represent grouped findings rather than raw edge volume when raw volume would be cognitively misleading. 11. Documentation Resolution Linked Semantics is not complete if CALL only states that two contexts are related. The user must be able to inspect why. CALL therefore routes to documentation at the same semantic resolution as the displayed relationship. SCREEN Level Primary documentation target 0 Page or record documentation; source fields; interface purpose. 1 Semantic Kernel specification, Reader overview, version and contract identity. 2 Bit Group definition, range, rationale, labels, and group-level Models. 3 Exact Bit / primitive definition, decode rule, examples, and relevant state meaning. 4 Bitlink contract, endpoints, relation type, directionality, provenance, and supporting evidence. 5 Ordered path with each hop independently inspectable; path explanation must not erase hop-level provenance. 11.1 Help and CALL remain distinct (?) "What is this page?" | v PAGE DOCUMENTATION (1:=:1) "How does this page connect to my SCREEN?" | v RELATIONAL DOCUMENTATION SK -> Bit Group -> Bit -> Bitlink -> Path The question-mark control SHOULD not become a substitute for CALL. It explains the local surface. CALL explains semantic relation across the active context. The two controls can cross-link where useful, but their responsibilities remain separate. 12. Multi-Page and Multi-Window Cognition CALL is explicitly designed for concurrent context. When several pages are open or several Thought Rails are active, the user is effectively assembling a temporary cognitive workspace. SCREEN converts that workspace into a bounded semantic context; CALL shows the registered structure among the engaged parts. Open / engaged page A ---- Open / engaged page B -----+ Selected record C ---------+--> SCREEN --> CALL Active Thought Rail D -----+ Suspended Thought Rail E --X excluded 12.1 Cognitive meaning of opening context In a CALL-enabled workspace, bringing another page into engagement is semantically meaningful: the user is adding it to the set of things currently being considered. This does not mean every open interface everywhere must automatically participate. The runtime must expose a clear, stable rule for what counts as engaged, and Thought Rail state must remain authoritative where a context has been explicitly suspended or activated. 12.2 Context reduction If a workspace contains many open pages, SCREEN SHOULD collapse irrelevant pages before CALL displays results. The user may reduce context by suspending Thought Rails, closing pages, changing focus, or lowering SCREEN resolution. The system’s goal is not to maximize visible connections; it is to expose the minimum useful nexus for the present evaluation. 13. FAMILIAR and Resonant Familiarity FAMILIAR describes the network-scale condition under which freely available semantic material is widely reused, increasingly Bitlinked, and therefore more likely to produce meaningful cross-domain bridges. SCREEN and CALL are the runtime mechanisms that make those bridges visible in a user’s immediate cognitive context. Relationship of the principles FAMILIAR creates the conditions for rich semantic resonance across the Commons. SCREEN screens that large network to the present engagement. CALL exposes the relevant registered correspondences. FREELY AVAILABLE SKs + ASSETS | v WIDESPREAD REUSE OF SHARED PRIMITIVES | v MORE BITLINKS ACROSS DOMAINS | v LARGE INTERLINKED COMMONS | v SCREEN filters to present cognition | v CALL exposes Resonant Familiarity 13.1 Why network density matters A single person can notice personal analogies, but a sparse network leaves those connections dependent on happenstance. When many freely reusable SKs, Models, Learning Packages, and Bitlinks exist, the same semantic primitive can be mapped by many people into different disciplines and applications. CALL can then surface connections that the current user did not personally author. 13.2 Transferable mastery If a person is a Master in one domain and that domain’s SKs are widely reused, their mastered primitives acquire a growing external neighborhood of registered links. When the person later approaches an adjacent domain, CALL can expose which parts are genuinely novel and which are already connected to structures they understand. The subject may be new while portions of its structure are already familiar. NEW DOMAIN CONCEPT Status: Not yet learned CALL bridges: - known primitive A -> direct Bitlink - known Model B -> shared relation - mastered Group C -> mapped Group Result: Novel domain, partially familiar structure. 14. DRAGON Learning Integration CALL can become a powerful educational projection when learner-specific state is available. The semantic relationship remains canonical; the teaching route becomes personalized. DRAGON Learning may use CALL results to prefer explicit bridges into concepts already demonstrated by the learner. 14.1 Explain through familiar links Learning target: BIO-X CALL finds: MATH-A -> Master MUSIC-B -> Advanced BODY-C -> Familiar CHEM-D -> Not Read DRAGON Learning may prioritize: BIO-X <- MATH-A BIO-X <- MUSIC-B BIO-X <- BODY-C The system does not invent an analogy; it follows registered links. Learner state SHALL remain separate from canonical semantic meaning. CALL can say that a target is linked to a concept the learner has mastered, but the underlying Bitlink exists independently of that learner. Personal status changes presentation and routing, not the semantic contract. 14.2 Learning evidence A CALL interaction MAY become part of a learning workflow—for example, opening a Bit-level explanation, following a Bitlink, completing a comparison exercise, or demonstrating transfer. Such events may produce learning evidence through DRAGON Learning, but CALL itself does not promote learner status merely because a link was viewed. 15. Permission and Privacy CALL must be permission-first. A semantic relationship can leak information even when the underlying data is hidden. Therefore the viewer-authorized graph must be established before SCREEN or CALL determines which semantic objects, intersections, or links exist for that viewer. Permission precedence Unauthorized semantic objects and relations are pruned before CALL resolution. CALL SHALL NOT reveal that a restricted relationship exists and then merely hide its details. GLOBAL GRAPH | v PERMISSION PRUNING | v VIEWER-AUTHORIZED GRAPH | v SCREEN | v CALL 15.1 Consent-scoped contexts Where CERBERUS is used in business, healthcare, education, or other consent-sensitive systems, a page may expose only semantic results authorized for the current purpose. CALL must operate on that same bounded view. A business receiving a compatibility result must not gain additional semantic knowledge merely because the user has related private records elsewhere in CERBERUS. 15.2 Permission changes If permissions change while a CALL panel is open, the SCREEN SHALL be recomputed. Cached CALL results must not survive beyond the authorization state that produced them. 16. Non-Inference and Candidate Links One of CALL’s strongest properties is epistemic discipline. Concurrent viewing does not create a semantic relation. A model’s impression that two concepts are similar does not create a Bitlink. CALL canonical results are constrained to registered identities, declared group structures, prefix relations, registered Bitlinks, and finite registered paths. 16.1 Canonical CALL result A canonical CALL result must be traceable to exact registered objects and relations. If that provenance cannot be produced, the result cannot be represented as a canonical CALL connection. 16.2 Candidate relationship workflow An implementation MAY offer a separate research action such as “Investigate possible link.” This workflow must be visually and semantically distinct from CALL results. If investigation produces a validated Bitlink through the appropriate authoring and review process, future CALL evaluations may then surface it canonically. No registered CALL path | +--> show "No registered relationship found" | +--> optional: Investigate possible link | v Candidate relation | research / review | v Registered Bitlink | v future CALL result 17. Runtime State, Performance, and Caching CALL should feel immediate even when the global semantic graph is large. The architecture supports this because SCREEN begins from a small engaged context, semantic fields are normalized, and traversal is bounded by SCREEN Level and permission scope. 17.1 Recommended runtime state State element Purpose Focus context The page, record, or object from which CALL was invoked. Engaged contexts Current pages, selections, and Active Thought Rails admitted to SCREEN. SCREEN Level Current resolution 0–5. Normalized selections Canonical semantic references extracted from engaged contexts. SCREEN Nexus Derived intersections and eligible relations at current resolution. CALL projection Grouped, ordered, user-visible relation results and documentation links. Authorization context Viewer, purpose, consent, role, and other applicable permission state. 17.2 Cache rules • Normalized selections MAY be cached while their source record, semantic contract, and permission state remain unchanged. • SCREEN Nexus results MAY be cached by engagement set + SCREEN Level + semantic version + authorization context. • CALL path caches SHALL be invalidated when any hop, version, permission, or relevant relation changes. • Cached results SHALL never be treated as canonical ownership; they are disposable projections. 17.3 Bounded traversal SCREEN-5 path resolution is the primary place where uncontrolled graph expansion could occur. Implementations SHALL impose finite traversal bounds and SHOULD rank short, direct, high-provenance paths before longer paths. The user may request deeper exploration, but every requested traversal remains finite. 18. Failure States and No-Link Results CALL must be able to say “I do not have a registered connection” without converting absence into either a false claim of unrelatedness or a hallucinated bridge. Failure states are therefore first-class outputs. State Meaning Required behavior No engaged comparison context Only one eligible semantic context is active or no comparison target exists. Explain that CALL needs another engaged context or an object-neighborhood request. No registered link Eligible contexts exist, but no relation is found within the selected SCREEN Level / bound. State absence of registered linkage, not absence of possible conceptual relation. Unresolved semantic field A source field cannot be mapped to a canonical semantic identity. Flag unresolved field; do not guess. Version conflict Two references cannot be safely reconciled under declared version rules. Expose version mismatch and relevant documentation. Permission-pruned result A potential relation falls outside authorization. Do not reveal the relation or its existence. Path bound reached A deeper registered path may exist beyond current traversal limit. State bound reached; allow explicit deeper search if permitted. 18.1 Absence integrity Absence integrity “No registered relationship found” means exactly that: no eligible registered relationship was found under the current SCREEN, permissions, versions, and traversal bound. It is not a claim that no relationship could ever be discovered or authored. 19. Formal Laws Law 1 — Canonical Relation Law CALL SHALL represent as canonical only relationships resolvable from registered semantic identity, declared structure, registered Bitlinks, or finite registered paths. Law 2 — SCREEN Boundedness Law Every CALL evaluation SHALL operate over a finite SCREEN Context and produce a finite SCREEN Nexus. Law 3 — Engagement Law Only contexts currently defined as engaged may contribute to SCREEN. Suspended Thought Rails SHALL remain excluded until reactivated. Law 4 — Resolution Law SCREEN Level SHALL control semantic granularity without changing canonical meaning. Law 5 — Non-Mutation Law SCREEN and CALL SHALL NOT mutate canonical records, SKs, Bits, Bitlinks, Models, Rules, or learning state merely by viewing or traversing them. Law 6 — Permission Precedence Law Authorization SHALL be applied before SCREEN evaluation and CALL traversal. Law 7 — Provenance Law Every canonical CALL result SHALL be traceable to exact source contexts, semantic addresses, versions, and registered relation provenance. Law 8 — Glyph Neutrality Law The glyph 1:=:1 SHALL indicate correspondence without independently asserting equivalence, symmetry, direction, datatype, word size, or resolution. Law 9 — Thought Rail Participation Law Activation SHALL add a Thought Rail’s eligible semantic context to SCREEN; suspension SHALL remove it from SCREEN without deleting the preserved Thought Rail context. Law 10 — Minimum Sufficient Resolution Law CALL SHOULD present the lowest semantic resolution sufficient to explain a connection and allow deeper resolution on demand. Law 11 — Bounded Path Law Automatic path resolution SHALL remain finite. Every displayed hop SHALL be individually registered and inspectable. Law 12 — Documentation Traceability Law CALL SHALL route to documentation appropriate to the resolution at which a relation is displayed. Law 13 — Absence Integrity Law Failure to find a registered relation SHALL be represented as absence under the current constraints, not as proof of conceptual unrelatedness. Law 14 — Projection Law SCREEN Context, SCREEN Nexus, and CALL displays are derived projections and SHALL NOT become competing canonical truth stores. 20. Conformance Requirements An implementation is conforming only if the behaviors below can be demonstrated against known fixtures. Conformance is behavioral; a runtime may use different internal technologies provided the observable semantics remain equivalent. ID Requirement C-01 Every compatible page exposes a persistent or immediately stable CALL control using the 1:=:1 glyph or an accessible equivalent label tied to the same semantics. C-02 Every compatible page exposes page-local help distinct from CALL relational help. C-03 Changing SCREEN Level changes projection resolution without changing canonical semantic state. C-04 The same exact semantic address present in two engaged contexts can be surfaced at the appropriate SCREEN Level. C-05 Two different Bits in a declared common Bit Group can be represented as a group-level intersection at SCREEN-2 without being mislabeled as identical Bits. C-06 A direct registered Bitlink can be inspected at SCREEN-4 with exact endpoints and relation metadata. C-07 A bounded multi-hop path can be inspected at SCREEN-5, with every hop individually traceable. C-08 Suspending an Active Thought Rail removes its semantic context from SCREEN and updates CALL results. C-09 Reactivating a Suspended Thought Rail restores its eligible context and recomputes CALL. C-10 Unauthorized objects and relations do not appear as CALL results or existence hints. C-11 Concurrent viewing does not create a new canonical relation. C-12 Unresolved or ambiguous semantic fields are surfaced as unresolved rather than guessed. C-13 No-link states explicitly distinguish “no registered relationship found” from “no relationship could exist.” C-14 CALL results provide level-appropriate documentation routing. C-15 Cached results invalidate when relevant semantic version, relation, engagement, or permission state changes. 20.1 Example conformance fixture Fixture: Page A -> BODY-128:B032 Page B -> MOVEMENT-256:B071 Registered Bitlink BL-00218 connects them. Thought Rail C -> MUSIC::Phase, initially Suspended. Expected: SCREEN-3: A and B exact primitives are visible. SCREEN-4: BL-00218 is visible with provenance. C suspended: no MUSIC-derived CALL results. C activated: MUSIC-derived results recompute. No canonical relation is created by the test itself. 21. Worked Examples 21.1 Example A — BODY, FIT, and movement analysis A user opens a training record containing FIT-128, a movement analysis page containing MOVEMENT semantic references, and a BODY anatomy page. SCREEN-1 first shows the Kernel-level intersections. Descending to SCREEN-2 identifies the relevant body region and movement groups. SCREEN-3 reveals exact laterality or structure Bits. SCREEN-4 shows direct registered Bitlinks from exercise/movement semantics to anatomical semantics. The user can open the associated BODY Reader or Learning Package without leaving the CALL relation context. SCREEN-1 FIT-128 1:=:1 MOVEMENT MOVEMENT 1:=:1 BODY-128 SCREEN-2 MOVEMENT::Laterality 1:=:1 BODY-128::Orientation SCREEN-3 MOVEMENT:B071 1:=:1 BODY-128:B032 SCREEN-4 BL-00218 explains the exact mapping. 21.2 Example B — MORSE timing and music rhythm A learner has MORSE-64 timing documentation open while reviewing a MUSIC rhythm page. CALL can surface a registered duration mapping. The learner does not receive a vague statement that “Morse is like music.” Instead, the exact MORSE Unit Duration group and the registered music duration or rhythmic timing concept are exposed, along with the Bitlink and each domain’s own documentation. MORSE-64 :: Unit Duration 1:=:1 MUSIC :: Rhythmic Duration CALL action: [Open MORSE group] [Open MUSIC group] [Open Bitlink] 21.3 Example C — Active Thought Rail creates a cognitive bridge The user is reading cardiac cycle material. A Thought Rail about musical phase is Suspended, so its semantic context does not enter SCREEN. The user reactivates it. SCREEN now contains both domains. At SCREEN-5, CALL can expose a registered path through a mathematical phase/periodicity Kernel if such links have been authored. Before activation: CARDIAC page -> SCREEN MUSIC Thought Rail [Suspended] -> excluded CALL: no music bridge After activation: CARDIAC page ---------+ MUSIC Thought Rail ---+--> SCREEN-5 | v MUSIC::Phase -> MATH::Phase -> CARDIAC::Cycle Phase 21.4 Example D — Suspending context reduces cognitive noise A user has several research pages open, but only three are relevant to the immediate question. Rather than allowing every preserved page to flood CALL with relations, the user suspends two Thought Rails. The SCREEN Context shrinks immediately. The removed pages remain preserved for later reactivation, while CALL now renders a smaller nexus appropriate to the current evaluation. 21.5 Example E — No-link result Two pages contain valid semantic references, but no direct link or bounded path exists under the selected SCREEN Level. CALL displays “No registered relationship found within the current SCREEN-5 traversal bound.” It may offer a deeper permitted search or an “Investigate possible link” workflow, but it does not manufacture an analogy. 21.6 Example F — Permission-pruned business context A user’s private graph contains detailed records that can determine whether a product satisfies an accessibility or compatibility constraint. The business page receives only the authorized semantic result required for the interaction. CALL operates on the business-visible semantic surface and cannot expose hidden private Bitlinks simply because those records exist elsewhere in the user’s graph. 22. Implementation Checklist Area Checklist Universal controls (?) and (1:=:1) are available, stable, keyboard-accessible, and explained by accessible labels/tooltips. SCREEN state Runtime tracks focus, engaged pages, Active Thought Rails, Suspended Thought Rails, SCREEN Level, and authorization context. Normalization Predefined semantic fields resolve to canonical semantic selections and version identities. Permissions Unauthorized subgraphs are removed before intersection or traversal. Level resolution 0–5 produce the documented semantic granularity and do not mutate source data. CALL grouping Results are grouped at minimum sufficient resolution and expose exact relation type. Documentation Each result routes to level-matched page/SK/group/bit/Bitlink/path documentation. Thought Rails Activation and suspension deterministically add/remove context from SCREEN. No-link states Absence is explicit; ambiguous or unresolved fields are never guessed. Path bounds SCREEN-5 is finite and every hop is inspectable. Caching Caches are scoped to version, permissions, engagement, and resolution and invalidate correctly. Learning integration Personal learner state can affect presentation without altering canonical semantic links. Auditability A debugger can reconstruct why a CALL result appeared from source records through normalized selections and relation provenance. 22.1 Recommended first prototype 1. Add persistent (?) and 1:=:1 controls to a small set of pages. 2. Normalize only SK, Bit Group, Bit, and Bitlink fields for the first vertical slice. 3. Implement SCREEN Levels 0–4 before multi-hop SCREEN-5. 4. Use two or three known domains with registered links, such as BODY, FIT/movement, MORSE, or music. 5. Implement Active and Suspended Thought Rail participation before broad multi-window automation. 6. Add provenance/debug display early so every CALL result can be inspected while the logic is still small. 7. Add SCREEN-5 bounded path traversal after direct relation behavior is stable. 8. Only then add learner-state ranking, FAMILIAR-aware presentation, or candidate-link research workflows. 23. Extension Points The core SCREEN/CALL contract is deliberately small. Future capabilities may extend the projection while preserving the laws in this specification. • CALL Object Mode — resolve the registered neighborhood of one selected semantic object even when no second page is active. • CALL Comparison Mode — compare all engaged contexts rather than focusing on the page from which CALL was invoked. • Learning Lens — rank CALL bridges by learner status, prerequisite satisfaction, or demonstrated familiarity. • Research Lens — show high-value candidate gaps where no registered Bitlink currently exists, clearly separated from canonical results. • FASK Lens — display where a fantasy or alternate-rules branch preserves, changes, or translates canonical semantic relations. • Cross-runtime CALL — allow compatible runtimes to exchange bounded CALL-ready semantic selections without exposing unrelated source data. • Accessibility projections — render the same CALL result through text, graph, audio, haptic, or simplified presentation while retaining identical semantic provenance. Extension invariant New CALL presentations may add capability, but they must not weaken permission precedence, provenance, bounded traversal, non-inference, or the separation between canonical semantics and projection. Glossary Term Definition 1:=:1 CALL glyph indicating a specific registered correspondence between one resolved semantic object and another at the active SCREEN Level. It is neutral regarding size, datatype, equivalence, symmetry, direction, and granularity. Active Thought Rail A preserved thought context currently admitted to SCREEN and therefore participating in CALL evaluation. Bit An exact semantic primitive or coordinate defined by a Semantic Kernel contract. Bit Group A declared grouping of Bits within a Semantic Kernel that share a bounded semantic function or interpretation. Bitlink A first-class registered semantic relation connecting explicit semantic endpoints, with its own type, directionality, provenance, and documentation as applicable. Bitlink Path A finite ordered traversal across two or more registered Bitlinks. Bounded Traversal A finite relation search constrained by explicit limits such as SCREEN Level, hop count, permissions, or user-requested scope. CALL CERBERUS Active Lens Links. The runtime projection that exposes exact registered semantic correspondences inside the current SCREEN. CALL Result A user-visible resolved relationship, intersection, exact match, Bitlink, or bounded path produced from the SCREEN Nexus. Canonical Semantic State Registered meaning, state, contract, or relation that exists independently of the current interface projection. Candidate Link A possible relationship proposed for investigation but not yet registered as a canonical Bitlink. Correspondence A registered semantic relationship between resolved objects. Correspondence does not by itself imply equivalence. Engagement The workspace participation condition that determines which pages, records, selections, and Thought Rails enter SCREEN. FAMILIAR A CERBERUS principle describing how freely available semantic material increases reuse, cross-domain linking, and the likelihood of Resonant Familiarity as the Commons becomes densely interconnected. Focus Context The page, record, selection, or semantic object from which CALL is invoked or around which results are organized. Minimum Sufficient Relation Resolution The principle that CALL should initially display the lowest SCREEN Level sufficient to explain the relationship, while permitting deeper resolution on demand. Normalized Semantic Selection A runtime-resolved canonical semantic reference derived from predefined fields in an engaged context. Nexus A bounded set of semantic intersections, mappings, direct links, or paths relevant to current SCREEN evaluation. Permission Precedence The rule that viewer authorization is applied before SCREEN or CALL determines the existence of eligible semantic relationships. Projection A derived, disposable representation of canonical semantic state. SCREEN and CALL are projections. Resonant Familiarity Partial legibility of a new concept because registered connections link it to semantic structures the learner already understands. SCREEN Semantic Context Resolution Engagement Evaluation Nexus. The bounded active semantic working context and resolution mechanism through which CALL operates. SCREEN Context The engaged, authorized semantic input set contributed by current pages, records, selections, and Active Thought Rails. SCREEN Level One of six resolution levels, SCREEN-0 through SCREEN-5, controlling the granularity of CALL evaluation. SCREEN Nexus The finite derived set of relevant semantic intersection points and eligible relationships produced from the SCREEN Context. SCREEN-0 Record / Context resolution: active pages, records, or context objects. SCREEN-1 Semantic Kernel resolution: SK identities and declared Kernel relationships. SCREEN-2 Bit Group resolution: declared group-level semantic intersections or mappings. SCREEN-3 Bit resolution: exact semantic primitives or bit addresses. SCREEN-4 Bitlink resolution: direct registered semantic relations between resolved endpoints. SCREEN-5 Bitlink Path resolution: finite ordered traversal across registered links. Semantic Kernel (SK) A bounded formal contract that defines the meaning and organization of semantic state, including exact addresses and group structure. Suspended Thought Rail A preserved thought context intentionally excluded from current SCREEN evaluation until reactivated. Thought Rail A CERBERUS cognitive continuity mechanism that preserves page-like context. Its Active or Suspended state determines whether it participates in SCREEN. Universal Page Controls Persistent controls that provide page-local help (?) and relational CALL access (1:=:1) across compatible pages. Compact reference Element Meaning Participation / action (?) Explain this page Routes to page-local documentation. 1:=:1 Relate this page to the current SCREEN Opens CALL at the active SCREEN Level. Active Thought Rail Preserved and engaged Included in SCREEN and CALL evaluation. Suspended Thought Rail Preserved but not engaged Excluded until reactivated. SCREEN-0..5 Resolution ladder Context -> SK -> Bit Group -> Bit -> Bitlink -> bounded path. Compact invariant SCREEN determines what is in the present semantic field. CALL reveals how that field is explicitly connected. Thought Rails change participation; they do not rewrite semantic truth. Subject Index Page references below identify substantive occurrences in the specification body. The index intentionally favors architectural concepts, formal laws, runtime behavior, and user-facing interaction terms. Topic Pages 1:=:1 5, 7, 8, 11, 12, 13, 14, 16, … Active Thought Rail 7, 9, 10, 14, 17, 21, 24, 25, … Absence Integrity 22, 23 Bit 5, 6, 7, 8, 9, 11, 12, 13, … Bit Group 5, 6, 7, 8, 9, 11, 12, 13, … Bitlink 5, 6, 7, 8, 9, 11, 12, 13, … Bitlink Path 5, 9, 11, 13, 15 Bounded Traversal 13, 21 CALL 5, 6, 7, 8, 9, 10, 11, 12, … CALL Glyph 7, 15 CALL Result 5, 9, 10, 11, 14, 15, 16, 19, … Candidate Link 20 Canonical Semantic State 6, 14, 24 Conformance 5, 6, 12, 24 Correspondence 6, 7, 8, 9, 12, 15, 16, 18, … Documentation Resolution 16 DRAGON Learning 5, 19 Engagement 5, 6, 8, 9, 17, 18, 21, 23, … FAMILIAR 5, 17, 18, 19, 27 Focus Context 14, 21 Help 5, 7, 8, 16, 24 Identity match 15 Learning Lens 27 Minimum Sufficient Relation Resolution 13 Multi-Page 17 Nexus 5, 6, 7, 8, 9, 14, 15, 17, … Non-Inference 20 Normalized Semantic Selection 14 Permission Precedence 19, 23 Projection 6, 7, 10, 14, 15, 19, 21, 24, … Resonant Familiarity 5, 17, 18 SCREEN 5, 6, 7, 8, 9, 10, 11, 12, … SCREEN Context 7, 9, 22, 24, 26 SCREEN Level 5, 7, 8, 9, 11, 13, 14, 15, … SCREEN Nexus 7, 9, 14, 15, 21, 24 SCREEN-0 7, 11 SCREEN-1 7, 11, 12, 25 SCREEN-2 7, 11, 12, 24, 25 SCREEN-3 7, 11, 12, 25 SCREEN-4 7, 11, 12, 24, 25 SCREEN-5 7, 11, 13, 21, 24, 26, 27 Semantic Kernel 5, 7, 9, 11, 12, 13, 16 Semantic Normalization 5, 13, 15 Suspended Thought Rail 5, 10, 17, 23, 24, 26, 27 Thought Rail 5, 7, 9, 10, 11, 14, 17, 21, … Universal Page Controls 7 Version conflict 22 Viewer authorization 5, 14 SCREEN determines what is in the present semantic field. • CALL reveals how the field is explicitly connected.