CERBERUS SEMANTIC BITWORD NOTATION AND EXTENSION GRAMMAR Formal System Specification CORE SYSTEM PROPOSITION Semantic complexity grows without migration by combining four distinct mechanisms: Pure Prefix Extension, Compound Composition, Canonical Bitlink Extension, and Namespaced Custom Bitlink Extension. Bitword width bounds encoded state; explicit graph routes bound how deeply additional meaning may be resolved. PURE PREFIX-### • COMPOUND [PREFIX]-### BITLINK ⇄ • EXTEND ↳ • CUSTOM EXTEND ↳{NAMESPACE} Version 2.0 | 13 August 2026 Supersedes Semantic Bitword Notation Formal System Specification v1.0 FRONT MATTER Document Control Field Value Document title CERBERUS Semantic Bitword Notation and Extension Grammar — Formal System Specification Short title Bitword Notation & Extension Grammar Version 2.0 Date 13 August 2026 Status Formal system specification / architectural reference Supersedes Semantic Bitword Notation Formal System Specification v1.0 Primary scope Notation, decomposition, composition, Bitlinking, semantic extension routing, custom namespaced extension, validation, and conformance Normative Language The terms MUST, MUST NOT, SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY, and OPTIONAL are used normatively. MUST and SHALL identify conformance requirements. SHOULD identifies a strong default that may be departed from only for a documented reason. MAY identifies permitted but non-required behavior. Version 2.0 Change Summary Adds Canonical Bitlink Extension notation using ↳ for directed deeper semantic resolution without changing source Bitword width. Adds Custom Bitlink Extension notation using ↳{NAMESPACE} for private, organizational, community, FRINGE, FASK, project, or other governed extension bindings. Adds Extension Route Bits, Custom Extension Route Bits, Extension Routing States, explicit route-state activation, and route-availability semantics. Adds branching extension notation ↳* and recursive extension-chain notation for arbitrarily deep but finite traversals. Formalizes the distinction between containment topology, relationship topology, extension topology, and authorization topology. Adds Custom Extension Isolation, Width-versus-Depth, and Bitlinkability-does-not-imply-disclosure principles. Adds detailed HEALTH_DATA, CARDIAC, private custom, FRINGE, and FASK extension examples. EXECUTIVE SUMMARY CERBERUS Semantic Bitwords are bounded binary semantic structures intended to remain stable, inspectable, composable, and reusable across many applications. Version 1.0 established notation for Pure Bitwords, Compound Bitwords, composition trees, exact Bit addressing, explicit Bitlinks, Statebound Bitlinks, and semantic projection. Version 2.0 adds a formal extension grammar that allows a small Bitword to route into arbitrarily detailed semantic structures without embedding those structures into its own payload. The extension grammar is built around a simple distinction. Composition answers “what is this object made from?” A Bitlink answers “what is explicitly related?” A Bitlink Extension answers “where should semantic resolution continue?” A Custom Bitlink Extension answers the same question while placing authority for the binding inside a declared namespace rather than the canonical source specification. FOUR OPERATORS TO TEACH FIRST || means “made from.” ⇄ means “related to.” ↳ means “resolve deeper through.” ↳{NS} means “resolve deeper through a namespaced extension.” This architecture allows a compact root word such as HEALTH_DATA-128 to remain small while explicitly routing to [CARDIAC]-512, HEALTH_DATA_OTHER-64, a private recovery SK, an organizational proprietary SK, a FRINGE experimental SK, or a FASK fantasy structure. The source word remains unchanged; the target owns its own semantics; permissions determine whether a given runtime may traverse or evaluate the route. CONTENTS Ref. Section 1 Purpose, Scope, and Design Objectives 2 Semantic Growth Model 3 Foundational Terminology 4 Notation Lexicon 5 Pure Bitwords 6 Compound Bitwords 7 Composition Models and Width Accounting 8 Recursive Composition Trees 9 Bit Addressing and Semantic Paths 10 Repeated Constituents and Matrices 11 Projection and Constituent Extraction 12 Bit Identity and Explicit Bitlinks 13 State Changes and Statebound Bitlinks 14 Bitlink Graphs Across Compound Trees 15 Pure Extension and Compound Expansion 16 Canonical Bitlink Extensions 17 Extension Route Bits and Extension Routing States 18 Custom Bitlink Extensions and Namespaces 19 Branching and Recursive Extension Chains 20 Implicit Registry Extensions vs Explicit Route-State Extensions 21 Semantic Width vs Reachable Depth 22 Canonical Stability and Custom Extension Isolation 23 Permissions, Privacy, and Authorization Boundaries 24 Composability and Efficiency 25 Operator Locality and Model Routing 26 Registry and Binding Data Requirements 27 Worked Examples 28 Failure Modes and Anti-Patterns 29 Conformance Requirements and Tests 30 Reference Laws and Quick Notation Sheet A Formal Grammar Reference B Reference Extension Binding Record G Glossary I Subject Index by Section The Subject Index uses stable section references rather than page references so that the specification remains durable as wording and pagination change. 1. Purpose, Scope, and Design Objectives This specification defines a compact notation and conformance grammar for CERBERUS Semantic Bitwords and the explicit graph structures through which those Bitwords compose, relate, change together, and route toward greater semantic depth. It is designed to make complex semantic systems inspectable without forcing every possible meaning into one monolithic payload. 1.1 Goals Provide an immediately recognizable visual distinction between Pure and Compound Bitwords. Preserve Semantic Prefix Invariance for Pure Bitwords and Constituent Identity Invariance for Compound Bitwords. Provide exact local and path-qualified Bit addressing. Represent explicit semantic relationships without silently inferring them from similarity. Represent shared State changes across otherwise independent Bitwords. Permit canonical and custom semantic extension without changing the width or meaning of the source Bitword. Allow private, organizational, experimental, fantasy, and other namespaced extensions while preserving canonical interoperability. Support deterministic validation, decoding, projection, and bounded traversal. 1.2 Non-goals This notation is not itself a transport protocol, cryptographic format, database engine, authorization system, or user interface. The notation does not make an inferred relationship canonical merely because two values appear correlated. A Bitlink or extension route does not grant permission to view or traverse the target. Custom extension slots do not allow a user to redefine the common meaning of the source Bitword. 2. Semantic Growth Model Semantic structures grow through several distinct mechanisms. Conformance depends on preserving the difference between them, because each mechanism has different implications for width, ownership, decoding, and interoperability. Growth mechanism Notation What changes Source width Pure Prefix Extension PREFIX-n → PREFIX-m More resolution inside the same Pure semantic lineage. Increases Compound Composition A || B → [AB]-(n+m) More constituent semantic structures are assembled. New Compound has summed width Canonical Bitlink Extension A ↳ B Resolution continues through a governed route into another semantic structure. Unchanged Custom Bitlink Extension A ↳{NS} B Resolution continues through a namespaced binding. Unchanged SEMANTIC GROWTH Pure Extension A-64 → A-128 Compound Composition A-64 || B-64 → [AB]-128 Canonical Extension A:B007 ↳ C-256 Custom Extension A:B063 ↳{CIRCUIT} MY_C-128 Figure 2-1. Four primary semantic growth mechanisms. MASTER DESIGN RULE Semantic complexity SHOULD grow by extension, composition, and explicit graph routing rather than migration or reinterpretation of established Bits. 3. Foundational Terminology Term Definition Bit The smallest addressable binary semantic position inside a Bitword. Bit Group A bounded range of Bits interpreted together as one registered field, enumeration, mask, quantity, or semantic substructure. Bitword A bounded ordered binary semantic structure with declared width and grammar. Pure Bitword A Bitword whose complete payload belongs to one canonical prefix lineage. Compound Bitword A registered composition of two or more independently meaningful Bitwords under a declared Composition Model. Bitlink An explicit registered semantic relationship between bounded semantic objects. Statebound Bitlink A Bitlink whose participating Bits are coupled by a declared State transition. Bitlink Extension A directed semantic route indicating that additional resolution is obtained through another registered semantic structure. Custom Bitlink Extension A Bitlink Extension whose target binding is governed by a declared namespace rather than globally fixed by the source specification. Extension Route Bit A Bit whose canonical purpose is to indicate availability, activation, or routing of a semantic extension. Extension Routing State A value within a Bit or Bit Group meaning that local vocabulary is insufficient and further resolution must follow an explicit extension route. Namespace The authority/scope under which a Custom Bitlink Extension binding is defined. Composition Model The ordered declaration that maps a Compound payload to constituent Bitwords and their positions. Extension Binding Record A registered relation that binds a source route or routing state to a target semantic structure, with scope, provenance, version, and permissions. 4. Notation Lexicon Symbol Meaning Example PREFIX-### Pure Bitword MUSIC-128 [PREFIX]-### Compound Bitword [MEAL_PREP]-256 :B### Local Bit address HEALTH_DATA-128:B096 :B###-B### Bit range / Bit Group FOOD-128:B024-B031 :: Descend into a constituent/path [CARDIAC]-512::HEART-256:B042 [n] Repeated constituent instance EFFECT-16[3] || Ordered composition FOOD-128 || COOKING-128 π(TYPE) Projection / extraction π(FOOD-128)([MEAL_PREP]-256) ≡BIT Same canonical Bit identity A:B003 ≡BIT B:B007 ⇄ Explicit registered Bitlink A:B003 ⇄ B:B007 ΔS(x→y) Declared State transition ΔS(Note.Active:0→1) ⇄{ΔS} Statebound Bitlink A:B003 ⇄{ΔS(X)} B:B007 ↳ Canonical Bitlink Extension HEALTH_DATA-128:B096 ↳ [CARDIAC]-512 ↳{NS} Custom Bitlink Extension B124 ↳{CIRCUIT} MY_RECOVERY-128 ↳* Branching extension MetabolicConcern ↳* {GLUCOSE-256, ENDOCRINE-256} Route Bit annotation B096 Canonical Route Bit B096 Custom Extension Route Bit B124 EXT Extension Routing State PhysiologicalClass = EXT READING RULE || means “made from.” ⇄ means “related to.” ↳ means “resolve deeper through.” ↳{NS} means “resolve deeper through a namespaced extension.” 5. Pure Bitwords 5.1 Definition A Pure Bitword SHALL be written PREFIX-###, where PREFIX identifies one canonical semantic lineage and ### identifies total encoded width in bits. All encoded positions belong to that lineage or to fields explicitly reserved by that lineage for future use. COLOR_EFFECT-8 COLOR_EFFECT-16 MUSIC-128 BODY-256 HEALTH_DATA-128 5.2 Pure does not mean small Purity is a statement about semantic ownership, not size. A 1024-bit Pure Bitword can still be Pure if all Bits are governed by one prefix lineage. A 24-bit object may be Compound if it assembles independent words. 5.3 Prefix Invariance SEMANTIC PREFIX INVARIANCE Higher-resolution members of a Pure semantic prefix SHALL preserve the lower-resolution prefix byte-for-byte, in the same order and with the same meaning. New resolution appends; it does not migrate established Bits. HEALTH_DATA-64 = B000…B063 HEALTH_DATA-128 = B000…B063 || Extension B064…B127 ^^^^^^^^^^ unchanged 6. Compound Bitwords 6.1 Definition A Compound Bitword SHALL be written [PREFIX]-###. Brackets signal that the object is not interpreted as one continuous Pure prefix. The payload MUST first be decomposed according to its registered Composition Model. [MEAL_PREP]-256 = FOOD-128 || COOKING-128 6.2 Constituent Identity Invariance CONSTITUENT IDENTITY INVARIANCE A Bitword embedded inside a Compound SHALL retain its canonical identity, exact bit sequence, internal ordering, width, semantic interpretation, and source grammar. Composition creates an enclosing structure; it does not transfer semantic ownership of constituent Bits. 6.3 Compound width For direct ordered concatenation, total Compound width equals the sum of constituent widths. The width declaration applies to the encoded Compound payload, not to any external Bitlinks or extension targets reachable from it. W(A || B) = W(A) + W(B) FOOD-128 || COOKING-128 = [MEAL_PREP]-256 7. Composition Models and Width Accounting Every Compound Bitword SHALL resolve through a Composition Model that declares the ordered constituents, widths, positions, multiplicity where applicable, and nested Compound identities. The payload carries values; the Composition Model carries the grammar required to decompose them. Offset Constituent Width Owner B000-B127 FOOD-128 128 FOOD grammar B128-B255 COOKING-128 128 COOKING grammar A Composite MAY be serialized by direct concatenation, by references, or by another deterministic encoding if the canonical logical constituent boundaries remain recoverable. Physical representation is an implementation concern; semantic decomposition is normative. 8. Recursive Composition Trees Compound Bitwords are recursively closed: a Compound may contain Pure Bitwords, Compound Bitwords, or both. A composition tree answers “what is this object made from?” and is distinct from the Bitlink and extension graphs that may cross it. [SYNESTHETIC_EFFECT]-128 │ ├── [VISUAL_EFFECT]-64 │ ├── COLOR_EFFECT-16 │ ├── SHAPE_EFFECT-16 │ └── MOTION_EFFECT-32 │ ├── [TACTILE_EFFECT]-32 │ ├── HAPTIC_EFFECT-16 │ ├── PRESSURE_EFFECT-8 │ └── TEXTURE_EFFECT-8 │ └── SPATIAL_EFFECT-32 Figure 8-1. Recursive Compound tree. A runtime MAY flatten the payload for efficient execution, but semantic tooling SHOULD preserve the tree because it identifies canonical ownership and supports targeted projection, validation, mutation, and explanation. 9. Bit Addressing and Semantic Paths 9.1 Local Bit addresses Local Bit positions use :B###. Local addressing always resolves against the immediately named Bitword. HEALTH_DATA-128:B096 MOTION_EFFECT-32:B003 FOOD-128:B024-B031 9.2 Semantic descent The :: operator descends through Compound or registered semantic structure boundaries. Path-qualified addresses SHOULD be used whenever a local physical position would be ambiguous or when semantic ownership matters more than flattened storage position. [CARDIAC]-512::HEART-256:B042 [SYNESTHETIC_EFFECT]-128::[VISUAL_EFFECT]-64::COLOR_EFFECT-16:B006 9.3 Path stability A semantic path SHOULD identify constituent meaning rather than relying solely on flattened absolute offsets. A compiler may place or reference constituents differently while preserving the same semantic path. 10. Repeated Constituents and Matrices Repeated constituents use [n] after the Bitword identity. The index denotes one occurrence of a repeated constituent type inside the current composition or collection. [EFFECT_MATRIX]-128 = 8 × EFFECT-16 [EFFECT_MATRIX]-128::EFFECT-16[3]:B006 A Matrix is a structured repetition, not automatically a higher-resolution Pure Bitword. Repetition cardinality, index origin, and ordering MUST be declared by the Composition Model. 11. Projection and Constituent Extraction Projection notation π(TYPE)(COMPOUND) identifies deterministic extraction of a constituent semantic object from a Compound or nested structure. π(FOOD-128)([MEAL_PREP]-256) → FOOD-128 π([VISUAL_EFFECT]-64)([SYNESTHETIC_EFFECT]-128) → [VISUAL_EFFECT]-64 Projection SHOULD NOT imply mutation. A mutation Operator MUST separately declare authority and transformation semantics for the projected target. 12. Bit Identity and Explicit Bitlinks 12.1 Same canonical Bit identity ≡BIT indicates that two encoded locations or projections represent the same canonical semantic Bit identity. This is stronger than relationship and SHOULD be used sparingly. A:B003 ≡BIT B:B007 12.2 Explicit Bitlink ⇄ indicates an explicitly registered semantic relationship between distinct bounded semantic objects. The glyph does not itself assert equality, causation, direction, or confidence. Those semantics belong to the Bitlink record. COLOR_EFFECT-8:B002 ⇄ HAPTIC_EFFECT-8:B005 12.3 Identity and relation are not interchangeable IDENTITY VS RELATION ≡BIT means “the same canonical Bit.” ⇄ means “different semantic objects with an explicit registered relationship.” 13. State Changes and Statebound Bitlinks 13.1 State transition notation ΔS(State:Old→New) identifies a declared State transition. The State MAY be represented by a Bit, Bit Group, Model output, Instance state, or other bounded registered state. ΔS(Note.Active:0→1) ΔS(Workout.Status:Planned→Completed) 13.2 Statebound Bitlink A ⇄{ΔS(...)} B indicates that distinct semantic Bits participate in the same declared State transition. This allows otherwise independent Bitwords to change in coordinated ways without requiring a monolithic shared schema. COLOR_EFFECT-8:B002 ⇄{ΔS(Note.Attack:0→1)} HAPTIC_EFFECT-8:B005 13.3 Statebound Bitlink Sets One State transition MAY coordinate many Bits. The registered State transition becomes the common behavioral context while each participating Bit retains its own semantic owner. ΔS(Note.Attack:0→1) ⇒ COLOR_EFFECT-8:B002 := 1 ⇒ HAPTIC_EFFECT-8:B005 := 1 ⇒ LIGHT_EFFECT-8:B001 := 1 ⇒ SPATIAL_EFFECT-16:B009 := 1 14. Bitlink Graphs Across Compound Trees Composition topology and Bitlink topology are independent. The tree shows containment. The Bitlink graph may cross any branches, constituent types, records, or Semantic Kernels for which an explicit governed relationship exists. [SYNESTHETIC_EFFECT]-128 ├── [VISUAL_EFFECT]-64 │ └── COLOR_EFFECT-16:B006 └── [TACTILE_EFFECT]-32 └── HAPTIC_EFFECT-16:B003 COLOR_EFFECT-16:B006 ⇄{ΔS(Note.Accent)} HAPTIC_EFFECT-16:B003 TOPOLOGY SEPARATION Composition answers containment. Bitlinks answer relationship. Extension routes answer semantic continuation. Permissions answer who may traverse or evaluate any of those relationships. 15. Pure Extension and Compound Expansion 15.1 Pure Extension Pure Extension increases resolution inside one prefix lineage. Lower-resolution bits remain unchanged. COLOR_EFFECT-8 → COLOR_EFFECT-16 → COLOR_EFFECT-32 15.2 Compound Expansion Compound Expansion preserves established constituents while adding new constituents to a registered Compound design. It is not the same as Pure Prefix Extension even if the new payload is append-only. [VISUAL_EFFECT]-32 = COLOR_EFFECT-16 || SHAPE_EFFECT-16 [VISUAL_EFFECT]-64 = COLOR_EFFECT-16 || SHAPE_EFFECT-16 || MOTION_EFFECT-32 15.3 Composition Invariance SEMANTIC COMPOSITION INVARIANCE Existing constituents SHALL retain canonical meaning and bit sequence when incorporated into or retained within a larger Compound composition. 16. Canonical Bitlink Extensions 16.1 Definition A Canonical Bitlink Extension uses ↳ to indicate a directed, governed route from a source semantic object to another registered semantic structure that provides additional resolution. The target is not physically contained in the source payload merely because the route exists. HEALTH_DATA-128:B096 ↳ [CARDIAC]-512 16.2 Extension semantics The source and target retain independent canonical identities. The extension relation MUST be explicitly registered and versioned. The source width does not increase when the route exists. Traversal MUST remain finite for any actual request or runtime operation. The target MAY be Pure or Compound. The route MAY be type-level, record-level, or both, as declared by the Binding Record. 16.3 Directed meaning ↳ is intentionally directional. A ↳ B means B is a declared place to continue semantic resolution from A. It does not automatically imply that B extends A in the reverse direction. Reverse navigation MAY still exist through Registry indexes or an explicit reverse Bitlink. 16.4 Width conservation across extension W(A ↳ B) = W(A) for the encoded source A Reach(A) may include B through the registered graph WIDTH VS ROUTE A Bitlink Extension changes reachable semantic depth, not the encoded width of the source Bitword. 17. Extension Route Bits and Extension Routing States 17.1 Extension Route Bit An Extension Route Bit is a Bit whose declared semantic purpose is to indicate availability, activation, or routing of a semantic extension. Specifications MAY annotate such Bits with . HEALTH_DATA-128:B096 HEALTH_DATA-128:B096 Annotation Meaning Route Bit; exact route class resolved by the specification. Canonical Route Bit; destination type is governed by the common specification. Custom Extension Route Bit; destination binding is namespaced and not globally fixed. 17.2 Route state and domain state are separate A domain concern and the availability of detailed data SHOULD be represented separately when both distinctions matter. A Cardiac Concern may be present even when no detailed cardiac Bitword has been registered; conversely, historical detail may exist even when the current concern state is not active. CardiacConcern = PRESENT CardiacDetailAvailable = 1 CardiacDetailAvailable ↳ [CARDIAC]-512 17.3 Extension Routing State An Extension Routing State is a value within an existing Bit or Bit Group indicating that the local vocabulary is intentionally insufficient and resolution must continue through an explicit extension route. EXT is the recommended notation in specifications. HEALTH_DATA-64::PhysiologicalClass 00 Unknown 01 Class A 10 Class B 11 EXT → resolve registered extension OTHER IS A ROUTE, NOT A BUCKET When “Other” is encoded as an Extension Routing State, it SHOULD mean “the compact vocabulary is insufficient; follow the registered extension” rather than “miscellaneous unstructured data.” 18. Custom Bitlink Extensions and Namespaces 18.1 Definition A Custom Bitlink Extension uses ↳{NAMESPACE} to route semantic resolution through a binding governed by a declared namespace rather than a globally fixed target in the source Bitword specification. HEALTH_DATA-128:B124 ↳{CIRCUIT} MY_RECOVERY-128 18.2 Namespace authority The namespace identifies the authority under which the binding is meaningful. It does not automatically indicate publicness, correctness, or permission. Namespace identifiers SHOULD be stable and SHOULD resolve to governance/provenance metadata. Namespace example Typical meaning {CIRCUIT} Private user-owned binding. {ORG:DRAGON_ACADEMY} Organization-scoped extension. {COMMUNITY:SPORT_SCIENCE_LAB} Community or research-group extension. {PROJECT:ALPHA} Project-scoped extension. {FRINGE} Shared experimental or provisional extension. {FASK} Fantasy / alternate-rules extension with explicit epistemic separation. {EXTERNAL:VENDOR_A} External/proprietary semantic binding. 18.3 Target freedom A Custom Bitlink Extension MAY target a Pure Bitword, Compound Bitword, Instance, Model, or other registered semantic object if the source specification permits that target class. The target owns its own semantics; the source slot owns only the fact that a custom extension route is active. Record-level binding. The same Custom Extension Route Bit may bind differently for different records or users. The destination identity SHOULD live in the Extension Binding Record, not in the route Bit itself. User A HEALTH_DATA-128:B124 ↳{CIRCUIT} MY_RECOVERY-128 User B HEALTH_DATA-128:B124 ↳{CIRCUIT} MY_METABOLIC_CONTEXT-256 19. Branching and Recursive Extension Chains 19.1 Branching Extension ↳* indicates that one source has multiple explicitly registered extension destinations. The symbol is a concise notation for a finite set of extension relations; it is not a claim that all targets should always be traversed. HEALTH_DATA-128::MetabolicConcern ↳* ├── GLUCOSE-256 ├── ENDOCRINE-256 └── METABOLIC-256 19.2 Extension chain Extension routes may recurse. Each traversed step MUST resolve to a registered relation, and each actual traversal MUST be finite. A document MAY use ↳… as a human-readable shorthand indicating that further registered extension steps exist beyond those shown; canonical storage SHALL retain explicit edges. HEALTH_DATA-128::CardiacDetailAvailable ↳ [CARDIAC]-512 ::HEART-256:B042 ↳ CARDIAC_ELECTRICAL-256 ::RhythmConcern ↳ [RHYTHM_DETAIL]-1024 19.3 LIBERTY compatibility Recursive extension expresses LIBERTY cleanly: the grammar can generate deeper semantic networks without a predefined conceptual depth limit, while every deployed Bitword is bounded and every actual traversal remains finite and governed. 20. Implicit Registry Extensions vs Explicit Route-State Extensions 20.1 Implicit Registry Extension A semantic object may have a registered extension even when the source payload contains no dedicated availability Bit. This is appropriate when extension existence is stable at the type level or when route presence can be resolved cheaply from the Registry. FOOD-128::Potassium ↳ MICRONUTRIENTS-256 20.2 Explicit Route-State Extension A dedicated Route Bit is appropriate when route availability varies by record, when rapid filtering matters, or when a compact payload must signal that a deeper private branch exists without disclosing the branch. HEALTH_DATA-128:B096 = 1 B096 ↳ [CARDIAC]-512 20.3 Selection rule Use Prefer Type-level stable semantic continuation Implicit Registry Extension Per-record branch availability Explicit Route-State Extension Private/custom per-record destination Custom Extension Route Bit + namespaced Binding Record Many possible destinations selected by one state Branching Extension or routed Model, depending on semantics 21. Semantic Width vs Reachable Depth Bitword width and semantic depth are intentionally decoupled. Width measures encoded payload. Reachable depth measures how far a permitted traversal can proceed through explicit Bitlinks and extension routes. WIDTH–DEPTH PRINCIPLE Bitword width bounds encoded state, not reachable semantic depth. A small Bitword may route into arbitrarily detailed registered structures while remaining exactly the same size. HEALTH_DATA-128 128 encoded bits │ └── Cardiac route ↳ [CARDIAC]-512 │ └── HEART-256 route ↳ CARDIAC_ELECTRICAL-256 │ └── … deeper only if required HEALTH_DATA still = 128 bits This separation prevents “universal schema inflation,” where every possible specialist detail is forced into the root word simply because it may someday be relevant. 22. Canonical Stability and Custom Extension Isolation 22.1 Custom Extension Isolation Principle CUSTOM EXTENSION ISOLATION PRINCIPLE A Custom Bitlink Extension MAY bind a declared extension slot to arbitrary permitted registered semantic structures without altering the canonical meaning, width, ordering, or interoperability of the source Bitword. 22.2 Slot meaning vs target meaning A custom route slot owns only its route semantics. It MUST NOT silently inherit the semantic identity of whichever target happens to be bound in one record. Canonical: HEALTH_DATA-128:B124 = Custom Extension Route 1 Active Binding: B124 ↳{CIRCUIT} MY_RECOVERY-128 B124 does NOT become “Recovery.” 22.3 Reserved Bits are not automatically custom routes A Bit declared as reserved or MUST-zero in an existing specification SHALL NOT be retroactively reinterpreted as a Custom Extension Route Bit if doing so would violate Prefix Invariance or prior conformance. New specifications SHOULD deliberately allocate Extension Route Bits and Custom Extension Route Bits where open-ended extensibility is desired. DESIGN RECOMMENDATION Standardize the common core. Allocate explicit route slots. Bitlink the specialized edge. Let namespaces carry unanticipated meaning without rewriting the common kernel. 23. Permissions, Privacy, and Authorization Boundaries 23.1 Bitlinkability does not imply disclosure AUTHORIZATION BOUNDARY The existence of a Bitlink or extension route SHALL NOT imply that the current viewer, application, Model, or external participant is authorized to traverse, inspect, copy, or evaluate the target. This principle is especially important for private health, financial, legal, identity, and personal semantic structures. A root word may reveal only that a deeper branch exists, while an authorized local Model evaluates that branch and returns a bounded result. External Fitness App │ asks bounded question ▼ Authorized local evaluation │ ├── HEALTH_DATA-128 ├── [CARDIAC]-512 └── Applicable Model / Normative │ ▼ Returns bounded constraint / result Underlying detailed cardiac Bits need not leave CIRCUIT. 23.2 Route discovery vs route traversal Implementations SHOULD distinguish: (1) knowledge that a route exists, (2) authority to resolve the target identity, (3) authority to read target state, and (4) authority to execute a Model using target state. These are separate permissions. 23.3 Epistemic status preservation Extension traversal SHALL preserve source and target epistemic status. A FASK target remains FASK. A FRINGE target remains experimental. A private CIRCUIT target remains private. Merely linking or executing through the route does not promote or canonicalize the target. 24. Composability and Efficiency 24.1 Avoiding monolithic schemas Compound Bitwords and Bitlink Extensions attack different sources of unnecessary size. Composition avoids creating a new Pure schema for every combination. Extension routing avoids embedding every possible specialist branch into the common root. BAD: universal object with every possible modality/domain packed in GOOD: small reusable Pure words + Compound composition when payloads must travel together + Bitlinks for relationships + Extension routes for deeper optional semantics 24.2 Minimum Sufficient Word MINIMUM SUFFICIENT WORD PRINCIPLE A semantic attachment SHOULD use the smallest registered Bitword capable of expressing the required state at the required resolution. Higher resolution or deeper traversal is requested only when materially necessary. 24.3 Sparse multimodality and sparse specialist depth A note may carry only COLOR_EFFECT-8 while another carries [SYNESTHETIC_EFFECT]-128. A person may carry HEALTH_DATA-64 while another additionally exposes HEALTH_DATA-128 routes into detailed cardiac or renal structures. Absence of a branch does not require placeholder payload. 24.4 Reuse and deduplication Frequently repeated Bitwords or extension targets MAY be referenced instead of duplicated. Inline and reference representations are semantically equivalent only when the same canonical identity and value are preserved. 25. Operator Locality and Model Routing 25.1 Semantic locality Operators SHOULD target the smallest semantic constituent or routed branch necessary for the transformation. A COLOR Operator does not need to understand the entire Synesthetic Compound; a cardiac Model does not need unrelated health branches. π(COLOR_EFFECT-16)([VISUAL_EFFECT]-64) → apply BRIGHTEN → reconstruct Compound with unrelated constituents unchanged 25.2 Extension-aware Model routing A Model MAY declare route requirements. For example, an ordinary energy Model may consume HEALTH_DATA-64. A more constrained fitness Model may consume HEALTH_DATA-128 and require [CARDIAC]-512 only when CardiacConcern is present and the Model’s Normatives require deeper resolution. IF HEALTH_DATA-128::CardiacConcern = PRESENT AND Model.RequiresCardiacResolution = TRUE THEN resolve CardiacDetailAvailable ↳ [CARDIAC]-512 ELSE continue at current resolution 25.3 Goal-seek integration Goal-seek behavior MAY operate across Bitlinked Models without merging source domains. FITNESS records, HEALTH_DATA, and MEAL_PREP objects can remain independent while derived workload and nutrition Models establish explicit optimization relationships. 26. Registry and Binding Data Requirements 26.1 Composition Model requirements Compound identity and total width. Ordered constituent identities and widths. Nested Compound references where applicable. Repeated constituent cardinality and index semantics. Serialization/offset mapping sufficient for deterministic decomposition. Version and provenance. 26.2 Bitlink Extension Binding requirements Stable Binding ID. Source Bitword type and optional source record reference. Exact source path, Bit, Bit Group, or routing state. Route class: canonical, custom, branching, or other declared subtype. Namespace for custom routes. Target semantic identity or target type constraint. Cardinality and activation semantics. Version, provenance, and status. Applicable authorization / permission reference. Epistemic scope where materially relevant. 26.3 Canonical vs record-level bindings Canonical bindings are commonly type-level: a designated cardiac route in HEALTH_DATA resolves to the CARDIAC semantic family. Custom bindings are commonly record-level: a person’s Custom Route 1 may resolve to that person’s private recovery SK. Implementations MAY support both layers simultaneously. 27. Worked Examples 27.1 FITNESS record as a Compound Bitword [FITNESS_RECORD]-160 = TIME-32 || FIT-128 TIME-32 provides calendar sequencing/placement. FIT-128 provides the fitness event semantics. A calendar projection can decode both without either word knowing how the screen is rendered. 27.2 Meal preparation as a Compound Bitword [MEAL_PREP]-256 = FOOD-128 || COOKING-128 FOOD identifies what is being worked with. COOKING identifies the preparation/cooking semantics. The Compound binds them without creating a new Pure schema for every food-method combination. 27.3 HEALTH_DATA routing into detailed cardiac semantics HEALTH_DATA-128 │ ├── Core reusable physiological/model inputs ├── CardiacConcern = PRESENT └── CardiacDetailAvailable = 1 │ ↳ [CARDIAC]-512 │ ├── BODY-256 └── HEART-256 HEALTH_DATA remains a compact private routing and model-input word. It does not become a miniature cardiac record. The cardiac branch can itself route into deeper specialist structures if required. 27.4 “Other / different Model” as Extension Routing State HEALTH_DATA-64::PhysiologicalClass = EXT │ ↳ HEALTH_DATA_OTHER-64 │ └── may extend further if required EXT means the compact local vocabulary is insufficient. The detailed representation lives in the target word, not in a miscellaneous unstructured bucket. 27.5 Private custom extension HEALTH_DATA-128:B124 = 1 ↳{CIRCUIT} MY_RECOVERY-128 MY_RECOVERY-128 ├── ⇄ SLEEP-128 ├── ⇄ FITNESS_HISTORY-256 └── ↳{CIRCUIT} MY_SLEEP_DETAIL-256 The source slot is canonical and interoperable; the destination is private and user-controlled. Another person may bind B124 to a completely different permitted semantic structure. 27.6 FRINGE and FASK extensions HEALTH_DATA-128:B126 ↳{FRINGE} EXPERIMENTAL_LONGEVITY-256 HEALTH_DATA-128:B127 ↳{FASK} [DRAGON_PHYSIOLOGY]-1024 The graph can cross epistemic environments without collapse. Experimental or fantasy targets remain explicitly experimental or fantasy. Real HEALTH_DATA remains real/private source state. 27.7 Branching specialist extension HEALTH_DATA-128::MetabolicConcern ↳* ├── GLUCOSE-256 ├── ENDOCRINE-256 └── METABOLIC-256 A Model or SCREEN may traverse only the branch relevant to the current task. The presence of several registered destinations does not require loading them all. 27.8 Composition plus extension in one object [MEAL_PREP]-256 ├── FOOD-128 │ └── MicronutrientDetail ↳ MICRONUTRIENTS-256 └── COOKING-128 └── TechniqueDetail ↳ COOKING_TECHNIQUE-256 Compound payload and extension graph coexist cleanly. Composition keeps required payloads together; extension routes preserve optional depth outside the Compound width. 28. Failure Modes and Anti-Patterns Anti-pattern Why it fails Monolithic inflation Adding every conceivable future specialist field to a root Bitword instead of routing optional depth through extensions. Route-as-containment confusion Treating ↳ as if target bits were physically inside the source payload. Custom semantic capture Allowing one user’s target binding to redefine the canonical meaning of a custom route slot. Permission leakage Assuming that a visible route or Bitlink authorizes reading the target. Epistemic laundering Using a link from real/CIRCLE state to FRINGE or FASK material as evidence that the target is canonical truth. Retroactive reserved-bit reinterpretation Repurposing a previously MUST-zero or semantically fixed Bit in a way that breaks Prefix Invariance. Unbounded runtime traversal Following extension graphs recursively without explicit depth, scope, cycle, or resource bounds. Implicit inference as canonical Bitlink Creating canonical relationships merely because a runtime infers similarity or correlation. Opaque “Other” bucket Encoding Other without an explicit extension route or governed semantics when deeper resolution is required. 29. Conformance Requirements and Tests ID Requirement Reference test BW-001 Pure notation A Pure Bitword is written PREFIX-### and resolves to one canonical prefix lineage. BW-002 Compound notation A Compound Bitword is written [PREFIX]-### and deterministically decomposes through a Composition Model. BW-003 Width accounting Compound direct-concatenation width equals sum of constituent widths. BW-004 Constituent identity Embedding a constituent does not change its canonical bit sequence or meaning. BW-005 Path resolution A path-qualified Bit reference resolves to one exact owning constituent and local Bit. BW-006 Bitlink explicitness ⇄ relationships are registered and are not inferred solely from similarity. BW-007 Statebound linkage ⇄{ΔS} identifies a declared State transition shared by participating semantic objects. BW-008 Canonical extension ↳ resolves through a versioned registered binding and does not change source width. BW-009 Custom namespace ↳{NS} resolves through a declared namespace and preserves the canonical meaning of the source slot. 29. Conformance Requirements and Tests — continued ID Requirement Reference test BW-010 Route-state separation Domain concern/value and detail-availability route state remain distinguishable when both are represented. BW-011 Extension routing state EXT or equivalent routing state resolves to an explicit extension target rather than an opaque miscellaneous field. BW-012 Branching extension ↳* expands only to explicitly registered finite destinations for the current traversal. BW-013 Permission boundary A route can exist while target traversal or disclosure remains denied. BW-014 Epistemic preservation FRINGE/FASK/custom target status survives traversal and execution. BW-015 Reserved-bit safety Previously reserved/MUST-zero bits are not silently reinterpreted in violation of prior conformance. BW-016 Finite traversal Every runtime traversal has a finite bound and cycle handling. BW-017 Custom binding isolation Two records may bind the same slot to different permitted targets without changing source grammar. BW-018 Minimum sufficient depth A conforming consumer can stop at the lowest sufficient Bitword/extension depth for the declared task. 30. Reference Laws and Quick Notation Sheet 30.1 Formal laws Law Rule Semantic Prefix Invariance Higher-resolution Pure words preserve lower-resolution prefix bits, order, and meaning. Constituent Identity Invariance Composition does not rewrite constituent semantic identity. Width Conservation For direct composition, W(A || B) = W(A) + W(B). Extension Width Invariance A ↳ B does not enlarge the encoded width of A. Width–Depth Principle Encoded width and reachable semantic depth are independent dimensions. Explicit Relationship Principle Canonical Bitlinks and extension routes are registered, not silently inferred. Custom Extension Isolation Namespaced custom bindings do not redefine the canonical source slot. Authorization Independence Bitlinkability/route existence does not imply permission to traverse or disclose. Epistemic Status Preservation Traversal does not alter CIRCLE, FRINGE, FASK, private, or proprietary status. Finite Traversal Every actual traversal is bounded and cycle-safe. Minimum Sufficient Word Use the smallest sufficient Bitword and semantic depth for the task. Semantic Complexity Growth Prefer extension/composition/routing over migration or reinterpretation. 30.2 Quick notation sheet PURE PREFIX-### COMPOUND [PREFIX]-### BIT PREFIX-###:Bnnn BIT RANGE PREFIX-###:Bnnn-Bmmm PATH A::B::C:Bnnn REPEAT WORD[n] COMPOSE A || B PROJECT π(TYPE)(COMPOUND) SAME BIT A ≡BIT B BITLINK A ⇄ B STATE ΔS(X:a→b) STATE LINK A ⇄{ΔS(X)} B EXTEND A ↳ B CUSTOM EXTEND A ↳{NAMESPACE} B BRANCH EXTEND A ↳* {B, C, D} ROUTE BIT Bnnn CANONICAL ROUTE Bnnn CUSTOM ROUTE Bnnn ROUTING STATE Field = EXT Appendix A. Formal Grammar Reference The following grammar is descriptive rather than transport-binding. It defines notation relationships used in formal specifications, diagrams, registries, and developer tooling. PURE := PREFIX "-" WIDTH COMPOUND := "[" PREFIX "]-" WIDTH BIT := WORD ":B" INDEX BIT_RANGE := WORD ":B" INDEX "-B" INDEX INSTANCE := WORD "[" INDEX "]" PATH := WORD ("::" WORD)* (":" BIT_LOCAL)? COMPOSITION := WORD "||" WORD ("||" WORD)* PROJECTION := "π(" TYPE ")(" COMPOUND ")" BIT_IDENTITY := BIT "≡BIT" BIT BITLINK := OBJECT "⇄" OBJECT STATE := "ΔS(" STATE_ID ":" OLD "→" NEW ")" STATE_BITLINK := OBJECT "⇄{" STATE "}" OBJECT EXTENSION := OBJECT "↳" TARGET CUSTOM_EXT := OBJECT "↳{" NAMESPACE "}" TARGET BRANCH_EXT := OBJECT "↳*" "{" TARGET ("," TARGET)* "}" ROUTE_BIT := BIT "" CANON_ROUTE := BIT "" CUSTOM_ROUTE := BIT "" ROUTING_STATE := FIELD "=" "EXT" Implementations MAY serialize equivalent identifiers in database-friendly or API-friendly forms. The semantic distinctions SHALL remain recoverable. Appendix B. Reference Extension Binding Record Field Requirement Meaning binding_id Required Stable identity for the extension relation. binding_version Required Version of the binding semantics. source_word_type Required Canonical source Bitword type. source_record_ref Conditional Specific source record when binding is record-level. source_path Required Exact Bit, Bit Group, routing state, or semantic path. route_class Required Canonical / custom / branching / other declared subtype. namespace Required for custom Authority/scope controlling a custom binding. target_ref Required Target semantic object or target type binding. target_class Recommended Pure Bitword, Compound Bitword, Model, Instance, etc. cardinality Required One, optional-one, many, ordered-many, etc. activation_semantics Conditional How source state indicates route activation/availability. epistemic_scope Conditional CIRCLE, FRINGE, FASK, private, proprietary, etc. permission_ref Conditional Authorization rule/object governing traversal or evaluation. provenance Required Who/what created or governed the binding and when. status Required Active, proposed, deprecated, revoked, experimental, etc. BINDING RECORD PRINCIPLE The route Bit carries compact state. The Binding Record carries destination identity, governance, provenance, and permission semantics. Appendix G. Glossary Term Definition Bit Smallest addressable binary position inside a Bitword. Bit Group Bounded set/range of Bits interpreted together. Bit Address Local :B### reference inside a named Bitword. Bit Identity Canonical semantic primitive represented by a Bit location. Bitlink Explicit registered semantic relationship, written ⇄. Bitlink Extension Directed semantic continuation to another registered structure, written ↳. Bitlink Graph Network of explicit registered semantic relations among Bits, Bit Groups, Bitwords, Models, or other objects. Bitlinkability The fact that an object can participate in explicit relationships; not equivalent to disclosure authority. Branching Extension One source with multiple registered extension destinations, written ↳*. Canonical Route Bit Route Bit whose target semantic family is governed by the common source specification; . Canonical Semantic Ownership Rule that a constituent or target retains the grammar that defines its meaning. Compound Bitword A bracketed [PREFIX]-### structure composed from independently meaningful Bitwords. Compound Expansion Growth of a Compound by adding constituents while preserving established constituents. Composition Ordered assembly of Bitwords using ||. Composition Model Registered grammar that declares constituent ordering, widths, positions, nesting, and repetition. Composition Tree Containment hierarchy produced by recursively decomposing Compound Bitwords. Constituent One Bitword embedded or referenced as part of a Compound Bitword. Constituent Identity Invariance Rule that composition does not rewrite a constituent’s canonical bits or meaning. Custom Bitlink Extension Namespaced extension relation written ↳{NAMESPACE}. Custom Extension Isolation Rule that custom target bindings do not redefine the canonical source slot. Custom Extension Route Bit Route Bit allocated for namespaced/custom bindings; . Epistemic Status Declared status such as CIRCLE/Common, FRINGE/experimental, FASK/fantasy, private, or proprietary. EXT Recommended display value for an Extension Routing State. Extension Binding Record Registry object binding a source route/state to a target with namespace, version, provenance, cardinality, and permissions. Extension Chain Finite traversal across successive ↳ relations. Extension Routing State A field value indicating that sufficient interpretation requires following an explicit extension route. Extension Route Bit Bit whose purpose is to indicate route availability, activation, or continuation. Implicit Registry Extension Registered semantic continuation that requires no dedicated per-record Route Bit. Minimum Sufficient Word Smallest Bitword/resolution sufficient for the declared task. Namespace Authority/scope under which a custom extension binding is defined. Path Semantic descent through constituent identities using ::. Prefix Extension Append-only increase in resolution inside one Pure prefix lineage. Prefix Invariance Rule that higher-resolution Pure words preserve all lower-resolution prefix bits and meanings. Projection Deterministic extraction of a constituent semantic object, written π(TYPE)(...). Pure Bitword Unbracketed PREFIX-### Bitword governed by one canonical prefix lineage. Reachable Semantic Depth How far a permitted traversal can continue through explicit graph routes; independent of encoded width. Reserved Bit Bit without active semantic use under the current canonical specification; not automatically a custom route. Route Activation State indicating that an extension relation is currently available/applicable for a record. Route Discovery Ability to determine that a route exists; distinct from permission to traverse it. Semantic Composition Invariance Rule preserving established constituent identity across Compound compositions. Semantic Depth Number/structure of explicit semantic extension steps reachable from a source. Semantic Growth Increase in resolution, composition, or reachable graph structure. Semantic Path Path-qualified reference identifying semantic ownership through nested structures. Semantic Prefix Stable named semantic lineage used by a Pure Bitword. State Transition Declared change in bounded state, written ΔS(...). Statebound Bitlink Bitlink coupled to a shared declared State transition, written ⇄{ΔS(...)}. Width Total encoded bit count of a Bitword. Width–Depth Principle Rule that encoded width does not bound reachable semantic depth. Appendix I. Subject Index by Section Subject Reference Subject Reference Authorization / disclosure §§ 23, 26, 29; Glossary Bit address §§ 4, 9; App. A; Glossary Bit identity § 12; Glossary Bitlink §§ 12–14, 24–27; Glossary Bitlink Extension §§ 2, 4, 16–23, 26–30; Apps. A–B; Glossary Branching Extension § 19; §§ 20, 27, 29–30; Glossary CARDIAC example §§ 16–17, 19, 23, 25, 27 Compound Bitword §§ 4, 6–11, 15, 24, 27–30; Glossary Composition Model §§ 6–8, 10–11, 26; Glossary Custom Bitlink Extension §§ 2, 4, 18–23, 26–30; Apps. A–B; Glossary Custom Extension Isolation § 22; § 29–30; Glossary Custom Extension Route Bit §§ 17–18, 20, 22, 27; Glossary Extension Binding Record §§ 16, 18–20, 26; App. B; Glossary Extension Routing State / EXT §§ 17, 20, 27–30; Glossary Extension Route Bit §§ 17–20, 22, 26–30; Glossary FASK extension §§ 18, 23, 27; Glossary Finite traversal §§ 16, 19, 21, 23, 29–30 FRINGE extension §§ 18, 23, 27; Glossary HEALTH_DATA §§ 5, 16–23, 25, 27 Implicit Registry Extension § 20; Glossary Matrices / repetition § 10; § 27 Minimum Sufficient Word § 24; § 29–30; Glossary Namespace § 18; §§ 22–23, 26–30; Glossary Operator locality § 25 Permission boundary § 23; §§ 26, 29–30 Prefix Extension §§ 2, 5, 15; Glossary Projection § 11; § 25; Glossary Pure Bitword §§ 4–5, 15; App. A; Glossary Reserved Bits § 22; § 28–29; Glossary Semantic path § 9; §§ 14, 19, 26; Glossary Statebound Bitlink § 13; §§ 14, 27, 29–30; Glossary Width accounting §§ 6–7, 16, 21, 24, 29–30 Width–Depth Principle § 21; §§ 24, 30; Glossary CLOSING STATEMENT SYSTEM SUMMARY Pure Bitwords encode one semantic lineage. Compound Bitwords encode assembly. Bitlinks encode explicit relationships. Statebound Bitlinks encode coordinated change. Bitlink Extensions encode where deeper canonical resolution continues. Custom Bitlink Extensions allow namespaced semantic growth without rewriting the common kernel. The resulting grammar allows CERBERUS to keep common Bitwords small and interoperable while supporting enormous specialist, personal, experimental, and imaginative semantic networks around them. The canonical core remains stable; semantic depth grows through explicit, inspectable, permission-aware routes.