CERBERUS Formal Gameplay Architecture Specification Version 0.1 Core principle: Build worlds that understand Skills rather than lists of character classes. Document Control Field Specification Document CERBERUS Playable Semantic Skills Subtitle Semantic Skill Progression, Portable Character Competence, and Asymmetric Perception Version 0.1 Status Formal gameplay architecture specification Primary scope Domain / Skill separation; experience and Level; capability MASKs; hierarchy aggregation; classless character intake; Skill-driven perception; multiplayer communication; portable Skill state. Companion gameplay-state architecture CERBERUS 6x6 Effects Matrix - Formal Specification v0.1 Companion selective-perception architecture PULSE for Fantasy and Simulation - Formal System Specification v1.0 Semantic dependencies CERBERUS; BIGFOOT; Domain SKs; Skill SKs; Operators; Rules; Models; PULSE; SOLAR / MIRROR. Abstract CERBERUS Playable Semantic Skills defines a progression architecture in which a domain Semantic Kernel and a character Skill Semantic Kernel remain distinct but interoperable. The Domain SK owns the semantic and operational structure of a field: its vocabulary, Operators, Rules, Models, and relationships. The Skill SK owns a character's progression through that field: experience tracks, level models, unlock conditions, acquired-capability MASKs, and progression bonuses. This separation allows a domain to remain useful outside gameplay while still supporting game progression when a Skill SK is attached. It also allows one domain to contain several independently developing progression tracks. A cooking domain, for example, may support distinct Knife Skills, Heat Control, Mixing, Preservation, Baking, and Finishing tracks without forcing those progression categories into the canonical semantic organization of COOKING-128 itself. Experience originates from successful use of registered domain Operators. Successful activity credits the most specific relevant progression track. Accumulated experience is interpreted through a registered Level Model, while a MASK records which eligible capabilities the character has actually acquired. Level therefore establishes a learning frontier; it does not by itself assert mastery. The architecture is designed to support games, learning systems, simulations, and portable character development without requiring the underlying Domain SK to contain character-specific experience state. CORE PROPOSITION A character can be represented as a composition of independently governed Skill states over shared Semantic Kernels, allowing progression, capability, perception, and cross-game interoperability without requiring mechanically authoritative character classes. Contents PART I Progression Foundations 1. Purpose and Scope 2. Domain SK and Skill SK Separation 3. Skill Tracks and Progression Subclasses 4. Experience Ticks 5. Experience and Level 6. Level Frontiers and Capability MASKs 7. Purpose-Based Access Without False Mastery PART II Character Competence 8. Experience Aggregation Through the Semantic Hierarchy 9. Higher-Order Competence and Bonus Scope 10. Character Competence as a Composition of Skills 11. Persistent Competence Versus Current Gameplay State PART III Perception and Multiplayer 12. Skill Progression as Reader Capability 13. One Canonical World, Multiple Skill Lenses 14. Communication as a Gameplay Mechanic 15. Multi-Lens and Late-Resolution Puzzle Design PART IV Classless Play and Portability 16. Classless Semantic Character Intake 17. Portable Skill State and Cross-Game Reuse 18. Playable Skill Packages 19. Whole-System Architecture 20. Formal Architectural Laws 21. Conclusion List of Figures Figure 1. The Atomic Experience Event Figure 2. Domain SK / Skill SK Separation Figure 3. One Skill, Multiple Progression Tracks Figure 4. Experience to Level Figure 5. Level Frontier + MASK Figure 6. Purpose-Based Access Profiles Figure 7. Experience Aggregation Hierarchy Figure 8. Experience Up / Competence Down Figure 9. Character as Skill Composition Figure 10. Persistent Competence vs. Current Gameplay State Figure 11. Skill Progression Changes Perception Figure 12. One World, Multiple Skill Lenses Figure 13. Communication as Gameplay Figure 14. Multi-Lens Puzzle Grammar Figure 15. Classless Character Intake Figure 16. Portable Playable Knowledge Figure 17. Whole-System Summary PART I Progression Foundations Separates domain semantics from character progression, defines the origin of experience, and establishes Levels, learning frontiers, and acquired-capability MASKs. 1. Purpose and Scope The purpose of this specification is to define the lowest-level progression mechanism used by CERBERUS Playable Semantic Skills. This specification establishes the boundary between domain semantics and progression semantics, the origin of experience, the role of progression tracks, the relationship between experience and Level, and the use of MASK state to distinguish eligibility from acquisition. The architecture is intentionally domain-neutral. A Domain SK may represent a real-world subject such as cooking, music, mathematics, engineering, or tennis; it may also represent a fictional or game-specific domain such as dragon riding, necromancy, arcane resonance, or starship gunnery. The Skill SK mechanism is independent of whether the domain is factual, fictional, educational, professional, or purely recreational. This specification does not require every Domain SK to have a Skill SK. A Domain SK may exist solely as a semantic, operational, descriptive, educational, or simulation contract. Progression is attached only when a use case requires a character or learner to develop through that domain. Core Boundary ARCHITECTURAL PRINCIPLE The Domain SK defines the semantic and operational domain. The Skill SK defines a character's progression through that domain. This boundary prevents progression bookkeeping from becoming part of the domain's canonical meaning. Figure 1 - The Atomic Experience Event. A registered Domain Operator resolves successfully and credits experience to the appropriate track in the attached Skill SK. Experience begins with validated activity rather than arbitrary point allocation. Reference Terms Term Meaning Domain SK Canonical Semantic Kernel defining a domain's vocabulary, Operators, Rules, Models, relations, and valid operational semantics. Skill SK Canonical progression contract attached to a Domain SK; defines tracks, Level Models, unlock requirements, MASK logic, and progression bonuses. Skill state One character's instantiated progression under a Skill SK, including experience totals, derived Levels, acquired MASK positions, and compatible progression state. Progression track A progression-specific subdivision within a Skill SK, such as Knife Skills or Heat Control. Experience tick A unit of historical progression evidence credited after qualifying successful registered activity. Level Model The declared mapping from accumulated experience to a discrete Level. MASK A positional admission or acquisition state over a declared capability space. Reader capability A character capability that can resolve authorized PULSE semantics at a declared depth or scope. 2. Domain SK and Skill SK Separation A Domain SK is authoritative for what exists inside the domain. Its responsibilities may include semantic identities, Operators, Rules, Models, relations, valid state structures, and other domain-specific contracts. It does not need to know how a particular game or character chooses to measure progression through those capabilities. A Skill SK is authoritative for progression. It references the Domain SK and declares how a character's activity within that domain is measured and interpreted. Typical Skill SK responsibilities include: experience tracks; accumulated experience ticks; Level Models; unlock requirements; acquired-capability MASKs; progression bonuses; and progression-specific groupings or subclasses. This division allows the same Domain SK to support several progression implementations without redefining its semantics. A single COOKING-128 domain could support a children's cooking progression, a general-purpose cooking progression, a culinary-school progression, or a fantasy tavern progression while preserving one semantic definition of the underlying cooking concepts and Operators. The inverse is not equally true: a Skill SK requires a domain to progress through. It may reorganize or group domain capabilities for progression purposes, but it does not become the semantic authority for those capabilities. Figure 2 - Domain SK / Skill SK Separation. Domain authority remains responsible for semantics and operations. Progression authority remains responsible for experience, Levels, unlocks, MASKs, and bonuses. Separation Law ARCHITECTURAL PRINCIPLE Progression may reference domain semantics; it does not redefine them. A change to an unlock requirement must therefore not silently alter the meaning of the underlying Operator. Likewise, a change to the Domain SK must not silently rewrite a character's historical progression record without an explicit migration or versioning rule. 3. Skill Tracks and Progression Subclasses A Skill SK may contain multiple progression tracks. These tracks are progression-specific subdivisions that allow a character to develop unevenly within one broader domain. For example, a cooking progression might contain: Knife Skills; Heat Control; Mixing; Preservation; Baking; and Finishing. A character may therefore become highly experienced in knife work and surface-heat methods while remaining inexperienced in preservation or baking. This is more expressive than a single undifferentiated Cooking Level. Progression tracks are not required to match the internal grouping structure of the Domain SK. The Domain SK should organize semantics according to the needs of the domain. The Skill SK should organize progression according to the needs of learning, gameplay, or simulation. Where the two structures naturally align, they may share boundaries; where they do not, the Skill SK may reference capabilities across several domain regions. Each successful Operator is explicitly associated with one or more relevant progression tracks by the Skill SK's progression bindings. For example: JULIENNE may credit Knife Skills; SEAR may credit Heat Control; EMULSIFY may credit Mixing; and FERMENT may credit Preservation. The Domain Operator itself does not need to contain an experience value or character-specific progression state. The progression binding determines where successful use is credited. Figure 3 - One Skill, Multiple Progression Tracks. The Skill SK may divide one semantic domain into independently developing forms of competence while continuing to reference the same canonical Domain SK. Track Specificity Principle ARCHITECTURAL PRINCIPLE Experience should be credited at the most specific progression track that truthfully represents the successful activity. Broader totals may later be derived through aggregation. The system should not create duplicate experience merely because one action belongs to several nested categories. 4. Experience Ticks Experience ticks are the accumulated historical evidence of successful activity within a progression track. They are not themselves a semantic definition, a class label, or a claim of universal competence. The minimal progression event is: 1. a character attempts a registered Domain Operator; 2. the applicable Rules and Models resolve the attempt; 3. the system determines that the relevant success condition has been met; and 4. the attached Skill SK credits experience to the bound progression track. A game may use one tick per qualifying success or a more detailed registered valuation model. The exact valuation scheme is outside the scope of this specification. What matters architecturally is that the resulting experience is traceable to successful activity and stored at the progression layer rather than embedded into the Domain SK. Experience is cumulative unless the Skill SK explicitly defines another model. Because it represents historical activity, it should generally remain available even when the character is temporarily unable to perform the corresponding action due to injury, equipment, resource depletion, world Rules, or other current-state conditions. Experience Law ARCHITECTURAL PRINCIPLE Successful registered activity creates experience in the relevant Skill track. This law gives progression a direct relationship to what the character actually does. 5. Experience and Level Level is a discrete interpretation of accumulated experience. It is useful for interfaces, unlock thresholds, broad bonuses, and progression pacing, but it is not the primary historical record. The relationship is: Experience Ticks → Level Model → Level A registered Level Model maps accumulated experience to a Level. Different Skill tracks may use different Level Models when their pacing requirements differ. A broad or advanced track can therefore progress more slowly than a narrow introductory track without changing the underlying meaning of an experience tick. Because Level is derived, two implementations may choose different display conventions while preserving the same experience history, provided the active progression contract remains explicit and versioned. Figure 4 - Experience to Level. Accumulated experience is the richer historical record. A Level Model converts that history into a compact discrete progression state. Level Interpretation Principle ARCHITECTURAL PRINCIPLE Experience records what the character has done. Level summarizes where that history places the character within a declared progression model. Level should therefore not be treated as a substitute for the more detailed state available from the progression tracks and capability MASKs. 6. Level Frontiers and Capability MASKs Level and acquisition are intentionally separate. A capability may have a declared Level requirement. When the character's current track Level is below that requirement, the capability is locked. When the requirement is met, the capability becomes eligible for learning, discovery, instruction, practice, purchase, quest reward, or another acquisition mechanism defined by the game. Eligibility alone does not mean that the character has acquired the capability. The Skill SK therefore uses a MASK over the relevant capability space. Each MASK position records whether that capability has actually been acquired by the character. The three reference progression states are: LOCKED — the Level requirement or another declared prerequisite is not met; AVAILABLE — the capability is eligible but the character has not yet acquired it; and ACQUIRED — the capability is eligible and its MASK position is active. This allows Level to establish a learning frontier without producing automatic mastery. Reaching a new Level may expose several new possibilities while leaving the character's actual development dependent on what they choose to learn and practice. Figure 5 - Level Frontier + MASK. Level determines which capabilities are eligible. The MASK records which eligible capabilities the character has actually acquired. Progression Law ARCHITECTURAL PRINCIPLE Level determines eligibility; MASK state records acquisition. This distinction supports specialized characters even when they share the same nominal Level. Two Level 6 cooks may possess different learned techniques because their MASKs reflect different histories of study and practice. 7. Purpose-Based Access Without False Mastery Progression gating is useful for games, but it must not become an unnecessary barrier to learning or assessment. A Skill SK may therefore operate under different access profiles without altering earned experience. Reference access modes include: Game Mode — normal progression Rules determine which capabilities are available during play; Learning Mode — selected or complete domain content may be exposed for study regardless of current progression; Curriculum Mode — an instructor, course, or learning package exposes a bounded subset; Assessment Mode — a declared set of capabilities is made available for evaluation, potentially with teaching aids removed; and Sandbox Mode — broad temporary access supports experimentation or testing. These modes change what the user may access or attempt; they do not automatically rewrite the character's historical experience or acquired-capability MASK. A culinary student preparing for an examination may therefore study an advanced technique immediately even if ordinary game progression would not yet expose it. Successful practice may still produce legitimate experience according to the active Skill contract, but temporary study access is not itself evidence of mastery. Figure 6 - Purpose-Based Access Profiles. The same domain can support progression-gated play, open learning, bounded curricula, assessment, and sandbox experimentation while preserving one earned Skill state. Access Principle ARCHITECTURAL PRINCIPLE Temporary accessibility does not equal acquired competence. This principle allows the same Semantic Kernel and Skill architecture to support recreational play, structured learning, professional simulation, revision, and testing without inventing separate domain vocabularies. PART II Character Competence Aggregates specific Skill history into broader semantic competence while preserving specialization and separating durable learning from current gameplay condition. 8. Experience Aggregation Through the Semantic Hierarchy The preceding progression model establishes that experience originates in successful registered activity and is credited to the most specific progression track that truthfully represents that activity. This section extends that model upward. A Skill SK may contain one or more progression tracks. The Skill's total experience is the sum of its registered track experience. Skill totals may then be aggregated through the existing semantic hierarchy: Skill, Family, Community, World, and Character. For a simple weapons example: LONGSWORD_SKILL contains 16,234 experience ticks; MACE_SKILL contains 20,345 experience ticks; and both Skills belong to the MELEE WEAPONS Family. The Family therefore contains 36,579 experience ticks from those two Skills. If the Family contains additional member Skills, their experience is added in the same way. The Family total then contributes to its Community total, the Community contributes to its World total, and World totals contribute to the aggregate Character experience state. The general relationship is: Skill Experience = sum of registered progression tracks Family Experience = sum of member Skill experience Community Experience = sum of member Family experience World Experience = sum of member Community experience Character Experience = sum of member World experience The hierarchy does not create new experience events. It exposes the same historical activity at progressively broader semantic resolutions. Figure 7 - Experience Aggregation Hierarchy. Longsword and Mace experience are counted once at their Skill level and summed into Melee Weapons. Higher semantic levels continue the same aggregation pattern without duplicating the underlying activity. Aggregation Law ARCHITECTURAL PRINCIPLE Experience is created at the most specific registered progression state and summed upward through the semantic hierarchy. This law prevents double counting. A successful Longsword Operator does not separately award Longsword XP, Melee Weapons XP, Weapons XP, Combat XP, and Character XP. It creates the specific progression event once. Broader totals are derived from the state beneath them. Different hierarchy levels may use different Level Models. A narrow Skill can therefore gain Levels much faster than a broad Family, Community, or World even though the broader container holds a larger absolute experience total. For example: Longsword: 16,234 ticks -> Level 4; Mace: 20,345 ticks -> Level 5; and Melee Weapons: 36,579 ticks -> Level 2. The broader Level reflects breadth and accumulated scale rather than a direct comparison of raw Level numbers. 9. Higher-Order Competence and Bonus Scope Aggregation gives Family, Community, and World progression a mechanical role without requiring them to manufacture lower-level experience. Each broader semantic level may expose a declared Bonus Profile appropriate to its scope. A Melee Weapons Family can represent transferable competence common to close-range weapons. A Weapons Community can represent broader weapon familiarity. A Combat World can represent general combat competence. The exact bonuses are domain-defined and must remain explicit rather than inferred from the hierarchy name alone. Illustrative bonus classes may include: numeric modifiers; resource efficiency; learning-rate modifiers; general-purpose Operators; reduced unfamiliarity penalties; Reader or perception improvements; semantic recognition capability; or Rule modifiers that apply within the declared scope. The direction of information is intentionally asymmetric: Experience aggregates upward. Declared higher-order competence may apply downward across its valid scope. The downward application of competence does not alter the descendant Skill's historical experience. A character may therefore possess: Mace Skill: Level 0; Melee Weapons Family: Level 12; Weapons Community: Level 10; and Combat World: Level 9. That character remains inexperienced with mace-specific technique. However, the broader progression system may legitimately grant transferable timing, distance judgment, weapon appraisal, or other registered competencies that apply to the new weapon. Figure 8 - Experience Up / Competence Down. Experience is summed toward broader semantic levels. Bonus Profiles may project general competence back across their valid descendants without fabricating experience in those descendants. Generalization Law ARCHITECTURAL PRINCIPLE Higher-order competence may assist lower-order activity without rewriting lower-order experience. This preserves both transfer and specialization. A highly experienced character can approach a related unfamiliar Skill intelligently while remaining truthfully inexperienced in that specific Skill. 10. Character Competence as a Composition of Skills Once Skill progression is independently represented, the game does not require a hard-coded character class to determine what the character can do. The character's developed competence profile can be represented as the composition of their instantiated Skill states. Those Skills may be highly uneven. A single character may be: Level 18 in Quilting; Level 15 in Dragon Hunting; Level 11 in Longsword; Level 9 in Forest Lore; Level 3 in Music; and Level 1 in Cooking. This is a valid character. High aggregate experience does not imply broad competence in every domain. The architecture therefore distinguishes character competence from class identity. A game may still use labels such as Knight, Engineer, Bard, Ranger, Chef, or another archetype for narrative, social, matchmaking, or interface purposes. Those labels may be derived from the Skill profile or assigned by the world, but they do not need to own the underlying mechanics. Figure 9 - Character as Skill Composition. The character's developed competence is composed from independently evolving Skill states. A class label may summarize or narrate that profile, but the Skills remain the mechanical authority. Character Competence Principle ARCHITECTURAL PRINCIPLE Class may describe a character; Skills constitute the character's developed competence. This allows unusual combinations to remain first-class rather than requiring a developer to predefine every possible hybrid class. A character can become a specialist, generalist, or unusual combination simply through the distribution of Skills they actually develop. The Character experience total may still provide a broad measure of accumulated successful activity. It should not be interpreted as universal proficiency. The distribution beneath the total remains the authoritative description of what the character has actually developed. This section concerns the competence component of character state. Other systems may continue to own identity, body, health, inventory, memory, relationships, objectives, location, personality, and world-local state. 11. Persistent Competence Versus Current Gameplay State Skill progression and current gameplay condition answer different questions. A Skill state answers: ARCHITECTURAL PRINCIPLE What has this character learned and developed over time? Current gameplay state answers: ARCHITECTURAL PRINCIPLE What can this character support under present conditions? A Level 12 Longsword character may still be exhausted, injured, slowed, disarmed, out of stamina, affected by status conditions, or otherwise unable to execute a normally available action. Conversely, restoring current resources does not create new Longsword experience or unlock techniques the character has never learned. Action resolution therefore combines at least three independent inputs: 1. Persistent Skill state - whether the relevant capability or Operator is available to the character; 2. Current runtime state - resources, statuses, equipment, environment, modifiers, and other active conditions; and 3. Rules / Operator contract - the exact requirements, costs, targets, and transformations governing execution. For an illustrative action: the character has LONGSWORD_SKILL Level 12; POWER CUT is an acquired Operator; current Stamina is 18; the Operator declares a Stamina cost of 12; and no other active Rule blocks the action. The action is therefore valid, Stamina deterministically changes from 18 to 6, and the Skill Level remains 12. If the action subsequently satisfies its success condition, the progression system may record new experience according to the active Skill progression binding. Figure 10 - Persistent Competence vs. Current Gameplay State. Skill history, current condition, and the action contract converge at deterministic resolution. The action mutates current state without rewriting earned competence. The CERBERUS 6x6 Effects Matrix can serve as one shared current-state and effect surface for games using that companion architecture. This paper does not redefine the matrix. It relies only on the broader separation between persistent character competence and mutable gameplay state. Persistent Competence Law ARCHITECTURAL PRINCIPLE Temporary inability does not erase earned competence. Current-State Law ARCHITECTURAL PRINCIPLE An available Skill capability executes only when current state and applicable Rules admit the action. This separation gives progression durable meaning while preserving deterministic gameplay. The character can know an action, fail to afford it, become temporarily unable to perform it, recover, and later use it again without any ambiguity about whether the underlying Skill was forgotten. PART III Perception and Multiplayer Connects developed Skills to Reader capability, PULSE readability, asymmetric perception, communication, and multi-lens puzzle design. 12. Skill Progression as Reader Capability Skill progression can alter more than action availability. A Skill SK may also bind selected progression states to Reader capability, Profile eligibility, semantic resolution, intersection access, persistence access, or sharing capability. This does not give the Skill SK authority over world truth. The world remains authoritative for what exists. PULSE remains responsible for selective readability. The Skill SK answers a narrower question: what Reader capabilities has this character developed sufficiently to use? The progression path is therefore: Skill experience → Skill Level / acquired MASK state → Reader capability → PULSE readability → viewer-specific perception A structural Skill provides a simple example. The canonical world may already contain a cavity, a fracture, a load path, and a concealed mechanism. Those structures do not appear when the character levels up. They are already part of the world state or registered semantic relationships. Progression changes how deeply the character can resolve the existing structural layer. An illustrative progression may behave as follows: low Reader capability: detect that the wall contains an abnormal structural condition; medium Reader capability: resolve a hidden cavity and visible fracture semantics; and high Reader capability: resolve load transfer, fracture origin, and a concealed mechanism. The exact thresholds, MASK positions, and Reader capabilities remain domain-defined. Level need not be the sole gate. A character may possess a high Level while lacking a specific acquired semantic capability, or may temporarily receive a Reader capability from equipment, environment, an artifact, a spell, or another permitted source. Figure 11 - Skill Progression Changes Perception. The canonical wall remains unchanged while progressively developed Reader capability exposes greater semantic resolution. Progression alters legibility rather than inventing new world state. Readability Boundary ARCHITECTURAL PRINCIPLE Skill progression may expand the character's Reader capability; it does not create the semantic world state being read. This distinction preserves the PULSE separation among canonical world state, readability, Reader/Profile capability, and perceptual projection. It also makes progression more interesting than a simple numeric multiplier. A character can become more capable because the world becomes more legible. 13. One Canonical World, Multiple Skill Lenses Once Reader capability is linked to Skill development, different characters can inhabit the same canonical environment while receiving materially different semantic views. A single room may simultaneously contain or relate to: structural state such as fractures, cavities, load paths, and mechanisms; arcane state such as wards, conduits, fields, residues, and ritual geometry; historical Echo state such as deaths, movement paths, former openings, and retained events; tracking state such as recent traversal, footprints, disturbance, and routes; and resonance state such as phase, harmony, continuation, and coherent musical relationships. The room is not duplicated into five versions. Each character resolves only the semantic dimensions admitted by their active Skill, Reader, Profile, permissions, and world conditions. Figure 12 - One World, Multiple Skill Lenses. Five characters inspect the same canonical room. Their developed Skill states admit different readable PULSE layers without requiring separate maps, duplicate objects, or hard-coded character classes. This architecture does not require the game to decide that one participant is categorically an Engineer, Mage, Necromancer, Scout, or Bard. Those words may remain useful descriptions, but the mechanical authority is the actual Skill state. A character may combine unusual capabilities such as Structural + Arcane, Tracking + Echo, Music + Magic, or Biology + Combat. The game reads the semantic capabilities that are present rather than requiring every valid combination to be predefined as a class. Lens Principle ARCHITECTURAL PRINCIPLE A character's perceptual lens is the readable consequence of developed semantic capability, not a mandatory class assignment. Two characters with the same broad Skill may also differ. Their Levels, acquired MASK positions, Reader resolution, equipment, permissions, and temporary conditions may expose different subsets or depths of the same PULSE layer. 14. Communication as a Gameplay Mechanic Asymmetric perception becomes most valuable when private views are not silently merged into a universal party interface. If one character resolves a structural cavity, another resolves an arcane ward inside it, and another resolves an historical event showing that the structure once opened from within, the party does not automatically possess one complete observation merely because the game engine contains all three pieces of data. The participants must communicate. Communication may occur through ordinary player speech, character dialogue, marks, pings, notes, or explicit sharing Operators. A sharing mechanism may communicate a Landmark or bounded semantic observation without granting the recipient the source character's complete Reader capability. This preserves a useful distinction: Direct perception ≠ communicated knowledge A recipient may know that another character marked a wall as unsafe without independently resolving the fracture. A character may know that a Mage reported a ward without possessing the Arcane semantics needed to inspect it directly. Source, confidence, time, and fidelity can remain visible where the game needs them. Figure 13 - Communication as Gameplay. Private semantic observations flow through human communication or explicit sharing into a shared social model. The party then selects an Operator whose consequence resolves deterministically against the world. Communication Law ARCHITECTURAL PRINCIPLE Private semantic views become shared operational understanding only through communication, declared sharing, or another authorized information route. This makes cooperation epistemic rather than merely numerical. Players do not simply contribute different damage types to the same shared information state. They contribute different pieces of reality. A multiplayer encounter can therefore ask players to explain what they see, decide whose lens is relevant, detect disagreement among Readers, and act under incomplete information. The social act of constructing a shared model becomes part of play. 15. Multi-Lens and Late-Resolution Puzzle Design The same architecture gives designers a compact grammar for puzzles and exploration. 15.1 Common Lens A Common Lens exposes semantics available to many character states. It can support broad navigation, basic clue reading, or introductory gameplay without requiring specialization. 15.2 Specialist Lens A Specialist Lens requires concentrated development in a particular Skill or Reader capability. It rewards genuine specialization without requiring a hard-coded class gate. 15.3 Deep Resolution Deep Resolution exposes greater semantic detail within a layer the character already recognizes. An early structural Reader may detect an abnormal wall; a later Reader may recover the exact failure route or concealed mechanism. 15.4 Multi-Lens Puzzle A Multi-Lens Puzzle requires several independent observations to be combined. For example: Structural reveals a hidden cavity; Arcane reveals the ward sealing it; Echo reveals that the opening was previously used from the opposite side; and Resonance reveals the activation sequence. No one observation needs to contain the complete solution. 15.5 Profile / Lens Intersection An Intersection puzzle reveals a declared relationship that becomes meaningful only when multiple semantic lenses can be queried together. Echo + Arcane may expose historical magical activity. Structural + Echo may expose a former wall position or collapse chronology. Resonance + Arcane may expose a chord-locked ward. The intersection remains bounded. Activating two lenses does not authorize an uncontrolled everything-view. 15.6 Legacy Secret A Legacy Secret exists in the world before the character can read it. Later Skill progression, Reader improvement, an acquired MASK position, or another valid capability makes the existing semantic structure legible. This enables meaningful revisitation. A player can return to a familiar room and discover new information without the game pretending that the secret was created at the moment of leveling. 15.7 Unexpected Expertise Because Skills are semantic rather than class-bound, designers can reward unusual competence. A Textiles Skill may recognize that a decorative border is actually a functional pattern. A Music Skill may notice a resonance clue in an architectural space. A Cooking or Botanical Skill may identify material evidence ignored by conventional adventuring abilities. Figure 14 - Multi-Lens Puzzle Grammar. Common, specialist, deep-resolution, multi-lens, intersection, and legacy-secret patterns provide reusable ways to design puzzles around semantic readability rather than predefined character classes. Puzzle Design Principle ARCHITECTURAL PRINCIPLE Gate discoveries by semantic capability and Reader resolution where possible, not by arbitrary class labels. The puzzle can state what must be perceived, understood, or operated upon. Any character or party whose actual Skill states satisfy those requirements can solve it. PART IV Classless Play and Portability Shows how games can ingest semantic Skill states directly, reuse playable knowledge across worlds, and close the loop from deterministic action back into progression. 16. Classless Semantic Character Intake A game does not need a mechanically authoritative class system in order to understand a developed character. The character can arrive as a composition of instantiated Skill states. Each Skill state references the semantic domain it progresses through and carries the character-specific progression information needed by the receiving game. The receiving game performs semantic intake rather than class translation. A minimal intake sequence is: Character Skill states → resolve Skill SK references → resolve linked Domain SKs → check local support → activate compatible capabilities → apply local Rules → play The game therefore asks questions such as: Which Skill identities are present on the character? Which of those Skill and Domain SK contracts are supported here? Which acquired MASK positions, Operators, bonus profiles, and Reader capabilities are compatible with this world? Which local Rules, permissions, resources, and current-state constraints govern their use? It does not first need to answer "What class is this character?" A character may arrive with Cooking, Forest Lore, Ghost Lore, Music, Structural Engineering, Longsword, Textiles, or any other registered Skill state. If the receiving game understands only some of those Skills, it activates the compatible subset. Unsupported Skills remain part of the character state but are inactive in that world unless a compatible semantic contract is later introduced. Figure 15 - Classless Character Intake. A character enters the game as a set of semantic Skill states. The game activates the Skills it supports, retains unsupported Skills without forced conversion, applies local world Rules and presentation, and begins play without requiring a canonical class lookup. Class Boundary ARCHITECTURAL PRINCIPLE Class may describe a character, but it does not need to construct the character. A game MAY still project class-like language for narrative, matchmaking, interface, or convenience. A character whose Skill distribution strongly favors combat and tracking may be described as a Ranger; another may be called an Engineer, Chef, Bard, or Battle Cook. Such labels are optional projections over the underlying Skill state. Removing or changing the label does not rewrite the character's actual competence. This also permits unusual combinations without requiring the game designer to enumerate every possible archetype in advance. A character may be simultaneously strong in Textiles, Dragon Combat, Music, Structural Engineering, and Cooking. The semantic Skill graph already expresses what that character can do. Semantic Intake Principle ARCHITECTURAL PRINCIPLE The receiving game should read the capabilities the character carries, activate the semantic contracts it supports, and let local Rules govern play. This shifts game design away from authoring every possible kind of person and toward authoring worlds that understand reusable semantic capabilities. 17. Portable Skill State and Cross-Game Reuse Because Domain SKs and Skill SKs use stable semantic identities, a character's developed competence can be represented independently of one game's genre, art style, interface, or story. A portable Skill state may include, as applicable: Skill SK identity and version; linked Domain SK identity and version; progression-track experience totals; derived Levels; acquired MASK positions; unlocked or acquired Operator bindings; applicable higher-order bonus state; Reader capability derived from progression; provenance needed by receiving systems to judge compatibility or trust; and character identity to which the state belongs. The exact serialization format is outside this paper. The architectural requirement is that the receiving game can determine what the Skill state means without translating an opaque game-specific class or level name. A Cooking Skill provides the clearest example. The same underlying semantic domain can appear in a children's cooking game, a fantasy tavern, a survival simulation, a meal-planning game, or a professional culinary simulator. Figure 16 - Portable Playable Knowledge. COOKING-128, its attached Cooking Skill state, and the character's accumulated progression can remain semantically stable while a children's game, fantasy game, and professional simulator apply different access profiles, Rules, difficulty, and MIRROR presentation. The receiving implementation may differ substantially: 17.1 Children's Game A children's game may MASK most advanced or unsafe Operators, expose a smaller learning frontier, use forgiving success Rules, and present the domain through playful MIRROR assets. The semantics that are exposed remain the real semantic identities rather than a disconnected imitation of cooking. 17.2 Fantasy Game A fantasy game may use the same Cooking semantics inside a tavern, expedition, magical kitchen, or survival system. Fantasy ingredients, equipment, animations, and world Rules may differ while shared concepts such as slicing, mixing, roasting, or emulsification retain their canonical semantic references where those real concepts apply. 17.3 Professional Simulation A professional simulator may expose broad or complete domain access, apply stricter validation and resource Rules, enable Learning or Assessment Modes, and use realistic MIRROR projections. Prior game experience can remain visible as history without automatically becoming professional certification. Portability Boundary ARCHITECTURAL PRINCIPLE Portable Skill state records developed semantic competence and experience history; it does not by itself establish a regulated professional credential. A receiving professional system MAY distinguish ordinary game experience, high-fidelity simulation, supervised assessment, physical verification, or external certification through provenance and governance. The semantic capability can remain the same while the evidentiary status differs. Access Boundary The same Skill state can also be exposed through different access purposes: Progression Mode may use Level and MASK state to gate normal play; Learning Mode may temporarily expose the complete semantic domain for study; Curriculum Mode may expose an instructor-selected subset; Assessment Mode may expose only the required test surface; and Sandbox Mode may permit broad experimentation. Temporary access does not rewrite accumulated experience or acquired competence. 18. Playable Skill Packages The Domain SK / Skill SK separation allows domain designers to build reusable playable knowledge packages rather than one-off game skill trees. A minimal playable package may combine: Domain SK + Skill SK + registered Operators + applicable Rules / Models + optional BOOTSTRAP learning material + presentation bindings The Domain SK remains responsible for semantic and operational meaning. The Skill SK remains responsible for progression. The receiving game remains responsible for local world state, permitted interactions, difficulty, current resources, narrative context, and presentation. This permits a well-designed domain progression to be reused rather than reimplemented. A strong Cooking package can support multiple games. A Music package can support a rhythm game, fantasy Bard system, educational trainer, or professional simulator. A Structural Skill can support engineering education, industrial simulation, exploration puzzles, or fantasy fortress gameplay. The portable object is therefore not one game's class called "Cook" or "Engineer." It is a shared semantic capability surface that multiple worlds can interpret. Playable Knowledge Principle ARCHITECTURAL PRINCIPLE Standardize the semantic capability contract where useful; allow worlds to vary how that capability is taught, gated, challenged, and presented. This is particularly valuable for learning-oriented games. If a Semantic Kernel is aligned to established terminology and domain practice, a game can teach vocabulary and conceptual relationships that remain useful outside that specific game. A learner may begin with a bounded children's interface, later use a more advanced game, and eventually enter a high-fidelity simulator without resetting the semantic foundation each time. 19. Whole-System Architecture The complete mechanism can now be expressed as one loop. Domain SK defines the semantic and operational domain. Successful Operator use produces progression evidence. Skill SK records experience in appropriate progression tracks, derives Levels through declared Level Models, records acquisition through MASK state, and binds progression to bonuses or Reader capability. Family, Community, and World aggregate the experience of their semantic descendants and may provide broader competence appropriate to their scope without fabricating lower-level experience. Character competence is the composition of the character's developed Skill states. Class labels are optional projections over that composition. Game semantic intake activates the Skill contracts supported by the receiving world. Current world state supplies resources, statuses, permissions, environment, Effects Matrix values, and other mutable conditions governing present action. PULSE + Reader capability determines what semantic world state the character can resolve. Private perception creates character-specific informational reality. Communication allows multiple players or characters to construct shared operational understanding from distinct semantic lenses. Chosen Operators resolve through local Rules and current state. Deterministic results mutate the world and may generate new successful-use experience, closing the progression loop. Figure 17 - Whole-System Summary. Domain semantics, Skill progression, hierarchy aggregation, classless character competence, semantic game intake, current world state, PULSE readability, communication, deterministic action, and renewed experience form one reusable gameplay loop. 20. Formal Architectural Laws 20.1 Domain / Progression Separation Law ARCHITECTURAL PRINCIPLE The Domain SK owns what the domain means and permits. The Skill SK owns character progression through that domain. 20.2 Successful Experience Law ARCHITECTURAL PRINCIPLE Experience originates from successful registered activity attributed to an appropriate Skill progression track. 20.3 Aggregation Law ARCHITECTURAL PRINCIPLE Broader experience values are sums of the experience contained beneath them; they do not require secondary experience awards. 20.4 Competence Generalization Law ARCHITECTURAL PRINCIPLE Higher-order Skill hierarchy levels may provide broader competence without granting false experience to descendant Skills. 20.5 Level / MASK Law ARCHITECTURAL PRINCIPLE Level defines progression state or eligibility; MASK state records which specific capabilities have actually been acquired or admitted. 20.6 Classless Character Law ARCHITECTURAL PRINCIPLE A game's mechanical understanding of a character may be derived directly from semantic Skill state without requiring a predefined class. 20.7 Readability Law ARCHITECTURAL PRINCIPLE Skill progression may expand Reader capability and semantic legibility without creating the world state being perceived. 20.8 Communication Law ARCHITECTURAL PRINCIPLE Private semantic perception becomes shared operational knowledge only through communication, declared sharing, or another authorized information route. 20.9 Portability Law ARCHITECTURAL PRINCIPLE A Skill state may remain semantically stable across games while access, Rules, difficulty, world context, and presentation vary locally. 20.10 Deterministic Play Law ARCHITECTURAL PRINCIPLE Available capability, current state, applicable Rules, and the chosen Operator determine the gameplay transition; progression records the successful history produced by those transitions. Companion Architecture References Companion specification Role in this paper CERBERUS 6x6 Effects Matrix - Formal Specification v0.1 Companion current-state and effect-resolution architecture. This specification references its separation of persistent semantic definitions from mutable gameplay state, registered Operators, and exact state deltas. PULSE for Fantasy and Simulation - Formal System Specification v1.0 Companion selective-perception architecture. This specification references its separation of canonical world state, PULSE readability, Reader/Profile capability, and viewer-specific projection. 21. Conclusion Playable Semantic Skills convert Semantic Kernels into a reusable substrate for character development without making progression part of every domain definition. Domain SKs describe semantic and operational possibility. Skill SKs describe how a particular character develops through that possibility. Experience can be accumulated from successful Operators, resolved into independently developing tracks, summarized through Level Models, and refined through acquired MASK state. Experience then aggregates through Family, Community, World, and character scope, producing broad competence while preserving the specific history beneath it. Because developed Skill state can also enable Reader capability, progression can change what a character perceives. PULSE can expose different semantic dimensions of one canonical world to different characters. Multiplayer parties must then communicate across those bounded realities, allowing expertise and information asymmetry to become core gameplay rather than decorative class bonuses. Finally, stable semantic Skill identities allow characters and playable domain packages to move between compatible games without forcing every world to share the same classes, assets, difficulty, or presentation. The receiving game needs to understand the semantic contracts it supports, apply its own Rules and world state, and render those capabilities through its own presentation system. Closing Principle ARCHITECTURAL PRINCIPLE Build worlds that understand Skills rather than lists of character classes. Read the supported semantic capabilities, apply local Rules, and play.