1 - CERBERUS_Deterministic_Semantic_Compilation_and_Projection_Architecture_v0.1.docx

CERBERUS Deterministic Semantic Compilation and Projection Architecture Formula Tables, SK Readers, Reader Semantics, and D/E/F/G Display Variants ARCHITECTURE THESIS Semantic interpretation is resolved during Semantic Kernel authoring so runtime execution can remain deterministic. Binary state is split by the exact BitWord structure, decoded through reusable Formula families, written into exact SK Reader fields, and projected through D/E/F/G displays without requiring AI to guess what the Bits mean. Architecture Paper v0.1 Bootstrap Candidate | August 2026 Abstract This paper defines the runtime bridge between a formal CERBERUS Semantic Kernel Specification and a functioning deterministic BitWord record. The architecture separates four responsibilities that are often conflated in conventional systems: canonical semantic construction, reusable binary mathematics, human-facing semantic explanation, and interface projection. The Semantic Kernel Specification fixes the Bits, BitGroups, exact placement, Reader topology, and composition. Formula records provide reusable mathematical decoders such as SCALAR-N, MASK-N, and TWOS-N. The SK Reader provides the exact ordered computational fields of a BitWord. A parallel Reader Semantics structure provides only the human-facing Long Text needed to explain each Reader field. D/E/F/G displays consume the same canonical data at BitGroup, Compound BitGroup, BitWord, and Compound BitWord scope without becoming alternate truth stores. The resulting runtime is deliberately simple: split a binary record according to the registered BitGroup sequence, execute the registered Formula for each slice, write each result to its exact Reader field, and synthesize the outputs in canonical order. AI may assist with authoring, natural-language routing, explanation, or documentation, but the calculation itself is deterministic. The architecture therefore supports very large semantic systems while reusing a comparatively small library of computational primitives and display components. Keywords: Semantic Kernel, Bit, BitGroup, BitWord, Formula Table, SK Reader, Reader Semantics, D/E/F/G, deterministic compilation, projection, BIGFOOT, DARTBOARD Document Map Section Focus 1-3 Purpose, Spec authority, and the canonical computational stack 4-7 Formula reuse, structural parsing, SK Readers, and human semantics 8-10 D/E/F/G projection, display variants, and read/write execution 11-13 AI boundary, scale, and the Airtable proof-of-concept 14-17 Portability, conformance, design laws, and Bootstrap implications Figure 1. Deterministic Semantic Kernel compilation architecture. The Specification governs canonical construction; runtime computation is separate from human semantics and display projection. 1. Purpose and Scope The purpose of this architecture is to make a Semantic Kernel executable without asking an AI, interface, or renderer to infer what its binary state means. CERBERUS already places the semantic design burden in the Semantic Kernel Specification. The runtime architecture described here takes advantage of that decision: it executes the structure that has already been authored and governed. The paper focuses on five connected mechanisms: reusable Formula records, exact SK Readers, a minimal Reader Semantics companion, D/E/F/G display projections, and the conformance relationship that binds all of them back to the Semantic Kernel Specification. It does not redefine the Bit, BitGroup, BitWord, Compound BitWord, Rule, Operator, or model systems. Instead, it specifies how those existing structures can be deterministically read and presented. CORE BOUNDARY The Specification answers what the Kernel is. The Formula system answers how its BitGroups calculate. The SK Reader answers where the calculated results belong. Reader Semantics answers what those results mean to a human. D/E/F/G answers how the same state is displayed. 2. The Authoring-Runtime Boundary A Semantic Kernel may be cognitively rich while remaining computationally simple. During authoring, the designer must decide which distinctions belong in the Kernel, which BitGroups are appropriate, how the Bits are placed, which resolution extensions are valid, which Reader addresses exist, and what each placement means. These are semantic design decisions. Once published in the Specification and implemented in the registries, they are no longer questions for runtime inference. The runtime should therefore behave more like a compiler than an interpreter of ambiguous prose. It receives a registered BitWord identity and canonical binary state. The BitWord structure tells it which BitGroups occur and in what order. Each BitGroup resolves a registered Formula family. The Reader defines the exact result field for each placement. The calculation becomes a deterministic traversal of already-resolved contracts. Authoring may require intelligence. Execution should require as little intelligence as possible. 2.1 Specification Authority The Semantic Kernel Specification is the canonical construction contract. It fixes the Bits, BitGroups, exact placement, Reader addresses, composition boundaries, and semantic roles that define the Kernel. An Airtable implementation, native runtime, generated interface, or AI explanation is conformant only insofar as it resolves to that exact construction. This prevents a display or runtime from silently becoming a second semantic authority. If a display variant looks different, it still binds to the same canonical placements. If an implementation links the wrong Formula or consumes the wrong width, the implementation is wrong; the runtime must not repair it by guessing. 3. Canonical Computational Stack The computational stack can be expressed as a short deterministic chain: CANONICAL READ PATH Binary Record -> ordered BitGroup slices -> registered Formula -> exact SK Reader fields -> decoded ordered state Bits remain the primitive state. BitGroups remain reusable mathematical structures. Formula records identify the calculation used to decode a BitGroup. The BitWord provides canonical composition and order. The SK Reader provides the exact computational output fields for those placements. The decoded state can then be consumed by automation, rules, models, displays, or external systems without semantic guessing. Layer Owns Must not own Bits Primitive binary state and contribution Domain-specific human explanation BitGroups Reusable mathematical grouping BitWord-specific semantic meaning Formula Deterministic decode behavior Live record state or display layout BitWord Exact ordered composition and placement Alternate display state SK Reader Exact decoded result fields Independent semantic reinterpretation Reader Semantics Human-facing explanation Canonical calculation authority D/E/F/G Projection of canonical state Independent truth 4. Formula Table Architecture The Formula Table stores reusable calculation identities. A Formula is not a copy of the current Bits and does not need to contain one handwritten equation for every width. It identifies a deterministic mathematical family that a runtime script or compiler can execute against the Bit slice supplied by the current BitGroup occurrence. For example, SCALAR-N can be implemented as one general rule: SCALAR(N) = sum(B_i * 2^(i-1)) for i = 1..N. The same interpreter can therefore read SCALAR-1, SCALAR-4, SCALAR-8, SCALAR-16, SCALAR-32, and any other registered width supported by the runtime. The Formula record supplies identity; the BitGroup supplies width and current Bits. Figure 2. Formula family reuse. Many registered SCALAR widths can share one deterministic SCALAR-N interpreter. 4.1 Formula Records Are Reusable Blocks The value of the Formula layer comes from reuse. A single mathematical primitive may occur across TIME, COLOR, MUSIC, MOVEMENT, geometry, simulation, robotics, and other domains while carrying entirely different semantic roles in each Reader. The mathematical operation is stored once and invoked wherever the corresponding BitGroup occurs. The BitGroup should link to its Formula so it can compile directly. At runtime, the exact Reader placement resolves that same registered mathematical behavior. The Formula relationship is therefore mathematical infrastructure rather than domain metadata. 4.2 Minimal Formula Vocabulary Formula family Generic role Example behavior SCALAR-N Unsigned weighted scalar Sum N binary positions with powers-of-two weights MASK-N Independent membership mask Preserve N independent Boolean memberships TWOS-N Signed two's-complement value Decode N-bit signed integer Future families Other reusable mathematics Added only when a genuinely new computational primitive is required The architecture does not require every Formula family to be encoded in its name forever. A record may carry whatever minimum parameters the interpreter genuinely needs. The governing principle is that algorithmic duplication should not grow simply because semantic placements grow. 5. The BitWord as Its Own Parser Once the Specification establishes exact BitGroup order and width, the BitWord structure already contains the information needed to segment its binary state. A separate canonical table of start positions, end positions, or display-order numbers would duplicate information that can be derived deterministically from the structure itself. Figure 3. Structural parsing. The ordered BitGroup widths determine the binary slices directly. The runtime begins at the first Bit. It consumes the width of the first registered BitGroup, executes that Formula, advances by that width, and repeats. The start offset of each later placement is simply the cumulative width of the placements before it. Derived offsets may be cached by an implementation for performance, but they do not need to become a second semantic authority. CANONICAL ORDER LAW If a component is intended to be structurally first, author it first in the BitWord. Do not maintain a second field that instructs readers to traverse the canonical structure backwards. 6. SK Reader Architecture The SK Reader is the executable decoding contract for a BitWord. It is built from the exact BitGroup placements established by the Specification. Each Reader field corresponds to one exact placement and resolves the Formula required to decode that placement. Results are written back to the Reader in the same canonical order. This leads to a useful lifecycle distinction: a BitWord can exist as a formally specified structure before its runtime Reader is implemented, but it is not runtime-complete until a conformant Reader exists. The Reader is what converts canonical binary state into addressable decoded values that other runtime systems can consume. READER COMPLETION LAW A BitWord is runtime-complete only when its SK Reader can deterministically decode every required placement defined by the Specification. Figure 4. TIME-128 as a deterministic Reader. Every semantic lane follows the same recurring pattern: exact slice -> registered Formula -> exact Reader field. 6.1 TIME as an Example of Structural Simplicity TIME-128 is semantically rich, but its runtime read path is repetitive. MASK-10, MASK-3, MASK-12, MASK-6, SCALAR-1, TWOS-17, SCALAR-5, SCALAR-6, and the remaining registered BitGroups are simply consumed in their specified order. The runtime does not need to understand months, weeks, phases, years, precision, offsets, or fine ticks in order to calculate their values. That distinction is important for scale. Semantic complexity can grow through composition while the runtime continues to execute a small number of familiar mathematical primitives. 7. Reader Semantics: Human Meaning Without Runtime Dependency A third helper structure is required because the mathematical result of a BitGroup does not, by itself, tell a person what that result means in a particular Semantic Kernel. SCALAR-6 can represent a minute, second, intensity, quantity, coordinate, or many other concepts. That domain meaning belongs beside the Reader placement rather than inside the reusable mathematical primitive. The Reader Semantics table should remain deliberately minimal. Each corresponding Reader field is a Long Text field containing whatever human-facing explanation is useful for that exact placement. A field may contain a single word, a definition, a table of enumerated meanings, several examples, caveats, units, or effectively a short essay. It is still one semantic payload for one exact Reader address. Figure 5. Machine and human read paths. The machine completes the calculation without parsing semantic prose; the human-facing explanation is an optional branch from the exact Reader address. 7.1 Why One Long Text Field Is Enough Additional metadata fields should not be created merely because the information can be normalized. If a semantic name, unit, display order, Spec reference, or interface relationship is already inherent in the Reader field, BitWord structure, linked Spec, or D/E/F/G system, duplicating it across very large numbers of placements creates cost and drift without adding new information. The scalability rule is therefore simple: store new information only when it cannot already be deterministically recovered from canonical structure. Reader Semantics stores the irreducible human explanation introduced when a generic mathematical block is assigned a particular semantic role. Figure 6. The three-table Reader Helper: reusable Formula records, exact SK Reader fields, and a parallel Long Text semantic layer. 8. D/E/F/G Projection Architecture D/E/F/G are display structures. They consume canonical data; they do not define it. This clarification is central because it allows CERBERUS to support many human interfaces over the same functioning Semantic Kernel without duplicating state or changing the computational contract. Scope Canonical structure displayed Role D BitGroup Display one exact BitGroup through one registered panel variant E Compound BitGroup Coordinate the display of an exact compound BitGroup structure F BitWord Display one complete BitWord G Compound BitWord Display a complete Compound BitWord while preserving constituent boundaries Figure 7. D/E/F/G projection scopes. Each display level resolves downward to canonical data and SK Readers. 8.1 Displays Are Assembled, Not Inferred A D display can be linked directly to a BitGroup and may have multiple registered variants. SCALAR-4, for example, could be shown through different human controls while every variant consumes the same decoded SCALAR-4 value. E, F, and G continue the same principle at larger structural scopes. Display structure should be authored in the order it is intended to be read and must remain conformant to the exact placements defined by the SK Specification. A separate display-order metadata field is unnecessary when the display assembly itself already expresses the order. Presentation can vary, but it cannot silently redefine the BitWord. 9. Display Variants and Projection Equivalence Once a BitWord has a functioning SK Reader, alternate displays can be constructed without changing the underlying data contract. TIME-128(a), TIME-128(b), and TIME-128(c) can therefore represent different registered F-level display variants of the same TIME-128 BitWord rather than different TIME encodings. Figure 8. Display Variant Equivalence. Distinct F-level presentations share one canonical TIME-128 BitWord and one SK Reader. PROJECTION EQUIVALENCE LAW Two display variants are functionally equivalent with respect to canonical Semantic Kernel state when they resolve to the same governed underlying structures and Reader addresses. Visual or interaction differences do not establish different semantic state. A variant may be optimized for calendar interaction, compact symbolic reading, engineering inspection, accessibility, mobile input, or another presentation goal. Because the state remains canonical, switching variants is lossless. The system changes the projection, not the data. 10. Deterministic Read and Write Paths 10.1 Read Path The read path is intentionally mechanical. Given a canonical BitWord record, the runtime resolves the exact BitWord structure, walks its BitGroups in order, obtains each registered Formula, executes each calculation against the appropriate Bit slice, and writes the results to the exact SK Reader fields. The requested D/E/F/G display then consumes those values. DETERMINISTIC READ Canonical Bits -> ordered BitGroups -> Formula execution -> exact Reader fields -> selected D/E/F/G projection 10.2 Write Path A display control does not gain authority simply because it can show a Reader value. A user interaction must resolve back to the exact canonical target represented by that panel. The appropriate encoding, Rules, Operators, and other governance determine whether and how the canonical Bits may change. Once the Bits change, the Reader recompiles the state and every conformant display sees the same result. Figure 9. Canonical read/display/write loop. Projection is separate from mutation authority, while Reader Semantics remains an explanatory branch. 11. The AI Boundary The architecture sharply reduces the number of places where AI interpretation is required. AI can help author a new Semantic Kernel, compare a proposed construction with an existing Spec, route natural language through SOLAR, explain a Reader field, assemble documentation, or assist a person in choosing an interface. None of those capabilities require the canonical runtime to ask an AI what a binary string probably means. If a calculation targets an exact Reader address, the runtime already knows which BitGroup and Formula apply. If a human asks what that address means, the system can retrieve the corresponding Reader Semantics Long Text. The AI may communicate that explanation, but it is not responsible for inventing the computational semantics. DETERMINISTIC EXECUTION PRINCIPLE Semantic ambiguity should be resolved while authoring and governing the contract so runtime execution can use exact addresses and deterministic scripts. 12. Scale Through Reusable Cognitive and Computational Primitives The Formula Table changes the scaling characteristics of Semantic Kernels. A system may eventually contain hundreds of thousands, millions, or billions of semantic placements without requiring an equivalent number of algorithms. Most placements can reuse a comparatively small mathematical vocabulary. Growth occurs primarily through composition, semantic assignment, and projection rather than through duplicated computation. Figure 10. Scale through primitive reuse. Large numbers of domain-specific Semantic Kernels and displays can converge on a compact reusable Formula library. This mirrors how experienced users learn the SK library. Once SCALAR-N, MASK-N, TWOS-N, routing, Reader placement, and other primitives are familiar, a large Specification may contain relatively little cognitive novelty. The computer receives the same benefit: familiar mathematical primitives are executed repeatedly while new meaning is introduced through exact placement and semantic composition. Human cognition compresses by recognizing reusable primitives. CERBERUS computation compresses by executing reusable primitives. 13. Airtable as a Reference Implementation The initial proof-of-concept can be implemented directly in Airtable using linked records and an automation script. A Formula record identifies a decoder such as SCALAR-4 or SCALAR-6. A test record supplies Bit values. The script reads the selected Formula, evaluates the relevant Bits, and writes the numeric result. A BitWord-oriented Reader can then retrieve those results in its assembled order. Figure 11. From the Airtable proof-of-concept to the generalized deterministic runtime pattern. The significance of the experiment is not that Airtable can add powers of two. It is that the experiment demonstrates the complete architectural direction: a registered Formula identity, a binary input, deterministic code, an exact output field, and ordered synthesis. The same pattern can be generalized from a two-row test into a Reader compiler for complete BitWords. 13.1 Reference Script Behavior A SCALAR-N interpreter can derive N from the selected Formula identity, read the corresponding Bit fields, validate that each input is binary, calculate the weighted sum, and write the result. The same script branch can therefore support many scalar widths. Additional Formula families can be added as new deterministic branches rather than as unique code for every semantic placement. IMPLEMENTATION DISCIPLINE The Formula registry is reusable and stateless with respect to live BitWord records. Current Bits belong to the canonical record or exact occurrence being decoded; Formula identity supplies the reusable function. 14. Portability Beyond Airtable Airtable is a useful proving environment because linked records, fields, automation triggers, and scripts make the architecture visible. It is not the architecture itself. The canonical model can be reimplemented in a native database, local runtime, game engine, robotics controller, simulation platform, distributed service, or another storage system because the essential contract is portable. At minimum, a target runtime needs stable identities, ordered structures, binary state, Formula resolution, Reader output addressing, and projection bindings. The execution model remains the same even when the storage representation or programming language changes. This is consistent with the broader CERBERUS principle that canonical semantic structure should remain independent from any single runtime substrate. 15. Conformance and Failure Determinism requires strict conformance. A runtime must be able to verify that the BitWord it is reading matches the Specification-derived construction it expects. Width disagreement, misplaced BitGroups, missing Formula bindings, duplicate or missing Reader fields, or projection bindings that target the wrong structures are implementation errors. Figure 12. Conformance boundary. A valid implementation proceeds deterministically; a structural disagreement fails explicitly instead of being repaired by inference. Fail-closed behavior is important precisely because AI is available elsewhere in the system. A probabilistic component may be capable of inventing a plausible interpretation of malformed state, but doing so would destroy the value of the canonical contract. The correct response to a structural mismatch is an explicit error, validation issue, or unresolved state. 16. Architectural Laws Law Statement Spec Authority Law The Semantic Kernel Specification determines canonical Bits, BitGroups, placement, Reader topology, and composition. Formula Reuse Law Reusable mathematical behavior is defined once and applied wherever the corresponding registered BitGroup occurs. Reader Completion Law A BitWord is runtime-complete only when a conformant SK Reader can decode every required placement. Canonical Order Law Computational traversal follows the exact structural order established by the BitWord Specification. Deterministic Decode Law Registered binary state is decoded through deterministic Formula execution rather than probabilistic semantic inference. Semantic Independence Law Human-facing semantic prose is not required for machine calculation. Projection Non-Ownership Law D/E/F/G displays consume canonical state but do not own or redefine it. Projection Equivalence Law Display variation does not establish semantic variation when the underlying governed structures and Reader addresses are unchanged. No Redundant Metadata Law Information deterministically recoverable from canonical structure should not be duplicated as an independent authoritative field. Traceability Law Every decoded or displayed value must resolve to an exact canonical placement and Bit state. Rebuildability Law Given canonical registry state, Formula definitions, Reader construction, and display contracts, the runtime and interfaces can be regenerated. Fail-Closed Conformance Law Structural disagreement is surfaced as an error rather than repaired through inference. 17. Bootstrap and SK Authoring Implications This architecture is useful in Bootstrap because it explains why the larger Semantic Kernel corpus does not imply a correspondingly complex runtime. Once the reader understands the separation between Specification, reusable mathematics, Reader compilation, human semantics, and projection, many later SKs become variations on the same small set of primitives. It also sharpens the implementation handoff for future SK Specs. An authored Kernel should not merely describe its domain semantics. It should be implementable as exact Bits and BitGroups, compile through registered Formula families, populate an SK Reader, expose one Long Text semantic payload for each human-facing Reader placement, and bind to conformant D/E/F/G projections. The Specification remains the authority tying these structures together. 17.1 Recommended Build Sequence Stage Build action 1 Author or revise the SK Specification and freeze exact Bits, BitGroups, placement, Reader addresses, and composition. 2 Normalize reusable Bits and BitGroups in BIGFOOT. 3 Link each mathematical BitGroup to its registered Formula family. 4 Build the SK Reader in exact canonical order and verify complete Formula resolution. 5 Populate the parallel Reader Semantics Long Text only where human explanation is required. 6 Build D variants for BitGroups, E variants for Compound BitGroups, F variants for BitWords, and G variants for Compound BitWords. 7 Validate that every projection resolves to exact canonical Reader addresses and that no display owns duplicate state. 8 Run conformance tests and publish the implementation handoff. Conclusion The central breakthrough of this architecture is not a particular Airtable script. It is the recognition that a Semantic Kernel can be authored richly and executed simply. The Specification resolves semantic ambiguity in advance. Reusable Formula families handle the binary mathematics. The SK Reader provides exact computational destinations. Reader Semantics provides human explanation without becoming a runtime dependency. D/E/F/G provides interchangeable displays without creating alternate state. The resulting system is deterministic where determinism matters and flexible where human presentation benefits from variation. A complex BitWord is no longer something an AI must read and guess. It is a compiled semantic contract: split the Bits exactly, execute the registered mathematics, write the result to the exact Reader field, and project the same canonical state through whichever conformant display variant is required. CLOSING INVARIANT Store mathematics once. Store canonical structure once. Store each genuinely new semantic distinction once. Derive and project everything else. Revision Record Version Date Status Summary 0.1 August 2026 Bootstrap Candidate Initial formalization of Formula Tables, SK Readers, Reader Semantics, deterministic BitWord compilation, and D/E/F/G display projection variants.