11 - CERBERUS_SK_Reader_Architecture_v2.0.docx

CERBERUS FORMAL SPECIFICATION SK Reader Architecture Deterministic Decoding, Typed Semantic Addressing, and Bounded Operator Scope Specification v2.0 Field Declaration Architecture CERBERUS Semantic Kernel System Status Verified Release Primary Function Deterministic resolution of Semantic Kernel BitWords into typed, addressable semantic state Supersedes SK Reader: Explanation & Export, Specification v1.0 Reader Invariant SK Reader ID + canonical binary word -> deterministically resolvable semantic state CORE PRINCIPLE The BitWord owns ordered state composition. BitGroup Formulas own mathematics. The SK Reader deterministically binds decoded results to contextual semantic addresses. BOSS supplies registered vocabulary; Rules and Operators govern mutation. No layer may infer authority it has not been given. Verified Release Abstract The CERBERUS SK Reader is the deterministic execution surface that converts a registered Semantic Kernel BitWord into ordered semantic placements without inventing meaning at runtime. A BitWord already declares its constituent BitGroups and their canonical order. Each BitGroup resolves through its registered Formula, and the resulting value is written to the exact contextual placement defined by the SK Reader. The result is a typed, addressable semantic state that can be inspected by humans, consumed by AI or software, projected through interfaces, serialized for transport, and targeted by governed operations. This specification upgrades the earlier Explanation & Export model by moving the Reader closer to the structural center of the Semantic Kernel architecture. Explanation, CRT serialization, one-click export, and round-trip reconstruction remain valid downstream uses, but they no longer define the Reader. The Reader now serves as the bridge between compact BitWord state and exact semantic addresses, while reusable BitGroup Formula families centralize mathematics and BOSS supplies the operational vocabulary used to speak about resolved state. The specification further defines typed operator scope. SCALAR, MASK, TWOS, and future BitGroup classes expose different legal operational territories. An operator cannot act merely because its symbol exists in BOSS: the target Reader placement, underlying BitGroup type, operator contract, and governing Rules must jointly admit the operation. A valid mutation is constrained to its declared target scope and MUST preserve all state outside that scope unless a wider composite scope is explicitly registered. The architecture is runtime-independent. The same Reader contract can execute in Airtable, Excel, a custom runtime, a local application, or another conforming system. A portable Reader package can therefore provide offline deterministic semantic decoding from only a Reader identity and binary word. Conformance is proven with golden vectors, exact expected outputs, operator fixtures, unchanged-state checks, and state-lossless round trips. Document Conventions The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are normative when capitalized. Examples marked illustrative demonstrate the mechanism without freezing an unapproved production allocation. Reader addresses such as A1 or B1 refer to semantic placements within a specific SK Reader. Physical bit addresses refer to locations in canonical binary storage. Those coordinate systems are related by registered bindings but are not interchangeable. SCALAR-N, MASK-N, and TWOS-N are representative BitGroup families used throughout this document. The exact Formula library and the final operator-compatibility matrix remain registry-governed and may expand as the full Semantic Kernel corpus is populated and audited. Contents 1. Purpose and Scope 2. Architectural Principle and Ownership 3. Minimal Reader Contract 4. BitWord Composition and Canonical Reader Order 5. Width-Driven Binary Partitioning 6. Formula Architecture and Contextual Meaning 7. Deterministic Reader Execution 8. Universal Three-Field Reader 9. Reader Addressing Model 10. Typed Semantic Surface 11. Operator Compatibility and Authority 12. Bounded Mutation Scope 13. Read Path and Write Path 14. SCALAR Operational Contract 15. MASK Operational Contract 16. TWOS Operational Contract 17. BitWords as Semantic Operands 18. BitWord Sentences and Expression Boundary 19. Portable Reader Packages and Offline Execution 20. Universal Reader Test Table 21. Conformance and Golden Vectors 22. Downstream Reader Consumers 23. State-Lossless Export and Round Trip 24. Airtable Prototype and Runtime Independence 25. Validation, Security, and Failure Modes 26. Design Laws 27. Migration from v1.0 28. Implementation Templates Formal Summary Glossary 1. Purpose and Scope The SK Reader is the canonical deterministic decoding and semantic-addressing layer for a Semantic Kernel instance. Its job is to accept an exact binary Word under a known Reader identity, resolve the Word's ordered BitGroup composition, apply the registered Formula associated with each BitGroup, bind each decoded result to its exact Reader placement, and expose the resulting semantic state without changing the source Word. 1.1 Goals Convert a canonical binary Word into exact ordered semantic placements without runtime inference. Reuse BitGroup mathematics through registered Formula identities rather than duplicating calculations in every SK Reader. Distinguish mathematical decoding from contextual semantic meaning. Provide stable Reader addresses that humans, AI, interfaces, and registered operations can target. Constrain operator scope according to BitGroup type, target semantics, operator contracts, and governing Rules. Permit portable and offline Reader execution from a compact Reader package. Support deterministic conformance testing, lossless state reconstruction, and downstream documentation or export. 1.2 Non-goals This document does not redefine Bit, BitGroup, BitWord, or Compound BitWord identity. It does not specify the complete BOSS operator vocabulary or final operator-compatibility matrix. It does not define the complete grammar of future BitWord sentences. It does not make DARTBOARD, CRT, SOLAR, MIRROR, Templates, Airtable, Excel, or AI authoritative over Semantic Kernel state. It does not grant the Reader mutation authority. Rules and registered Operators remain responsible for state change. BOUNDARY The Reader answers: What does this exact Word mean here, at these exact semantic addresses? It does not answer: What am I allowed to change? 2. Architectural Principle and Ownership CERBERUS separates canonical state, reusable mathematics, contextual meaning, symbolic vocabulary, authorization, mutation, and presentation. The Reader is strong precisely because it does not absorb the responsibilities of its neighbors. Figure 1 places the Reader inside that ownership stack. Figure 1. SK Reader in the CERBERUS Ownership Stack Owner Primary responsibility Must not silently absorb Bits Atomic binary positions. BitGroup or Reader semantics. BitGroups Reusable mathematical structures and typed state forms. Context-specific SK meaning. Bit Formula Deterministic conversion for a BitGroup family. Reader placement or mutation authority. BitWord Exact ordered composition of constituent BitGroups. Reader-specific prose or UI behavior. SK Reader Decode result placement and contextual semantic addressability. Rule authorization or direct mutation. BOSS Stable symbolic and operational vocabulary. Automatic permission to execute an operation. Rules / Operators Permission, preconditions, exact read/write scope, and state mutation. Semantic redefinition of the Reader target. D/E/F/G and DARTBOARD Display and interface projection. Canonical semantic state. CRT / Export Serialization, packaging, traversal, and transmission. Source-of-truth status. SOLAR Language and alias routing into registered identities. Runtime invention of binary meaning. 2.1 Authoring intelligence, runtime determinism Authoring a new SK may require careful design, comparison, human judgment, AI assistance, testing, and revision. Once the contracts are registered, runtime execution SHOULD require as little interpretive intelligence as possible. The Reader is therefore a compilation target for prior semantic design work, not a place where that design work is repeated on every read. 3. Minimal Reader Contract The most compact external Reader request contains two essential pieces of information: the identity of the Reader contract and the canonical binary Word to be interpreted under that contract. Everything else required for decoding is resolved through registered structure. Figure 2. Minimal Reader Contract Minimal Contract SK Reader ID + Canonical Binary Word = Deterministically Resolvable Semantic State 3.1 Why the Reader identity is required Binary alone is not self-describing. The same sequence of zeros and ones can represent different structures under different BitWord contracts. Reader identity anchors the binary to the intended SK, BitWord composition, BitGroup formulas, contextual placements, and Reader semantics. A conforming implementation MUST fail closed when the supplied Reader identity and Word width are incompatible. 3.2 Consumer simplicity The consumer does not need to traverse the Registry graph manually. The graph may be complex during authoring, but the Reader contract compresses that complexity into a stable execution surface. This is the architectural reason a three-field UI and a portable offline Reader can remain extremely simple while still resolving complex records. 4. BitWord Composition and Canonical Reader Order A BitWord is an ordered composition of BitGroups. That composition is already the authoritative structural sequence needed by the Reader. The Reader MUST derive canonical decode order from the Word's registered constituent order rather than maintain a second independently authoritative ordering system. Figure 3. BitWord Composition Determines Reader Order CANONICAL ORDER LAW Canonical Reader order is derived from canonical BitWord composition. A teaching or presentation view MAY rearrange visual sections, but it MUST retain enough address information to preserve the underlying order and bindings. 4.1 Reader completion A BitWord is runtime-complete when a conforming SK Reader can deterministically resolve every required constituent placement. Reserved, conditional, or intentionally hidden groups remain part of the contract even when a compact display omits them. 4.2 Reader order is not physical address identity The Word's ordered composition determines the sequence of groups. Physical offsets can be derived cumulatively from their widths, but semantic Reader addresses remain a separate coordinate system. This distinction becomes essential when Operators target semantic roles rather than raw offsets. 5. Width-Driven Binary Partitioning The Reader partitions an incoming Word by consuming the registered widths of its constituent BitGroups in canonical order. No delimiter is required inside the binary. No semantic label is required to discover boundaries. The registered composition itself is the parser. Figure 4. Width-Driven Binary Partitioning 5.1 Cumulative offset rule For a Word composed of groups G1...Gn with widths w1...wn, the first group consumes the first w1 bits, the second begins immediately after w1 and consumes w2 bits, and so on. An implementation MAY cache derived start/end offsets for performance or debugging, but those cached offsets MUST NOT become a competing source of structural truth. Illustrative Partition SCALAR-4 | MASK-6 | TWOS-8 | SCALAR-4 widths: 4 | 6 | 8 | 4 binary: 1011 | 101001 | 11100101 | 0110 5.2 Coverage invariant Every bit in a canonical Word MUST be consumed exactly as declared by its composition, including reserved or extension regions. A Word-length mismatch, gap, overlap, or incompatible extension MUST produce an explicit validation failure unless the SK contract formally defines the condition. 6. Formula Architecture and Contextual Meaning The Reader separates reusable mathematics from SK-specific meaning. A BitGroup Formula answers how the bits calculate. The SK Reader answers where the resulting value belongs and what that placement means in this Kernel. Figure 5 demonstrates why those responsibilities cannot be collapsed. Figure 5. Mathematics and Meaning Are Separate Layer Question answered Example BitGroup identity What mathematical structure is this? SCALAR-7 Formula How do these bits decode? 1010110 -> 86 Reader placement Where does this result belong? A1, B2, or C1 Reader semantics What does the value mean here? Sweetness, Speed, Opacity 6.1 Formula reuse If two placements use the same mathematical BitGroup family, they SHOULD reuse the same Formula identity unless a genuinely different mathematical contract exists. This avoids hundreds of locally rewritten decode formulas and makes Formula correctness independently testable. 6.2 Semantic rebinding Reusing SCALAR-7 does not make Sweetness, Speed, and Opacity semantically equivalent. It only means they share a bounded mathematical representation. Contextual meaning remains registered at the Reader placement. A new semantic distinction should therefore not force the creation of a new Formula when the mathematics is unchanged. 6.3 Representative Formula families Family Structural interpretation Typical decode output SCALAR-N Unsigned bounded scalar. 0 through 2^N - 1, optionally scaled by a declared higher-level contract. MASK-N Independent participation or membership bits. Set/list/Boolean participation state rather than one scalar magnitude. TWOS-N Signed two's-complement state. Negative, zero, or positive integer under the declared width. The Formula library is intentionally open. Additional families should be extracted from recurring SK structures after corpus population rather than invented preemptively. 7. Deterministic Reader Execution A conforming Reader executes a simple deterministic pipeline. Domain complexity is stored in Registry contracts; runtime code applies the same sequence to every compatible Kernel. Figure 6 shows the reference execution path. Figure 6. Deterministic Reader Execution Pipeline 7.1 Reference algorithm Resolve the SK Reader identity and its governed BitWord. Validate Word width, version, and serialization convention. Load constituent BitGroups in canonical BitWord order. Consume registered widths to partition the binary Word. Resolve and apply the Formula linked to each BitGroup. Write each decoded result to its exact Reader placement. Resolve contextual Reader semantics and any display-safe units or labels. Compile the ordered semantic output and attach validation status. Do not mutate source state during any read operation. 7.2 No inference The Reader MUST NOT choose a Formula because it looks plausible, infer a missing label from nearby fields, repair malformed bits silently, or reinterpret an unknown version. Unknown contracts are preserved or rejected according to explicit compatibility rules; they are never guessed. 8. Universal Three-Field Reader The full execution pipeline can be exposed through an intentionally tiny human-facing surface. The universal Reader interface has only three conceptual fields: Reader selection, binary code insertion, and output. Hidden implementation fields, formulas, automations, or tables may exist behind the interface, but they are not part of the conceptual contract. Figure 7. Three-Field Universal Reader Visible field Responsibility SK Reader Selection Select the exact Reader identity and therefore the governed BitWord, constituent BitGroups, formulas, placements, and semantics. Binary Code Insertion Supply the exact current canonical state to be decoded. Output Display the ordered resolved semantic state and validation result. OPERATIONAL COMPRESSION Choose the Reader. Paste the ones and zeroes. Read the answer. 8.1 AI use An AI can consume the same surface. Given a portable Reader package, the AI does not need to rediscover the BitWord graph before interpreting the immediate state. This reduces context requirements while preserving deterministic semantics. 9. Reader Addressing Model A resolved Reader exposes semantic coordinates such as A1, A2, A3, or B1. These addresses identify contextual placements inside a specific Reader. Physical bit addresses identify locations in the stored Word. The two systems are deterministically bound but must not be conflated. Figure 8. Reader Address vs Physical Bit Address Coordinate Owns Example use Reader address Contextual semantic placement. Target the Speed placement of a movement Reader. Physical bit address Exact binary storage location. Read or rewrite the bits underlying that placement. Binding Registered relationship between the two. Resolve Reader target to exact BitGroup slice. 9.1 Address scope A Reader address is meaningful only inside its Reader identity. A3 in one SK MAY mean Speed while A3 in another SK means something completely different. External systems SHOULD therefore treat Reader identity and Reader address as a composite target, even if the serialization syntax for that composite is defined elsewhere. 10. Typed Semantic Surface Once a BitWord has been decoded into Reader placements, those placements form a typed semantic surface. The underlying BitGroup type constrains which classes of operation are even meaningful against the state. Figure 9 shows representative operational territories for SCALAR, MASK, and TWOS. Figure 9. Typed Semantic Surface 10.1 Type is eligibility, not permission A compatible type establishes that an operation can make mathematical or structural sense. It does not establish that the operation is authorized in the current SK, Reader role, object state, Ruleset, or runtime context. Type checking is therefore an early gate, not the final authority gate. 10.2 Representative operational territories Type Natural operational territory Examples SCALAR Bounded numeric mathematics, comparison, thresholding, scaling, selection by magnitude. +, -, <, >, =, min/max when registered MASK Membership, inclusion/exclusion, Boolean/set structure, participation, selected structural relations. intersection, union, NOT/complement, membership when registered TWOS Signed arithmetic, inversion, displacement, directional change, signed composite behavior. negation, signed addition/subtraction, bounded signed transforms when registered These are illustrative families, not a complete compatibility matrix. Exact compatibility MUST be registry-governed. 11. Operator Compatibility and Authority BOSS gives CERBERUS a stable vocabulary for mathematical, logical, structural, graph, temporal, and other operators. The existence of a BOSS identity does not grant that symbol universal execution rights. A legal operation emerges only when the requested operator, target Reader placement, target type, operator contract, and governing Rules agree. Figure 10. Operator Compatibility Gate 11.1 Compatibility dimensions Dimension Question BOSS operator identity What operation or relation is being requested? Reader target Which exact contextual placement is the operand or mutation target? BitGroup type Is the operation meaningful for this mathematical representation? SK / Reader role Is this operator admitted for this semantic role? Rules / state Are current preconditions, permissions, bounds, and lifecycle conditions satisfied? Registered Operator What exact read/write scope and mutation procedure executes the change? VOCABULARY IS NOT AUTHORITY BOSS can say what +, intersection, implication, mapping, or directed adjacency mean. It does not by itself say that the current target may be changed. 12. Bounded Mutation Scope A valid operation acts only within its declared scope. For a local BitGroup operation, the target slice may change while surrounding groups remain bit-for-bit identical. Wider operations are allowed only when the registered Operator explicitly declares a wider scope. Figure 11. Bounded Local Mutation 12.1 Untouched-state preservation When an Operator targets one BitGroup, every bit outside that scope MUST remain unchanged unless the Operator contract explicitly includes those additional bits. This law makes local operations auditable and prevents a semantic command from becoming an implicit whole-Word rewrite. 12.2 Recompilation after mutation After a governed mutation writes exact binary state, the Reader SHOULD rerun from the canonical Word rather than patch its displayed output directly. Re-reading ensures that dependent displays, validation, and semantic outputs all derive from the new source state. 13. Read Path and Write Path Reader architecture becomes safest when read and write are visibly different operations. Reading resolves state. Writing begins with an instruction, routes through BOSS vocabulary and a semantic target, checks compatibility and Rules, invokes a registered Operator, mutates exact binary state, and then allows the Reader to recompile. Figure 12. Read Path vs Write Path Path Core sequence Authority Read Binary -> BitWord -> BitGroups -> Formula -> Reader -> resolved state Pure projection; no mutation authority. Write Instruction -> BOSS -> Reader target -> type check -> Rules -> Operator -> binary mutation -> Reader rerun Governed state change. 13.1 Interface writes DARTBOARD or another interface MAY initiate a write by targeting a Reader placement, but the interface does not bypass the write path. The same registered Operator and Rules remain authoritative whether the command originated from a slider, a form, an AI instruction, an automation, or another runtime. 14. SCALAR Operational Contract SCALAR BitGroups expose bounded numeric state. A SCALAR-N Formula decodes the registered binary slice into a nonnegative integer domain from 0 through 2^N - 1. Higher-level SK semantics may attach units, resolution, normalization, thresholds, or other meaning without changing the underlying SCALAR mathematics. Figure 13. SCALAR Bounded Operation 14.1 Worked SCALAR-7 example The illustrative fixture decodes 0101010 as 42, applies registered addition of 5, obtains 47, and re-encodes the result as 0101111. Only the target SCALAR-7 slice is rewritten. 14.2 Boundary behavior An arithmetic operation that would exceed the representable domain MUST follow the declared boundary policy. Clamp, wrap, reject, saturate, widen, or route-to-error behavior cannot be inferred merely from the SCALAR type. The governing Operator or Rule contract must define it. 14.3 Comparisons and queries SCALAR placements can also participate in non-mutating comparisons and set-selection expressions when compatible operators are registered. A query such as Protein > threshold may inspect a SCALAR placement without changing any bits. 15. MASK Operational Contract MASK BitGroups represent independent participation states. Although the storage is binary, the group MUST NOT be treated as a single unsigned magnitude unless a separate explicit interpretation is registered. Each bit normally corresponds to an independently meaningful membership or participation position. Figure 14. MASK Structural Operation 15.1 Structural and relational operations Because MASK positions are independently addressable, registered operators can express intersection, union, exclusion, complement, membership, Boolean gating, or other structural participation operations. The resulting state remains a MASK and can be re-encoded directly into the same bounded set of positions. 15.2 Semantic labels remain external to the Formula The MASK Formula resolves active and inactive positions. The Reader placement or linked semantic registry tells the runtime what each position means in the current SK. A1, A2, and A3 may therefore represent very different memberships in different Readers even when the MASK width is identical. 16. TWOS Operational Contract TWOS BitGroups expose signed state through two's-complement decoding. This creates a natural foundation for signed magnitude, displacement, inversion, directional offset, assistance versus load, and other composite operations whose meaning depends on negative, zero, and positive values. Figure 15. TWOS Signed Operation 16.1 Signed decode and re-encode A conforming operation decodes the source TWOS slice under its declared width, applies an admitted signed operation, validates the result against the representable domain and governing Rules, and re-encodes the new signed value. The semantic meaning of positive and negative states is still owned by the Reader role, not by two's-complement mathematics itself. 16.2 Composite scope TWOS does not imply that every composite operation is automatically legal. It indicates a signed representation capable of participating in such operations when the SK and Operator contracts admit them. A future compatibility registry may therefore distinguish unary negation, signed addition, vector-like composition, directional inversion, and other operation classes explicitly. 17. BitWords as Semantic Operands Once a Reader identity and binary Word are sufficient to resolve a bounded semantic state, the pair can function as a compact semantic operand. The operand can remain compressed during transport while still being deterministically expandable through its Reader. Figure 16. BitWord as Semantic Operand Conceptual Definition Semantic Operand := <SK Reader ID, Binary Word> 17.1 BOSS expressions BOSS operators can relate or operate on resolved operands when compatibility contracts permit. Mathematical, logical, structural, and graph expressions can therefore reference compact binary-backed records without expanding every field into prose first. Examples include intersection, implication, mapping, assignment, adjacency, and other registered vocabulary. 17.2 Operand independence Each operand remains independently decodable under its own Reader. Combining operands in an expression does not flatten their contracts into one universal schema. The expression describes a relationship or requested operation between stable semantic identities. 18. BitWord Sentences and Expression Boundary The Reader architecture makes complex BitWord sentences possible, but this specification intentionally stops short of defining the final sentence grammar. The important architectural result is that resolved Words can participate as typed operands and BOSS can supply stable operational vocabulary between them. Capability Boundary [Word A] Operator [Word B] Operator [Word C] Each Word remains independently Reader-resolvable. Each Operator remains a registered BOSS identity. Execution still requires type compatibility, Rules, and registered Operator scope. 18.1 What this specification establishes A compact Reader packet can stand in for a complex record. Reader placements can be addressed inside that record without whole-record expansion. Operators can be checked against the mathematical type and semantic role of the target. Expressions can preserve operand identity while describing relationships across records. The eventual language can grow through composition rather than requiring an unbounded set of primitive binary encodings. 18.2 What remains future work Precedence, grouping, arity, serialization, variable binding, expression typing, error propagation, compound scope, sentence transport format, and a complete operator compatibility matrix belong in a future BitWord language specification or related system contracts. 19. Portable Reader Packages and Offline Execution Reader execution does not require Airtable, an internet connection, or AI once the deterministic contracts have been compiled into a portable package. Airtable can remain the editable canonical registry while a stable snapshot acts as an execution artifact elsewhere. Figure 17. Portable Offline Reader 19.1 Portable package contents Component Required role Reader identities Resolve the requested SK Reader and version. BitWord compositions Provide canonical constituent order and widths. BitGroup Formula library Decode each mathematical structure deterministically. Reader bindings and semantics Place decoded values and explain their contextual meaning. Validation contracts Check width, version, reserved states, and other invariants. Optional operator compatibility data Support local type and authority checks where the portable runtime is permitted to execute operations. 19.2 Airtable and Excel roles Airtable is the canonical authoring and registry environment in the current prototype. Excel can serve as a compiled portable Reader implementation. The Excel file does not become semantic authority merely because it executes offline. If the canonical Registry evolves, a new versioned package can be compiled while older snapshots remain valid for historical data governed by their version. 19.3 Runtime pluralism The same package model can support a custom desktop application, embedded runtime, local database, simulation engine, or other software. Excel is therefore one convenient implementation surface, not a defining dependency. 20. Universal Reader Test Table The three-field Reader naturally becomes a universal engineering console. A test record supplies a Reader identity, binary input, and expected output. The runtime produces actual output and compares the two. Operator fixtures extend the same model by specifying a target, requested operator, and expected final binary state. Figure 18. Universal Reader Test Table 20.1 Minimal decode fixture Decode Fixture Reader ID Binary Word Expected Reader Output 20.2 Minimal operator fixture Operation Fixture Reader ID Initial Binary Word Target Reader Address BOSS Operator + Parameters Expected Final Binary Word Expected Final Reader Output 20.3 Visible interface vs hidden machinery The conceptual Test Table can remain extremely small even if Airtable uses hidden lookups, helper formulas, scripts, automations, or linked records to implement it. Those implementation details are replaceable. The test contract is stable. 21. Conformance and Golden Vectors Every SK Reader SHOULD ship with canonical test vectors that prove structure resolution, Formula decoding, placement binding, type compatibility, mutation scope, and round-trip behavior. Because addresses and binary state are exact, conformance can be tested at bit-level precision. Test Required result All-zero Word Every placement resolves according to its declared zero, presence, reserved, and validation semantics. All-one Word Maximum, signed, mask, and reserved states decode without silent reinterpretation. Single-bit walk Each bit affects only the intended group/placement unless the contract explicitly defines coupled semantics. Width boundaries Minimum, maximum, zero, sign boundaries, and quantization edges decode exactly. Reader ordering Output order matches canonical BitWord composition. Formula reuse Identical BitGroup structures decode identically across Readers before contextual semantic binding. Valid operator/type Registered operation produces the exact expected local result. Invalid operator/type Incompatible operation is rejected without mutation. Untouched-state preservation All bits outside declared write scope remain bit-for-bit identical. Boundary operation Overflow/out-of-range behavior follows the registered policy. Round trip Export -> reconstruct -> Word comparison returns bit-for-bit identity. CONFORMANCE QUESTION The Test Table asks one foundational question: Can CERBERUS read and locally operate on its own language correctly? 22. Downstream Reader Consumers Once the Reader has resolved canonical state, many consumers can use the same result without becoming semantic authority. Figure 19 shows this fan-out. Figure 19. Reader Output Fan-Out Consumer Use of Reader output Human display Inspect resolved semantic state in compact, detailed, debugging, or teaching views. AI Explain, compare, summarize, route, or compose from deterministic Reader output. DARTBOARD Project exact Reader targets into interactive UI elements. CRT / Export Serialize ordered semantic state and selected context into portable text packages. API / Runtime Exchange typed state with other deterministic systems. Documentation Populate governed templates or generate explanations from exact registered state. 22.1 Projection is not truth A projection can omit detail, change visual form, translate labels, or choose another medium while still referencing the same Reader state. Human display, AI prose, a DARTBOARD slider, a CRT text package, and a document figure are therefore different projections of one semantic source, not independent definitions of the source. 23. State-Lossless Export and Round Trip The earlier Reader specification correctly established that losslessness depends on preserving exact canonical state plus the interpretation contract rather than relying on a human-readable display string. That principle remains unchanged and is now positioned downstream of Reader execution. Figure 20. State-Lossless Export and Round Trip 23.1 State-lossless minimum Kernel / Reader identity and version sufficient to locate the correct interpretation contract. Exact canonical binary Word under a declared serialization convention. Word size and compatibility metadata needed to reject accidental reinterpretation. Optional embedded Reader Manifest when the receiving runtime does not already possess the contract. 23.2 Round-trip requirement A State-Lossless package imported by another conforming runtime MUST reconstruct the exact source Word. If no semantic mutation occurs, exporting again MUST preserve the bitstate. Formatting, UI layout, or explanatory wording may differ across Reader versions when the semantic contract remains compatible, but the canonical Word comparison is exact. 24. Airtable Prototype and Runtime Independence The current CERBERUS prototype can implement the architecture transparently in Airtable. The BitGroup table links each reusable mathematical structure to its Formula; the BitWord table stores ordered constituent composition; the SK Reader table provides contextual placements and semantics; and a small Test Table supplies Reader identity plus binary state to the deterministic decode pipeline. 24.1 Prototype responsibilities Airtable surface Prototype role Bit Table Canonical primitive binary identities and structural references. BitGroup Table Reusable groups, widths, type identity, and Formula linkage. Bit Formula Table Reusable deterministic calculations such as SCALAR-N, MASK-N, TWOS-N and future families. BitWord Table Ordered composition of BitGroups. SK Reader Table Exact semantic placements, Reader identity, and contextual meaning. Test Table Reader selection, binary input, output, hidden execution helpers, and conformance fixtures. 24.2 No implementation lock-in A future custom runtime may pack Words directly, compute Formula families in code, cache offsets, and expose high-performance operation routing. Those optimizations do not change the semantic contract. The Reader architecture is defined by deterministic relationships between registered identities, not by Airtable formulas or interface layout. 25. Validation, Security, and Failure Modes 25.1 Reader identity or width mismatch A Reader expecting one Word contract MUST reject incompatible widths or versions unless an explicit prefix, translation, or extension contract permits partial reading. Shifting offsets to make a malformed Word fit is prohibited. 25.2 Unknown Formula or BitGroup type A runtime MUST NOT substitute a similar Formula or infer type from width. It may preserve the unknown state, request the missing contract, route to a compatible implementation, or fail with an explicit uninterpreted status. 25.3 Invalid operator targeting If an operator is semantically incompatible with the target type, not admitted by the Reader role, outside the Operator's declared scope, or prohibited by current Rules, the runtime MUST reject the request without mutating canonical state. 25.4 Scope escape After every bounded operation, conformance tooling SHOULD compare untouched regions before and after execution. Unexpected changes outside the declared write scope are a critical failure even when the final displayed value appears correct. 25.5 Untrusted portable packages Portable Reader packages SHOULD distinguish locally trusted canonical snapshots from externally supplied manifests. Formula execution should use a constrained declarative vocabulary or trusted implementation rather than arbitrary executable code. A package may describe semantics without being granted authority to mutate a canonical Base. 25.6 AI interpretation boundary AI may help author, explain, compare, or route Reader output. It MUST NOT be used as a substitute for missing deterministic contracts when exact binary meaning or mutation is required. 26. Design Laws Law Normative statement Canonical Order Law The BitWord's registered constituent order is the canonical Reader decode order. Width-Driven Parsing Law Registered BitGroup widths determine binary partition boundaries; the binary contains no implied delimiters. Formula Reuse Law Reusable mathematics is stored once in BitGroup Formula identities rather than rewritten per SK. Math/Meaning Separation Law A decoded mathematical value does not acquire contextual meaning until bound to an SK Reader placement. Reader Completion Law A Word is runtime-complete when every required placement can be deterministically decoded by a conforming Reader. Reader Address Law Reader coordinates identify semantic placements; physical bit addresses identify storage positions; a registered binding connects them. Typed Operation Law Operator compatibility is constrained by the target BitGroup type and Reader role. Vocabulary/Authority Separation Law A BOSS operator identity defines meaning but does not by itself authorize execution. Bounded Mutation Law A registered operation cannot modify state outside its declared write scope. Untouched-State Preservation Law All non-target state remains bit-for-bit unchanged unless wider scope is explicitly declared. No Reader Mutation Authority Law The Reader resolves state and targets; Rules and Operators govern mutation. No Inference Law Unknown formulas, versions, types, or bindings are never guessed in exact execution. Runtime Independence Law A conforming implementation may execute the same Reader contract in Airtable, Excel, custom code, or another runtime. Projection Separation Law Human display, AI output, CRT, documentation, and UI are projections of resolved state rather than new semantic authorities. Round-Trip Law A state-lossless package reconstructs the exact original Word when no semantic mutation occurs. 27. Migration from v1.0 SK Reader: Explanation & Export v1.0 established several durable principles: deterministic decoding, separation of reading from mutation, runtime independence, human-readable explanation, lossless export, round-trip reconstruction, and conformance testing. Those principles remain valid. Version 2.0 changes where the Reader sits in the architecture and removes machinery that is now better owned elsewhere. v1.0 concept v2.0 treatment Reader as explanation/export layer Expanded: Reader is the deterministic semantic execution and addressing surface; explanation/export are downstream consumers. Reader Group order maintained in the Reader Simplified: canonical order is derived from registered BitWord composition. Decode details stored heavily with Reader Groups Normalized: reusable mathematics moves to BitGroup Formula identities. Bit ranges manually central to Reader definition Derived: structural offsets come from constituent order and widths; physical addresses remain available for audit. Human-readable explanation Retained as one projection of resolved Reader state. Reader does not mutate Retained and strengthened through explicit read/write path separation. CRT and one-click export Retained but demoted to downstream serialization behavior. Lossless export / Reader Manifest / round trip Retained as portable state and interoperability mechanisms. Generic Reader generation Strengthened: BitWord + BitGroups + Formulas + Reader bindings form a compiler-friendly contract. Operational language implication Expanded: Reader packets can act as typed semantic operands governed by BOSS vocabulary and operator scope. ARCHITECTURAL UPGRADE v1.0 explained how to make compact bitstate legible and portable. v2.0 explains how that same state becomes a typed, addressable operational surface. 28. Implementation Templates 28.1 Reader Contract Template Template 1 READER ID: READER VERSION: SK / KERNEL ID: BITWORD ID: WORD SIZE: CANONICAL CONSTITUENT ORDER: READER PLACEMENTS: VALIDATION PROFILE: DOWNSTREAM PROJECTION PROFILE(S): 28.2 Reader Placement Template Template 2 READER ADDRESS: SEMANTIC NAME: BITGROUP ID: FORMULA ID: <resolved through BitGroup> PHYSICAL BINDING: <derived / inspectable> UNIT / BASIS / LABEL SOURCE (if applicable): ALLOWED OPERATOR CLASSES: <registry-governed> DESCRIPTION: VALIDATION RULES: 28.3 Operator Target Template Template 3 BOSS OPERATOR ID: TARGET READER ID: TARGET READER ADDRESS: EXPECTED BITGROUP TYPE: READ SCOPE: WRITE SCOPE: PARAMETERS: PRECONDITIONS / RULES: BOUNDARY POLICY: EXPECTED POST-MUTATION VALIDATION: 28.4 Golden Vector Template Template 4 TEST ID: READER ID: INPUT BINARY: EXPECTED READER OUTPUT: OPTIONAL TARGET: OPTIONAL OPERATOR: EXPECTED FINAL BINARY: EXPECTED FINAL OUTPUT: EXPECTED UNCHANGED REGIONS: PASS / FAIL: 28.5 Portable Reader Package Manifest Template 5 PACKAGE ID / VERSION: READER IDENTITIES: BITWORD COMPOSITIONS: BITGROUP FORMULA LIBRARY: READER BINDINGS + SEMANTICS: VALIDATION CONTRACTS: OPTIONAL OPERATOR COMPATIBILITY DATA: BUILD SOURCE / CANONICAL SNAPSHOT: INTEGRITY METADATA (optional): Formal Summary NORMATIVE COMPRESSION A conforming SK Reader MUST resolve a known Reader identity and canonical binary Word through the registered BitWord composition, constituent BitGroup widths, BitGroup Formula identities, and contextual Reader placements without inference or mutation. The resulting placements form a typed semantic surface. Registered BOSS vocabulary may describe or request operations against that surface, but execution requires compatible target type, admitted Reader role, governing Rules, and a registered Operator with explicit scope. Any bounded mutation MUST preserve all state outside its declared write scope. The same Reader contract MAY execute in Airtable, Excel, a custom runtime, or another conforming implementation, and state-lossless packages MUST permit exact bit-for-bit reconstruction when no mutation occurs. The architecture therefore compresses complex semantic records twice: first into Reader-resolvable binary state, and then into stable symbolic relationships and operations over that state. This gives CERBERUS a path from compact BitWords to inspectable, testable, portable, and eventually sentence-like semantic computation without requiring runtime guesswork. Glossary Term Definition Bit The atomic binary position used by a registered BitWord contract. BitGroup An ordered set of Bits interpreted together as one reusable mathematical or structural unit. BitGroup Formula Registered deterministic conversion associated with a BitGroup family, such as SCALAR-N, MASK-N, or TWOS-N. BitWord An ordered composition of BitGroups forming a bounded binary semantic word. BOSS CERBERUS symbolic and semantic registry that stores stable operator identities, symbols, contextual uses, and related operational vocabulary. Bounded Mutation A governed state change whose write scope is explicitly declared and cannot silently escape its target region. Canonical Word The exact binary state governed by one SK/BitWord contract. Compatibility Gate The combined check that considers operator identity, Reader target, BitGroup type, Reader role, Rules, and Operator contract before execution. Contextual Meaning The semantic interpretation assigned to a decoded value by its exact SK Reader placement. CRT CERBERUS Rollup Traversal; a downstream mechanism for ordered traversal and text serialization of registered semantic material. DARTBOARD CERBERUS runtime/interface layer that projects registered Reader targets into interactive controls or views. Golden Vector A canonical Reader test fixture containing known input state and exact expected output, optionally including an operator and expected post-mutation state. MASK-N BitGroup family whose Bits represent independent participation or membership positions rather than one scalar magnitude. Minimal Reader Contract The external pairing of SK Reader identity plus canonical binary Word sufficient to resolve semantic state when the Reader package is available. Operator Registered executable mechanism with declared read/write scope, parameters, preconditions, and mutation behavior. Physical Bit Address Exact location in canonical binary storage. Portable Reader Package Versioned snapshot containing enough Reader, BitWord, Formula, binding, and validation information to execute decoding outside the canonical authoring runtime. Projection A human, visual, textual, API, AI, or interface representation derived from resolved Reader state without becoming semantic authority. Reader Address Contextual semantic coordinate within one SK Reader, such as A1 or B1. Reader Binding Registered relationship connecting a Reader placement to the BitGroup slice that supplies its value. Reader Completion Condition in which every required placement of a BitWord can be deterministically resolved by a conforming SK Reader. Reader Semantics Human-readable contextual meaning associated with an exact Reader placement. Rules Governed conditions that determine whether an operation is permitted in the current context. SCALAR-N BitGroup family representing a bounded nonnegative numeric state from 0 through 2^N - 1. Semantic Operand Conceptual pair of Reader identity and binary Word that can be independently resolved and then participate in compatible semantic expressions. SK Reader Versioned deterministic contract that resolves a BitWord into ordered, typed, contextually meaningful semantic placements. SOLAR CERBERUS lexical and language-routing system used to resolve natural-language terms and aliases into registered semantic identities. State-Lossless Export Portable package that preserves enough information to reconstruct the exact canonical Word. TWOS-N BitGroup family representing signed two's-complement state under a declared width. Untouched-State Preservation Requirement that all bits outside a declared mutation scope remain bit-for-bit unchanged. Document Control Item Value Document CERBERUS | SK Reader Architecture Version 2.0 Document class Formal Architecture and Operational Specification Primary predecessor SK Reader: Explanation & Export v1.0 Figure set 20 verified figures Release status Verified Release Verification Semantic, structural, figure, and rendered-document conformance verified. This version is the verified release of the SK Reader Architecture specification.