MORSE-64_Formal_System_Specification_v1.0.docx

MORSE-64 FORMAL SYSTEM SPECIFICATION Prefix-Invariant Morse Transmission Core and Multi-Modal Projection Layer Specification Version 1.0 Architecture CERBERUS Semantic Kernel / Bitlinking Word Family MORSE-32 -> MORSE-64 -> higher-resolution extensions Date 12 August 2026 REFERENCE PRINCIPLE MORSE-32 is the canonical transmitted-signal semantic core. MORSE-64 preserves MORSE-32 byte-for-byte as B000-B031 and appends a 32-bit projection layer that specifies how the same Morse signal is timed, rendered, performed, observed, or evaluated across audio, radio, light, haptic, mechanical, digital, spatial, and other modalities. Status: Formal reference specification for implementation, testing, education, and evolution. Document Control Field Specification Document Title MORSE-64 Formal System Specification Specification Version 1.0 Primary Subject Compact Morse signal encoding plus prefix-invariant projection semantics Canonical Base Word MORSE-32, 32 bits / 4 bytes Projection Word MORSE-64, 64 bits / 8 bytes Reference Morse Standard ITU-R M.1677-1, International Morse code Normative Language MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used as requirements terms. Related CERBERUS Specifications Semantic Kernel Bitlinking; Semantic Prefix Invariance; CERBERUS Matryoshka Integrated Architecture Abstract MORSE-64 defines a compact, deterministic semantic word family for representing Morse signals and projecting them into physical or perceptual forms. The first 32 bits, MORSE-32, encode the transmitted Morse signal as a registered semantic token with an exact sentinel-based binary tree path, token identity, class, role, profile, and Kernel version. The appended 32 bits form the MORSE-64 Projection Layer: a bounded description of unit duration, time basis, timing profile, output medium, expression mode, intensity, and fidelity. The architecture separates the invariant signal from the variable projection. The letter A remains the same MORSE-32 token whether it is heard as a tone, flashed as light, felt as a haptic pulse, keyed mechanically, represented geometrically, or rendered by a teaching interface. Bitlinks can therefore bind once to stable MORSE-32 semantic addresses while MORSE-64 chooses how that meaning is expressed in a particular environment. CORE RESULT MORSE-64 = MORSE-32 transmitted-signal semantics + 32 bits of projection semantics. Higher-resolution descendants may append further bits without moving or reinterpreting any existing address. Contents Ref. Section 1 Purpose and Scope 2 Normative Concepts and Terminology 3 Design Principles 4 Canonical Word Architecture 5 MORSE-32 Transmission Core 6 Canonical Symbol and Signal Registry 7 MORSE-64 Projection Layer 8 Projection Execution Model 9 Semantic Kernel Bitlinking 10 Semantic Prefix Invariance and Resolution Expansion 11 Worked Examples 12 Runtime, Serialization, and Storage 13 Conformance, Validation, and Testing 14 Governance, Profiles, and Extensions 15 Implementation Templates 16 Applications 17 Design Principles Summary 18 Conclusion A Appendix A - Complete Bit List B Appendix B - Binary Examples C Appendix C - Registered Values and Reserved Ranges G Glossary I Subject Index R References 1 Purpose and Scope This specification defines MORSE-32 and MORSE-64 as a prefix-invariant Semantic Kernel family. MORSE-32 encodes the atomic signal intended for transmission. MORSE-64 appends the information required to project that signal through a selected medium and timing/performance context. The design is intended to support ordinary text-to-Morse conversion, human keying, machine transmission, multimodal accessibility, education, simulation, Bitlink-driven interfaces, and later scientific-resolution extensions without requiring migration of existing bits. 1.1 In Scope A 32-bit transmitted-signal core with a 9-bit sentinel-prefixed Morse tree code. An 8-bit Token ID that distinguishes semantic tokens even when two tokens share the same physical dot/dash sequence. Typed Symbol Class, Role, Profile, and Version fields. A 32-bit projection extension containing timing, medium, expression, intensity, and fidelity semantics. Canonical International Morse mappings for letters, figures, punctuation, miscellaneous signs, and procedural signals aligned to ITU-R M.1677-1. Deterministic decoding, projection, Bitlinking, serialization, extension, and conformance behavior. Prefix-preserving interoperability between MORSE-32, MORSE-64, and future larger words. 1.2 Out of Scope Replacing the ITU definition of International Morse code or claiming this specification is an ITU standard. Encoding an arbitrary audio waveform, RF waveform, raw sensor stream, or every measured timing sample directly inside 64 bits. Treating case, font, handwriting, or source-document typography as part of the transmitted Morse signal unless carried by a separate text/source model. Guessing the meaning of unresolved or malformed signals. Fail-closed behavior is preferred. Forcing community, historical, experimental, or fictional Morse variants into the canonical ITU profile without explicit profile identity. 2 Normative Concepts and Terminology Term Definition MORSE-32 The first 32 bits. Canonical transmitted-signal semantic core. MORSE-64 MORSE-32 plus a 32-bit Projection Layer. SignalCode9 Nine-bit field containing a left-zero-padded sentinel-prefixed dot/dash path. Sentinel Leading binary 1 placed before the dot/dash path so sequence length remains recoverable. Dot / Dash Dot maps to binary 0; dash maps to binary 1 after the sentinel. Token ID Eight-bit semantic identity that disambiguates tokens sharing a physical sequence. Projection A replaceable rendering or performance of the semantic signal through a medium. Timing Profile Registered Model describing how dot units map to dash and gap durations. Medium Audio, RF/carrier, light, haptic, mechanical, digital, spatial, or other renderer class. Bitlink Declared connection from a Kernel state, field, element, or transition to another semantic or perceptual consumer. Semantic Prefix Invariance Requirement that a published prefix remain byte-for-byte stable inside conforming higher-resolution descendants. Fidelity Compact normalized indication of signal/performance/interpretation quality; not a substitute for detailed measurement data. 3 Design Principles Principle Meaning Signal Before Projection The Morse token is authoritative; audio, light, haptic, geometry, and other outputs are projections of that token. Exact Binary Path The physical Morse sequence is recoverable directly from SignalCode9 without consulting a display string. Semantic Disambiguation Token ID and Symbol Class distinguish identical signal patterns used for different semantic purposes. Minimum Sufficient Resolution Use MORSE-32 when only the signal matters; use MORSE-64 when projection/performance matters; use larger words only when additional resolution is required. Prefix Invariance Higher-resolution words append; they do not migrate, renumber, or reinterpret prior bits. One Signal, Many Modalities Multiple renderers may subscribe to one MORSE-32 signal without creating competing truth stores. State Small, Contract Rich Keep live words compact and store detailed Models, Rules, profile definitions, and resource bindings in Registries. AI Proposes, Runtime Governs Natural-language or AI routing may select tokens and projection profiles, but deterministic Kernel contracts validate the packed word and rendering behavior. 4 Canonical Word Architecture 4.1 MORSE-32 Core Layout Bits Group Width Purpose B000-B008 SignalCode9 9 Sentinel + dot/dash tree path; exact transmitted pattern. B009-B016 TokenID8 8 Semantic token identity; 256 possible registered values. B017-B020 SymbolClass4 4 Letter, figure, punctuation, procedural, extended, custom, etc. B021-B023 Role3 3 Ordinary atomic token or stream/control role. B024-B027 Profile4 4 Canonical ITU or explicitly registered extension/historical/custom profile. B028-B031 Version4 4 MORSE-32 contract version. v1.0 uses 0001. Figure 1. MORSE-32 transmitted-signal layout MORSE-32 (32 bits / 4 bytes) B000 B008 B009 B016 B017 B020 B021 B023 B024 B027 B028 B031 | SignalCode9 | TokenID8 |Class4| Role3 |Profile4|Version4| 4.2 MORSE-64 Extension Layout Bits Group Width Purpose B000-B031 MORSE-32 32 Inherited transmitted-signal semantic core. B032-B041 UnitDuration10 10 Base dot-unit scalar, 0-1023. B042-B043 TimeBasis2 2 Microseconds, milliseconds, 10 ms units, or external Model. B044-B047 TimingProfile4 4 Registered timing/performance grammar. B048-B051 Medium4 4 Projection medium / renderer class. B052-B055 ExpressionMode4 4 Generated, keyed, observed, decoded, training, simulated, etc. B056-B059 Intensity4 4 Normalized projection magnitude, 0-15. B060-B063 Fidelity4 4 Normalized quality/confidence score, 0-15. Figure 2. Prefix-invariant MORSE-64 construction MORSE-64 (64 bits / 8 bytes) [ B000 ---------------- B031 ][ B032 ------------------------------ B063 ] [ MORSE-32 ][ PROJECTION-32 ] MORSE-32 is never rewritten when projection detail is appended. 4.3 Complete Bit List Bit Group Definition B000 SignalCode9 SignalCode9 field bit 0 (MSB-first across B000-B008). B001 SignalCode9 SignalCode9 field bit 1 (MSB-first across B000-B008). B002 SignalCode9 SignalCode9 field bit 2 (MSB-first across B000-B008). B003 SignalCode9 SignalCode9 field bit 3 (MSB-first across B000-B008). B004 SignalCode9 SignalCode9 field bit 4 (MSB-first across B000-B008). B005 SignalCode9 SignalCode9 field bit 5 (MSB-first across B000-B008). B006 SignalCode9 SignalCode9 field bit 6 (MSB-first across B000-B008). B007 SignalCode9 SignalCode9 field bit 7 (MSB-first across B000-B008). B008 SignalCode9 SignalCode9 field bit 8 (MSB-first across B000-B008). B009 TokenID8 TokenID8 field bit 0 (MSB-first across B009-B016). B010 TokenID8 TokenID8 field bit 1 (MSB-first across B009-B016). B011 TokenID8 TokenID8 field bit 2 (MSB-first across B009-B016). B012 TokenID8 TokenID8 field bit 3 (MSB-first across B009-B016). B013 TokenID8 TokenID8 field bit 4 (MSB-first across B009-B016). B014 TokenID8 TokenID8 field bit 5 (MSB-first across B009-B016). B015 TokenID8 TokenID8 field bit 6 (MSB-first across B009-B016). B016 TokenID8 TokenID8 field bit 7 (MSB-first across B009-B016). B017 SymbolClass4 SymbolClass4 field bit 0. B018 SymbolClass4 SymbolClass4 field bit 1. B019 SymbolClass4 SymbolClass4 field bit 2. B020 SymbolClass4 SymbolClass4 field bit 3. B021 Role3 Role3 field bit 0. B022 Role3 Role3 field bit 1. B023 Role3 Role3 field bit 2. B024 Profile4 Profile4 field bit 0. B025 Profile4 Profile4 field bit 1. B026 Profile4 Profile4 field bit 2. B027 Profile4 Profile4 field bit 3. B028 Version4 Version4 field bit 0. B029 Version4 Version4 field bit 1. B030 Version4 Version4 field bit 2. B031 Version4 Version4 field bit 3. B032 UnitDuration10 UnitDuration10 field bit 0. B033 UnitDuration10 UnitDuration10 field bit 1. B034 UnitDuration10 UnitDuration10 field bit 2. B035 UnitDuration10 UnitDuration10 field bit 3. B036 UnitDuration10 UnitDuration10 field bit 4. B037 UnitDuration10 UnitDuration10 field bit 5. B038 UnitDuration10 UnitDuration10 field bit 6. B039 UnitDuration10 UnitDuration10 field bit 7. B040 UnitDuration10 UnitDuration10 field bit 8. B041 UnitDuration10 UnitDuration10 field bit 9. B042 TimeBasis2 TimeBasis2 field bit 0. B043 TimeBasis2 TimeBasis2 field bit 1. B044 TimingProfile4 TimingProfile4 field bit 0. B045 TimingProfile4 TimingProfile4 field bit 1. B046 TimingProfile4 TimingProfile4 field bit 2. B047 TimingProfile4 TimingProfile4 field bit 3. B048 Medium4 Medium4 field bit 0. B049 Medium4 Medium4 field bit 1. B050 Medium4 Medium4 field bit 2. B051 Medium4 Medium4 field bit 3. B052 ExpressionMode4 ExpressionMode4 field bit 0. B053 ExpressionMode4 ExpressionMode4 field bit 1. B054 ExpressionMode4 ExpressionMode4 field bit 2. B055 ExpressionMode4 ExpressionMode4 field bit 3. B056 Intensity4 Intensity4 field bit 0. B057 Intensity4 Intensity4 field bit 1. B058 Intensity4 Intensity4 field bit 2. B059 Intensity4 Intensity4 field bit 3. B060 Fidelity4 Fidelity4 field bit 0. B061 Fidelity4 Fidelity4 field bit 1. B062 Fidelity4 Fidelity4 field bit 2. B063 Fidelity4 Fidelity4 field bit 3. 5 MORSE-32 Transmission Core 5.1 SignalCode9: Sentinel-Based Binary Tree Encoding SignalCode9 is the exact atomic transmitted pattern. It uses the natural binary structure of Morse: DOT = 0 and DASH = 1. A leading sentinel 1 is prepended before the Morse elements. The resulting bit string is then left-padded with zeros to exactly nine bits. The sentinel makes the path length recoverable even when the Morse sequence begins with one or more dots. Figure 3. SignalCode9 encoding Encoding rule 1. Start with sentinel: 1 2. Append one bit per Morse element: DOT = 0 DASH = 1 3. Left-pad with 0 until the field is 9 bits wide. Examples E . -> 10 -> 000000010 T - -> 11 -> 000000011 A .- -> 101 -> 000000101 N -. -> 110 -> 000000110 S ... -> 1000 -> 000001000 O --- -> 1111 -> 000001111 ERROR ........ -> 100000000 -> 100000000 Nine bits are sufficient for the atomic signal set in ITU-R M.1677-1 because the longest listed signal is the eight-dot Error signal. SignalCode9 = 000000000 is reserved for non-signal/control use and MUST NOT represent an ordinary atomic Morse signal. 5.2 Natural Binary Morse Tree Figure 4. First levels of the Morse binary tree 1 ROOT / \ DOT 0 DASH 1 / \ 10 E 11 T / \ / \ 100 I 101 A 110 N 111 M / \ / \ / \ / \ 1000 S 1001 U 1010 R 1011 W 1100 D 1101 K 1110 G 1111 O The stored 9-bit field is the same tree address left-padded with zeros. 5.3 TokenID8: Exact Semantic Identity SignalCode9 answers what physical dot/dash pattern is transmitted. TokenID8 answers what registered semantic token the sender or decoder means. This distinction is necessary because International Morse reuses some patterns for more than one semantic role. For example, K and the procedural Invitation to Transmit both use -.-; X and the multiplication sign both use -..-. DISAMBIGUATION LAW Two MORSE-32 words MAY share SignalCode9 while remaining semantically distinct through TokenID8 and SymbolClass4. A decoder MUST NOT infer semantic equivalence solely from a shared dot/dash path. 5.4 SymbolClass4 Value Class 0000 Null / Unassigned 0001 Letter 0010 Figure 0011 Punctuation 0100 Miscellaneous sign 0101 Procedural signal 0110 Boundary / Control 0111 Composite source sign 1000 Extended alphabet 1001 Historical 1010 Custom / Community 1011 FASK / Fictional 1100-1111 Reserved 5.5 Role3 Value Role 000 Ordinary atomic signal 001 Word boundary/control 010 Line boundary/control 011 Message start 100 Message end 101 Composite continuation / expansion context 110 Reserved 111 Custom registered role Role3 describes stream or operational use without changing the physical signal identity. A cross/addition signal may therefore retain its token while Role3 indicates that it is being used as a message-end marker in a particular workflow. Implementations SHOULD keep operational interpretation explicit rather than silently overloading punctuation semantics. 5.6 Profile4 Value Profile 0000 ITU International / M.1677-1 canonical profile 0001 Registered language extension 0010 Historical Morse profile 0011 Amateur / community registered profile 0100 Educational profile 0101 Experimental profile 0110 Custom registered profile 0111 FASK / fictional profile 1000-1111 Reserved for future profile families 5.7 Version4 Version4 identifies the MORSE-32 semantic contract. This specification assigns 0001 to MORSE-32 v1.x. Prefix-preserving compatible clarifications MAY retain the same version where bit meanings do not change. Any change that reinterprets an existing published bit or value is non-conforming and requires a new Kernel identity or explicit translation rather than silent reuse. 6 Canonical Symbol and Signal Registry The tables in this section align the canonical ITU profile with ITU-R M.1677-1. MORSE-64 is not an ITU Recommendation; it is a CERBERUS semantic encoding that uses the ITU signal mappings as the canonical v1 reference profile. Token IDs below are MORSE-32 registry assignments created by this specification. 6.1 Letters Symbol Morse SignalCode9 Token ID Token Binary A .- 000000101 0x01 00000001 B -... 000011000 0x02 00000010 C -.-. 000011010 0x03 00000011 D -.. 000001100 0x04 00000100 E . 000000010 0x05 00000101 F ..-. 000010010 0x06 00000110 G --. 000001110 0x07 00000111 H .... 000010000 0x08 00001000 I .. 000000100 0x09 00001001 J .--- 000010111 0x0A 00001010 K -.- 000001101 0x0B 00001011 L .-.. 000010100 0x0C 00001100 M -- 000000111 0x0D 00001101 N -. 000000110 0x0E 00001110 O --- 000001111 0x0F 00001111 P .--. 000010110 0x10 00010000 Q --.- 000011101 0x11 00010001 R .-. 000001010 0x12 00010010 S ... 000001000 0x13 00010011 T - 000000011 0x14 00010100 U ..- 000001001 0x15 00010101 V ...- 000010001 0x16 00010110 W .-- 000001011 0x17 00010111 X -..- 000011001 0x18 00011000 Y -.-- 000011011 0x19 00011001 Z --.. 000011100 0x1A 00011010 É ..-.. 000100100 0x1B 00011011 6.2 Figures Symbol Morse SignalCode9 Token ID Token Binary 0 ----- 000111111 0x20 00100000 1 .---- 000101111 0x21 00100001 2 ..--- 000100111 0x22 00100010 3 ...-- 000100011 0x23 00100011 4 ....- 000100001 0x24 00100100 5 ..... 000100000 0x25 00100101 6 -.... 000110000 0x26 00100110 7 --... 000111000 0x27 00100111 8 ---.. 000111100 0x28 00101000 9 ----. 000111110 0x29 00101001 6.3 Punctuation, Miscellaneous Signs, and Procedural Signals Symbol Name / Role Morse SignalCode9 Token ID Class . Full stop / period .-.-.- 001010101 0x30 0011 , Comma --..-- 001110011 0x31 0011 : Colon / division sign ---... 001111000 0x32 0011 ? Question mark ..--.. 001001100 0x33 0011 ' Apostrophe .----. 001011110 0x34 0011 - Hyphen / dash / subtraction -....- 001100001 0x35 0011 / Fraction bar / division -..-. 000110010 0x36 0011 ( Left parenthesis -.--. 000110110 0x37 0011 ) Right parenthesis -.--.- 001101101 0x38 0011 " Quotation marks .-..-. 001010010 0x39 0011 = Double hyphen / equals -...- 000110001 0x3A 0100 + Cross / addition .-.-. 000101010 0x3B 0100 @ Commercial at .--.-. 001011010 0x3C 0100 × Multiplication sign -..- 000011001 0x3D 0100 [UNDERSTOOD] Understood ...-. 000100010 0x40 0101 [ERROR] Error ........ 100000000 0x41 0101 [INVITE] Invitation to transmit -.- 000001101 0x42 0101 [WAIT] Wait .-... 000101000 0x43 0101 [END WORK] End of work ...-.- 001000101 0x44 0101 [START] Starting signal -.-.- 000110101 0x45 0101 6.4 Non-Atomic Source Signs and Expansion Source Form Canonical Handling % No single atomic Morse signal in the ITU procedure. Normalize to 0/0 before atomic encoding. ‰ Normalize to 0/00 before atomic encoding. ′ When following figures, transmit the apostrophe signal once. ″ When following figures, transmit the apostrophe signal twice. Source typography / case Not part of the Morse signal itself; preserve in a separate text/source model when exact textual round-trip is required. ATOMICITY RULE MORSE-32 encodes one atomic transmitted signal per word. A source character that requires multiple Morse signals MUST be normalized into an ordered sequence of atomic MORSE-32 words before projection. 7 MORSE-64 Projection Layer The MORSE-64 extension does not alter the transmitted token. It specifies how the token is projected, performed, observed, or evaluated. The same first 32 bits may therefore be combined with different Projection-32 tails to generate many equivalent perceptual realizations. 7.1 UnitDuration10 - B032-B041 UnitDuration10 stores an unsigned scalar from 0 to 1023. The scalar represents the base Morse dot unit. A value of zero means unspecified and causes the renderer to obtain timing from a referenced Timing Profile, environment default, or explicit external Model. Values 1-1023 are interpreted through TimeBasis2. 7.2 TimeBasis2 - B042-B043 Value Basis 00 Microseconds 01 Milliseconds 10 10 millisecond units 11 External or higher-resolution time Model TimeBasis2 is intentionally compact. Human Morse normally fits comfortably in millisecond or 10 ms resolution, while electronic systems may use microseconds. Scientific work requiring substantially finer or richer timing semantics SHOULD use a higher-resolution descendant such as MORSE-128 or link to a dedicated timing/measurement Kernel rather than overloading MORSE-64. 7.3 TimingProfile4 - B044-B047 Value Timing Profile 0000 Canonical ITU ratios: dot 1, dash 3, intra-character gap 1, letter gap 3, word gap 7. 0001 Farnsworth-style spacing; canonical element rhythm with expanded character/word spacing. 0010 Extended spacing 0011 Compressed / high-speed registered profile 0100 Human keying / measured performance 0101 Machine exact 0110 Teaching / deliberate 0111 Accessibility / slow 1000 Rhythmic / musical 1001 Custom registered 1010 Observed reconstruction 1011 Experimental 1100 FASK / fictional 1101-1111 Reserved 7.4 Medium4 - B048-B051 Value Projection Medium 0000 Abstract / no renderer 0001 Audio tone 0010 RF / carrier keying 0011 Visible light 0100 Screen / visual UI 0101 Haptic / vibration 0110 Mechanical tap / actuator 0111 Electrical pulse / data line 1000 Gesture / movement 1001 Musical 1010 Spatial / AR / environment 1011 Digital logical stream 1100 Multi-modal 1101 Custom 1110 FASK / fictional 1111 Reserved 7.5 ExpressionMode4 - B052-B055 Value Expression Mode 0000 Template 0001 Generated 0010 Human keyed 0011 Human typed 0100 Observed 0101 Decoded 0110 Reconstructed 0111 Planned 1000 Playback 1001 Training target 1010 Training performance 1011 Machine received 1100 Machine sent 1101 Simulated 1110 Custom 1111 Reserved 7.6 Intensity4 - B056-B059 Intensity4 is a normalized 0-15 magnitude. Zero means unspecified or not applicable. Values 1-15 express increasing projection intensity. The renderer interprets magnitude according to medium: audio amplitude, light brightness, haptic strength, motion emphasis, actuator force class, or another registered scale. Absolute engineering quantities SHOULD be stored in a dedicated Model or higher-resolution measurement word when required. 7.7 Fidelity4 - B060-B063 Fidelity4 is a normalized 0-15 quality/confidence field. Zero means not evaluated. Depending on ExpressionMode4, Fidelity4 may summarize timing accuracy, decode confidence, received-signal quality, performance similarity, or reconstruction confidence. The governing profile MUST document the interpretation. Fidelity4 does not replace raw measurements or evidence. 8 Projection Execution Model 8.1 Canonical Timing Derivation Under TimingProfile4 = 0000, the renderer derives all durations from the base dot unit. ITU-R M.1677-1 defines a dash as three dots, the gap between elements of one character as one dot, the gap between letters as three dots, and the gap between words as seven dots. Figure 5. Canonical timing model Given unit U: DOT duration = 1U DASH duration = 3U Within-character gap = 1U Between-letter gap = 3U Between-word gap = 7U 8.2 Generic Projection Algorithm Resolve MORSE-32 Kernel version and Profile4. Resolve TokenID8 and verify that SignalCode9 matches the registered token under the active profile. Decode SignalCode9 by locating the sentinel and reading each following bit as DOT=0 or DASH=1. Resolve UnitDuration10 and TimeBasis2, then apply TimingProfile4. Resolve Medium4 and target renderer. Apply Intensity4 through the renderer-specific normalized mapping. Render each element and gap in order. If ExpressionMode4 represents an observed or performed signal, evaluate Fidelity4 according to the registered Model. Emit audit / Bitlink events as configured without modifying MORSE-32. 8.3 Medium-Specific Interpretation Medium Projection Behavior Audio tone DOT/DASH become tone-on durations; gaps become silence. RF / carrier DOT/DASH become keyed-carrier on durations; gaps are carrier-off. Visible light DOT/DASH become light-on durations; gaps are dark intervals. Haptic DOT/DASH become vibration pulses; gaps are no-vibration intervals. Mechanical tap DOT/DASH become actuator contact/hold patterns. Screen / UI DOT/DASH may animate glyphs, bars, tree traversal, or timed highlights. Gesture / movement DOT/DASH map to registered short/long movement primitives. Musical DOT/DASH map to registered short/long musical articulations while preserving Morse timing semantics. Multi-modal Several renderers subscribe to the same semantic event in synchronization. 8.4 Projection Is Not Alternate Truth SEPARATION PRINCIPLE MORSE-32 says what signal the token is. MORSE-64 says how that signal is projected or performed in context. Audio samples, light states, vibration states, and UI animations are derivative outputs and MUST NOT silently become independent copies of the Morse semantic truth. 9 Semantic Kernel Bitlinking MORSE-64 is designed to participate directly in CERBERUS Semantic Kernel Bitlinking. Stable fields and values become semantic addresses that can drive renderers, tutorials, interfaces, automations, other Kernels, or logged learning feedback. 9.1 Bitlink Scope by Resolution Address Scope Meaning MORSE-32 address Applies to the signal itself and is inherited by MORSE-64 and every conforming descendant. MORSE-64 address Applies to projection/performance semantics and is inherited only by descendants that preserve the MORSE-64 prefix. Higher-resolution address Applies only where the descendant Kernel declares and preserves that extension. 9.2 Per-Element Bitlinking A renderer may treat the decoded SignalCode9 path as an ordered sequence of semantic elements. The first element, second element, and subsequent elements can trigger short/long audio, light, haptic, movement, or teaching outputs without creating a separate stored state for each modality. Figure 6. Element-level Bitlink projection MORSE-32: A SignalCode9 -> .- Element 1 DOT x UnitDuration x TimingProfile x Medium x Intensity -> short projection event Element 2 DASH x UnitDuration x TimingProfile x Medium x Intensity -> long projection event 9.3 Inherited Bitlinks A Bitlink registered against a MORSE-32 field does not need to be recreated for MORSE-64. For example, a teaching interface bound to TokenID8 = A or to SignalCode9 = .- can consume the first 32 bits of a MORSE-64 token exactly as if it received MORSE-32. The appended Projection Layer may then add medium-specific behavior without changing the original binding. 9.4 Cross-Kernel Translation Cross-Kernel writes SHOULD follow the Semantic Kernel Bitlinking rule that target mutation is proposed through the target Kernel and validated by the target Rules. A MORSE token may trigger a MUSIC, LIGHTING, HAPTIC, SKENE, UI, or game/fantasy Kernel, but semantic equivalence MUST NOT be assumed merely because a renderer happens to use similar values. 10 Semantic Prefix Invariance and Resolution Expansion 10.1 Prefix Invariance Law NORMATIVE LAW Every conforming MORSE-64 word MUST preserve its MORSE-32 prefix byte-for-byte at B000-B031. A future descendant that declares MORSE-64 inheritance MUST preserve B000-B063 byte-for-byte. Expansion occurs by ordered append, not migration. Figure 7. Append-only resolution growth MORSE-32 [B000 ---------------- B031] MORSE-64 [B000 ---------------- B031][B032 ---------------- B063] unchanged appended MORSE-128 (illustrative) [B000 ---------------- B031][B032 ---------------- B063][B064 ---------------- B127] unchanged unchanged new resolution 10.2 Minimum Sufficient Resolution Resolution Use When MORSE-32 Typing, text conversion, compact transmission tokens, ordinary decode, symbol lookup. MORSE-64 Audio/light/haptic projection, human keying, machine sending, training, playback, compact performance state. MORSE-128 or linked measurement data Scientific signal analysis, detailed per-element deviations, carrier/envelope metrics, noise/jitter, richer confidence/evidence. A system MUST NOT instantiate higher resolution merely because it exists. The record should carry the lowest resolution sufficient for the operation while higher-resolution Models remain available for interpretation or analysis. 10.3 Zero-Loss Upward Extension and Transfer A stored MORSE-32 token can become MORSE-64 by appending 32 projection bits. The original four bytes are not translated. A MORSE-64-aware system can transfer the full eight bytes directly to another conforming implementation. A MORSE-32-only reader can consume the first four bytes and ignore or preserve the opaque tail. Downward truncation preserves the prefix but omits extension information; it is therefore a lower-resolution projection, not a lossless representation of the larger word unless the tail is retained elsewhere. 11 Worked Examples 11.1 Example A - Typed Letter A Figure 8. MORSE-32 encoding of A Source semantic token: A Morse signal: .- SignalCode9: 000000101 TokenID8: 00000001 (0x01) SymbolClass4: 0001 Letter Role3: 000 Ordinary Profile4: 0000 ITU Version4: 0001 v1 MORSE-32: 000000101 00000001 0001 000 0000 0001 11.2 Example B - Same Signal, Different Semantics Figure 9. Semantic disambiguation LETTER K SignalCode9: 000001101 MORSE-32: 000001101 00001011 0001 000 0000 0001 INVITATION TO TRANSMIT SignalCode9: 000001101 MORSE-32: 000001101 01000010 0101 000 0000 0001 Physical pattern is identical (-.-). Token identity and class are not. 11.3 Example C - SOS as Three Atomic Tokens Figure 10. SOS as a MORSE-32 sequence S ... -> MORSE-32 token 1 O --- -> MORSE-32 token 2 S ... -> MORSE-32 token 3 The message is an ordered sequence of atomic words. TimingProfile and stream boundaries determine the gaps between them. 11.4 Example D - Haptic Projection of A Take the MORSE-32 A word unchanged. Append a Projection-32 tail with UnitDuration10 = 80, TimeBasis2 = milliseconds, TimingProfile4 = canonical, Medium4 = haptic, ExpressionMode4 = generated, Intensity4 = 10, Fidelity4 = not evaluated. Figure 11. MORSE-64 haptic projection MORSE-32 prefix: 000000101 00000001 0001 000 0000 0001 Projection-32 tail: 0001010000 01 0000 0101 0001 1010 0000 Derived haptic events: DOT -> vibrate 80 ms GAP -> off 80 ms DASH -> vibrate 240 ms 11.5 Example E - Human Keying and Fidelity A training system may retain the target MORSE-32 token while marking ExpressionMode4 = Training Performance and TimingProfile4 = Human Keying / Measured. Detailed observed durations may live in an external measurement record; a registered Model can compare those durations against the target profile and store a compact Fidelity4 result in MORSE-64. 12 Runtime, Serialization, and Storage 12.1 Canonical Serialization Bit addresses are numbered B000 through B063 in this specification. Within each multi-bit field, the specification displays values most-significant-bit first. A packed MORSE-64 value is exactly 8 bytes. A packed MORSE-32 value is exactly 4 bytes. Storage implementations MAY expose individual fields for transparency or pack the word natively, provided field boundaries and meanings remain identical. Textual debug form SHOULD group the word by field boundaries rather than printing an unbroken 64-character string. 12.2 Reference Decode Procedure Figure 12. Reference decoding model decodeMorse32(word): validate Version4 and Profile4 read SignalCode9 find first 1 sentinel for each following bit: 0 -> DOT 1 -> DASH resolve TokenID8 + SymbolClass4 verify token registry agrees with SignalCode9 return typed atomic signal decodeMorse64(word): core = decodeMorse32(B000-B031) projection = decode fields B032-B063 return core + projection contract 12.3 Storage Transparency An Airtable or educational prototype may store SignalCode9, TokenID8, and the Projection fields as visible columns while also calculating the packed word. A production implementation may store the entire word as 4 or 8 bytes. Both are conforming if the semantic addresses, values, and serialization are equivalent. 13 Conformance, Validation, and Testing 13.1 MORSE-32 Conformance Every atomic token has exactly one registered TokenID8 within a profile/version. Every canonical atomic token has a SignalCode9 that decodes to the declared Morse sequence. SignalCode9 000000000 is not used as an ordinary atomic signal. The sentinel must be present and the remaining path must be no longer than eight Morse elements in MORSE-32 v1. TokenID8, SymbolClass4, and SignalCode9 must agree with the active Profile4 Registry entry. Ambiguous physical sequences remain semantically distinguishable by token identity/class rather than being collapsed. 13.2 MORSE-64 Conformance B000-B031 match a conforming MORSE-32 word exactly. Projection fields are decoded according to the declared values and do not modify the MORSE-32 prefix. TimingProfile4 defines deterministic timing behavior or explicitly references a registered Model. Medium4 selects a renderer class; renderer-specific absolute units are documented externally where needed. Intensity4 and Fidelity4 are interpreted according to registered Models and are not silently treated as universal physical units. Observed, simulated, generated, and training states remain distinguishable through ExpressionMode4 and provenance. 13.3 Test Vectors Token Morse Expected SignalCode9 Test E . 000000010 PASS if decode reproduces exact sequence T - 000000011 PASS if decode reproduces exact sequence A .- 000000101 PASS if decode reproduces exact sequence S ... 000001000 PASS if decode reproduces exact sequence O --- 000001111 PASS if decode reproduces exact sequence 0 ----- 000111111 PASS if decode reproduces exact sequence 5 ..... 000100000 PASS if decode reproduces exact sequence Error ........ 100000000 PASS if decode reproduces exact sequence 14 Governance, Profiles, and Extensions 14.1 Canonical ITU Profile Profile4 = 0000 is reserved for the International Morse mappings aligned to ITU-R M.1677-1. Community or experimental additions MUST NOT silently appear inside the canonical profile. If a new mapping is required, use a registered extension profile, a new Kernel version where appropriate, or a separate descendant Kernel. 14.2 Reserved Values Reserved field values are architectural capacity. Implementations MUST NOT assign private meanings to reserved values and still claim canonical conformance. Private experimentation should use the Custom, Experimental, or FASK values explicitly provided for that purpose. 14.3 FASK and Fictional Projection MORSE-64 can participate in fictional or game logic without corrupting the canonical Morse signal. A FASK profile may cause a Morse token to trigger a spell, portal, character animation, or fictional machine behavior through registered Rules and Bitlinks. The underlying MORSE-32 signal remains interpretable as ordinary Morse when the canonical prefix is preserved. 15 Implementation Templates 15.1 MORSE-32 Token Registry Record Field Example Token ID 0x01 Canonical Name A Display Symbol A Signal .- SignalCode9 000000101 Symbol Class Letter Role Ordinary Profile ITU canonical Version 1 Aliases / Notes Optional Bitlinks Registered consumers 15.2 MORSE-64 Projection Record Field Example MORSE-32 Prefix Exact 32-bit token Unit Duration 80 Time Basis Milliseconds Timing Profile Canonical ITU Medium Haptic Expression Mode Generated Intensity 10/15 Fidelity 0 = not evaluated Renderer Resource Haptic profile / device binding Provenance Source action/event TIME-128 Optional event coordinate 16 Applications Application Use Text and messaging Compact translation of typed characters into deterministic Morse atomic tokens. Radio and signaling Projection into keyed carrier or tone timing while keeping the signal identity stable. Accessibility Haptic, visual, audio, or multimodal Morse from the same MORSE-32 prefix. Education Teach symbol, dot/dash path, binary tree traversal, timing, and Bitlink behavior from one semantic atom. Human performance Compare target and keyed/observed signals while preserving the intended token. UI and Skene Animate tree traversal, character tapping, glyphs, lights, or scene actions from stable semantic triggers. Games and FASK Use real Morse as a stable input language while attaching fictional Rules and outputs in explicit profiles/worlds. Automation Map Morse tokens or sequences to registered commands without relying on free-form text parsing. Research extensions Append higher-resolution fields for signal envelope, jitter, noise, carrier, or measurement detail when required. 17 Design Principles Summary Principle Result MORSE-32 = transmitted signal First 32 bits describe the atomic signal and semantic token. MORSE-64 = projection Next 32 bits describe how the signal is expressed or evaluated. Dot = 0, Dash = 1 Natural binary path after a sentinel 1. Token ID disambiguates Identical signal patterns may carry different semantic purposes. Timing is derived Store the base unit and timing profile instead of redundant durations. Modality is replaceable Audio, light, haptic, UI, motion, and other renderers subscribe to one signal. Prefix never migrates Higher resolution appends fields in order. Use only needed resolution Do not carry scientific detail for ordinary text conversion. Bitlinks inherit Bindings to MORSE-32 remain valid inside MORSE-64 descendants. Profiles isolate divergence Historical, custom, community, experimental, and fictional variants remain explicit. 18 Conclusion MORSE-64 converts Morse from a display convention into a compact, typed, prefix-invariant Semantic Kernel family. MORSE-32 provides a four-byte atomic transmitted-signal record whose SignalCode9 is itself a binary address through the Morse tree. Token identity and class preserve semantic distinctions that the physical pattern alone cannot express. MORSE-64 then appends four more bytes that define timing, medium, expression mode, intensity, and fidelity without changing the signal. This separation makes one Morse token reusable across radio, audio, light, haptic, mechanical, digital, spatial, educational, simulation, and fictional systems. The same Bitlinks can remain attached to the stable core while higher-resolution projection or measurement layers are added only when needed. The architecture therefore achieves compact storage, deterministic decode, multimodal portability, transparent learning, and zero-migration semantic growth. FORMAL SUMMARY MORSE-64 = prefix-invariant MORSE-32 transmitted signal + registered Projection-32 timing/performance semantics + deterministic Bitlink-compatible rendering. Appendix A - Complete Bit List This appendix repeats the canonical B000-B063 allocation as a compact implementation reference. Bits Group Width Definition B000-B008 SignalCode9 9 Sentinel-prefixed Morse path, DOT=0, DASH=1. B009-B016 TokenID8 8 Registered semantic token identity. B017-B020 SymbolClass4 4 Token class. B021-B023 Role3 3 Stream/control role. B024-B027 Profile4 4 Morse profile. B028-B031 Version4 4 MORSE-32 version. B032-B041 UnitDuration10 10 Base dot unit scalar. B042-B043 TimeBasis2 2 Time basis. B044-B047 TimingProfile4 4 Timing grammar. B048-B051 Medium4 4 Projection medium. B052-B055 ExpressionMode4 4 Performance/provenance class. B056-B059 Intensity4 4 Normalized projection magnitude. B060-B063 Fidelity4 4 Normalized quality/confidence. Appendix B - Binary Examples Token Morse SignalCode9 MORSE-32 grouped binary A .- 000000101 000000101 00000001 0001 000 0000 0001 K -.- 000001101 000001101 00001011 0001 000 0000 0001 0 ----- 000111111 000111111 00100000 0010 000 0000 0001 5 ..... 000100000 000100000 00100101 0010 000 0000 0001 Period .-.-.- 001010101 001010101 00110000 0011 000 0000 0001 Error ........ 100000000 100000000 01000001 0101 000 0000 0001 Appendix C - Registered Values and Reserved Ranges Field Registry / Reserved Policy Token ID 0x00 reserved/null; 0x01-0x1B letters; 0x20-0x29 figures; 0x30-0x3D punctuation/misc.; 0x40-0x45 procedures; remaining space reserved/extendable by governed registry. SymbolClass4 1100-1111 reserved. Role3 110 reserved; 111 custom registered. Profile4 1000-1111 reserved in v1 except where later governance assigns explicit values. TimingProfile4 1101-1111 reserved. Medium4 1111 reserved. ExpressionMode4 1111 reserved. SignalCode9 000000000 reserved for no atomic signal; codes with no registered token remain invalid under the canonical profile. Glossary Term Definition Atomic signal One indivisible Morse token represented by one MORSE-32 word. Bitlink Registered semantic connection from a Kernel field/state/event to another consumer. Canonical profile Profile4 = 0000 using mappings aligned to ITU-R M.1677-1. Composite source sign Source symbol that must be expanded into multiple atomic Morse signals before transmission. Dash Long Morse element; encoded as binary 1 after the SignalCode9 sentinel. Dot Short Morse element; encoded as binary 0 after the SignalCode9 sentinel. ExpressionMode4 Four-bit class describing how the projection was produced or observed. FASK Fantastically Altered Semantic Kernel / explicitly fictional or alternate-world semantic extension. Fidelity4 Four-bit normalized quality or confidence indicator. Intensity4 Four-bit normalized projection magnitude. Medium4 Four-bit renderer/medium class. Minimum Sufficient Resolution Use the smallest word that carries the semantic depth required by the task. MORSE-32 32-bit transmitted-signal semantic core. MORSE-64 64-bit word containing MORSE-32 plus Projection-32. Prefix Invariance Published lower-resolution bits retain the same addresses and meanings in descendants. Profile4 Four-bit Morse mapping/profile selector in MORSE-32. Projection Replaceable physical or perceptual realization of a semantic Morse signal. Role3 Three-bit stream/control role. Semantic Kernel Versioned fixed-width semantic contract assigning stable meaning to bit addresses and groups. Sentinel Leading 1 placed before the dot/dash path in SignalCode9. SignalCode9 Nine-bit exact atomic Morse tree-path encoding. SymbolClass4 Four-bit semantic token class. TimeBasis2 Two-bit basis for interpreting UnitDuration10. TimingProfile4 Four-bit projection timing grammar selector. TokenID8 Eight-bit registered semantic identity. UnitDuration10 Ten-bit scalar defining the base dot-time unit. Version4 Four-bit MORSE-32 Kernel version field. Subject Index Subject Primary Sections Ambiguous signals 5.3; 11.2 Append-only extension 10.1-10.3 Audio 7.4; 8.3; 16 Binary tree 5.1-5.2 Bitlinking 9 Canonical timing 7.3; 8.1 Composite signs 6.4 Conformance 13 Dash 5.1; Glossary Dot 5.1; Glossary Expression mode 7.5 FASK 14.3; 16 Fidelity 7.7 Figures 6.2 Haptic 7.4; 11.4; 16 Intensity 7.6 ITU profile 6; 14.1; References Letters 6.1 Medium 7.4; 8.3 Minimum Sufficient Resolution 10.2 MORSE-32 4.1; 5; 10 MORSE-64 4.2; 7-10 MORSE-128 10.2 Prefix Invariance 10 Procedural signals 6.3 Projection 7-8 Punctuation 6.3 Role 5.5 Serialization 12 SignalCode9 5.1-5.2 Symbol Class 5.4 Timing Profile 7.3 Token ID 5.3; 6 Training 7.5; 11.5; 16 Unit Duration 7.1-7.2 Versioning 5.7; 10; 14 References ITU-R M.1677-1 (10/2009), International Morse code. International Telecommunication Union, Radiocommunication Sector. Status: In force. CERBERUS Semantic Kernel Bitlinking - Formal Specification for Bit-Addressed Operators, Rule-Governed State Transitions, Cross-Kernel Translation, and Multi-Modal Semantic Triggers, v1.0. Semantic Prefix Invariance - Formal System Specification, v1.0. CERBERUS Matryoshka Integrated Formal Specification, v1.0. SOURCE NOTE Canonical Morse character mappings and the 1:3:1:3:7 timing relationships in this specification are aligned to ITU-R M.1677-1. MORSE-32 and MORSE-64 field layouts, Token IDs, profiles, projection semantics, Bitlink behavior, and prefix-invariance rules are CERBERUS architecture defined by this specification.