4 - CERBERUS_Template_System_Bounded_Presentation_Contracts_for_MIRROR_Aware_Documentation_v0.1.docx

CERBERUS COMPANION ARCHITECTURE CERBERUS Template System Bounded Presentation Contracts for MIRROR-Aware Documentation Concept Specification v0.1 Core Thesis Templates give information and assets governed places to land. Data owns meaning. MIRROR owns material. Templates own placement. Readers own binding. Figure 1. The four-way responsibility split +------------------+ +------------------+ | CERBERUS DATA | | FORMULA / READER | | Meaning / facts | | Slot bindings | +--------+---------+ +---------+--------+ | | +------------+------------+ v +------------------+ | TEMPLATE | | Regions / Slots | | Geometry / Rules | +---------+--------+ | v +------------------+ | SOLAR MIRROR | | Visual material | +---------+--------+ | v +------------------+ | RENDERER | | DOCX / PDF / UI | +------------------+ Reader chooses the semantic Slot. Template owns that Slot's geometry. MIRROR supplies visual material. The renderer manifests the result. Purpose Define a compact reusable template grammar that can accept CERBERUS data, SOLAR/MIRROR imagery, system figures, and interactive-model fallbacks without forcing Readers to manage page coordinates or forcing Templates to own semantic meaning. 1 Why a Template Layer Exists CERBERUS can know what an object is. SOLAR can provide familiar lexical entry points. MIRROR can resolve reusable visual material. None of those systems should have to decide where a title, figure, fact list, symbol, model, or exploded asset view belongs on a page. The Template System adds a bounded presentation layer between semantic selection and rendering. It turns layout from an improvised drawing decision into an addressable contract. Boundary A Template governs placement and presentation behavior. It does not become the authority for the content placed inside it. Figure 2. Template grammar TEMPLATE | +-- REGION | | | +-- SLOT | | | +-- BINDING | +-- INSTANCE The reusable Template is populated through Regions and Slots. A populated use is an Instance. Core object model Object Purpose Does not own Template Reusable whole presentation contract Semantic facts or assets Region Bounded functional area The content placed in it Slot Addressable placement for one content role Source-system authority Binding Maps content/material to a Slot Geometry Instance Populated manifestation of a Template The reusable Template definition Bounded Geometry Templates own geometry. Readers should bind values to stable Slot identities rather than emitting renderer-specific coordinates. A logical coordinate space makes the same Template portable across DOCX, PDF, web, and interactive surfaces. Figure 3. A bounded logical page CANVAS: 1000 x 1000 logical units +------------------------------------------+ | REG-HEADER | | SLT-NAME SLT-ID | +----------------------+-------------------+ | REG-CONTENT | REG-VISUAL | | | | | SLT-DESCRIPTION | SLT-HERO | | SLT-FACTS | | +----------------------+-------------------+ | REG-FOOTER | | SLT-NOTES / SLT-REFERENCES | +------------------------------------------+ The Reader addresses SLT-HERO. The Template determines where SLT-HERO is. Minimum Slot geometry Field Meaning Slot ID Stable address used by Readers and renderers X / Y Logical origin within the Template canvas Width / Height Bounded available area Z Order Stacking order when content overlaps by design Alignment Placement behavior inside the bounds Padding Internal breathing room Slot Vocabulary The primitive Slot vocabulary should stay small. Specific meaning belongs in the Slot Role and Binding Key rather than in an ever-growing set of rendering primitives. Primitive Slot types Type Typical use Type Typical use TEXT Narrative / labels DATA Values / measurements IMAGE Static visual SYMBOL Exact symbolic asset STRUCTURE BitWord / graph / hierarchy TABLE Tabular content LIST Variable-length items COMPOSITE Multi-part MIRROR construction MODEL Interactive / rendered model CAPTION / REFERENCE Captions, links, related routes 2 MIRROR-Aware Visual Slots Visual Slots do not contain image ownership rules. They declare what kind of material may satisfy the bounded role, then resolve the actual material through SOLAR MIRROR or another governed asset source. Figure 4. Visual Slot resolution +------------------------+ | SLT-HERO | | Type: IMAGE / MODEL | +-----------+------------+ | v +------------------------+ | SOLAR / MIRROR ROUTE | +-----------+------------+ | +--------+---------+----------------+----------------+ | | | | v v v v Preferred Image Exact Asset Composite Shape Interactive Model | | | | +------------------+----------------+----------------+ v +------------------+ | SLOT BOUNDS | | fit / fallback | +------------------+ MIRROR resolves what material exists. The Template resolves where it belongs. A single Slot may support multiple manifestations. An interactive renderer may show a manipulable model, while a DOCX or PDF renderer uses a registered static preview or snapshot of the same bound material. Media Capability Law Media capability does not change Slot identity. The same Slot may be interactive in one renderer and static in another. Presence, Fallback, and Fit Rules Automation requires explicit behavior when content is absent, variable in length, or larger than the allocated bounds. Those rules belong to the Template rather than being improvised by a Reader. Presence rules Rule Meaning REQUIRED Instance is incomplete without content for the Slot OPTIONAL Content may be omitted without invalidating the Template CONDITIONAL Presence depends on a defined condition, capability, or available route Empty-region policies Policy Behavior COLLAPSE Remove unused space and let neighboring content expand PRESERVE Keep the bounded area empty FALLBACK Resolve a lower-capability or alternate content source REPLACE Substitute a designated alternate Region or Slot Fit and overflow vocabulary Policy Typical use CONTAIN Preserve the full visual within bounds COVER Fill the bounds; cropping is permitted WRAP Flow text to new lines EXPAND Grow the bounded Region when permitted SHRINK Reduce content scale within a safe minimum CROP Trim material according to a defined focal rule PAGINATE Continue variable content onto additional pages/surfaces TRUNCATE Limit content and signal that additional material exists Figure 5. Interactive fallback SLT-ASSET-MODEL | +-- interactive renderer available? -- YES --> live model | +-- NO -------------------------------------> static preview | v same Slot ID Fallback changes manifestation, not semantic Slot identity. Repeating Content and Flexible Regions Variable-length structures should use repeating Slots or Regions. This avoids arbitrary limits such as PART-01 through PART-50 and lets the same Template handle simple and complex subjects. Figure 6. Repeating Slot REG-PARTS +------------------------------------------+ | SLT-ASSET-PARTS [REPEATER] | | | | + Body | | + Head | | + Ear L | | + Ear R | | + Tail | | + ... | +------------------------------------------+ The Region owns the repetition and pagination behavior. The Reader supplies the ordered collection. Region behavior Behavior Use FIXED Stable dimensions EXPANDABLE Grows with wrapped or repeated content COLLAPSIBLE Disappears cleanly when not used REPEATING Repeats an internal structure for each item PAGINATED Continues across pages or views 3 Canonical Template Families The first system needs only a small set of reusable Template families. They demonstrate the grammar while covering the documentation patterns most likely to be used immediately. Template A - Entity Facts A general factsheet pattern for animals, plants, rocks, planets, machines, places, or other entities. The subject schema can differ while the bounded presentation remains stable. Figure 7. Entity Facts Template +------------------------------------------+ | NAME / CLASSIFICATION | +----------------------+-------------------+ | CORE FACTS | HERO VISUAL | | | | | Weight | [ MIRROR ] | | Lifespan | | | Range | | | Diet | | +----------------------+-------------------+ | DESCRIPTION | +----------------------+-------------------+ | BEHAVIOR | SECONDARY VISUAL | | | / MODEL | +----------------------+-------------------+ The same presentation contract can host Wolf, Oak, Basalt, Mars, or a machine record. Template B - SK BitWord Representation A structured presentation for SKs and BitWords that can consume the linked BitWord, BitGroup, Bit, Reader, dependency, and MIRROR figure relationships built into CERBERUS. Figure 8. SK BitWord Template +------------------------------------------+ | BITWORD NAME ID WIDTH | +------------------------------------------+ | | | BITWORD REPRESENTATION | | [ registered visual ] | | | +----------------------+-------------------+ | BITGROUPS | DEFINITION | | | | +----------------------+-------------------+ | BITS | READER / FUNCTION | | | | +----------------------+-------------------+ | DEPENDENCIES / <R> / RELATED SKs | +------------------------------------------+ Once BitWords and BitGroups are linked, the Reader can populate stable Slots without redesigning the page. Template C - Symbol Explanation A BOSS-friendly explanation card that preserves the established Symbol, Name, Description, Professional Example, and Personal Example structure while allowing optional imagery and relation routes. Figure 9. Symbol Explanation Template +------------------------------------------+ | | | * | | SYMBOL | | | +------------------------------------------+ | NAME | | DESCRIPTION | +----------------------+-------------------+ | PROFESSIONAL EXAMPLE | PERSONAL EXAMPLE | | | | +----------------------+-------------------+ | FAMILY / RELATIONS / ROUTES | +------------------------------------------+ A MIRROR asset or model can be added as an optional illustration without changing the symbol record itself. 4 Template D - Asset Explanation MIRROR can document its own reusable material. A simple image can use the basic identity and metadata Regions; a complex layered or rigged asset can additionally expose parts, routing, pivots, transforms, variants, and provenance. Figure 10. Asset Explanation Template +------------------------------------------+ | ASSET NAME / ID / TYPE / STATUS | +----------------------+-------------------+ | | PARTS | | WHOLE ASSET | | | [ IMAGE/MODEL ] | Body | | | Head | | | Tail | | | Legs ... | +----------------------+-------------------+ | EXPLODED / STRUCTURAL VIEW | | | | Body -- Head -- Ear | | +-- Foreleg -- Lower Leg -- Paw | | +-- Tail | +----------------------+-------------------+ | ROUTING | TRANSFORMS | | SOLAR / Folder | Pivots / Limits | +----------------------+-------------------+ | NOTES / VERSION / PROVENANCE | +------------------------------------------+ Optional Regions collapse for simple assets; complex assets can expose their recoverable construction. Template E - Technical Component Explanation A general component page for Readers, formulas, registries, operators, state machines, DataSpec structures, and other CERBERUS machinery. Figure 11. Technical Component Template +------------------------------------------+ | COMPONENT NAME ID / TYPE | +------------------------------------------+ | | | STRUCTURAL FIGURE | | | +----------------------+-------------------+ | COMPONENTS | PURPOSE | +----------------------+-------------------+ | INPUTS | OUTPUTS | +----------------------+-------------------+ | RULES / RELATIONSHIPS | +------------------------------------------+ | EXAMPLE | +------------------------------------------+ The Template is content-neutral: the same spatial grammar can explain a Formula, Reader, Registry, or graph component. Template F - Process / Flow Explanation A process-oriented template for governed flows and transformations. It reserves a central bounded flow region and separates purpose, inputs, outputs, rules, failure states, and an example. Figure 12. Process Template +------------------------------------------+ | PROCESS NAME | +------------------------------------------+ | PURPOSE / START CONDITION | +------------------------------------------+ | | | [ A ] --> [ B ] --> [ C ] --> [ D ] | | | +----------------------+-------------------+ | INPUTS | OUTPUTS | +----------------------+-------------------+ | RULES | FAILURE STATES | +----------------------+-------------------+ | EXAMPLE | +------------------------------------------+ The flow itself can be a MIRROR system figure, graph rendering, or interactive model. 5 Compositional Templates Templates should be built from reusable Regions where practical. A single Identity Header, Hero Region, Description Region, or References Region can appear across many Template families without being recreated each time. Figure 13. Region reuse REG-IDENTITY-HEADER | +--> TPL-ENTITY-FACTS +--> TPL-SK-BITWORD +--> TPL-SYMBOL +--> TPL-ASSET +--> TPL-TECHNICAL REG-DESCRIPTION | +--> TPL-ENTITY-FACTS +--> TPL-SYMBOL +--> TPL-TECHNICAL Build once. Save exactly. Compose repeatedly. Stable IDs Stable Template, Region, and Slot identities make the system addressable by formulas, Readers, renderers, Airtable records, and future automation. Human-readable names should accompany the IDs, but the IDs are the stable binding contract. Starter identity pattern Class Examples Template TPL-ENTITY-FACTS, TPL-SK-BITWORD, TPL-SYMBOL Region REG-IDENTITY, REG-HERO, REG-FACTS, REG-STRUCTURE Slot SLT-NAME, SLT-ID, SLT-HERO, SLT-BITWORD, SLT-PARTS Formula and Reader Handoff The Template System should make future Formula/Reader automation simpler by giving Readers stable semantic targets. A Reader chooses which Slot receives a value. It does not need to know the Slot's page coordinates, font size, crop behavior, or fallback policy. Figure 14. Reader-to-Template binding TARGET: Wolf READER OUTPUT +------------------------+---------------------------+ | SLT-NAME | Wolf | | SLT-CLASS | Mammal | | SLT-HERO | SOLAR.PreferredImage | | SLT-DESCRIPTION | <resolved text> | | SLT-FACTS | <resolved fact set> | +------------------------+---------------------------+ | v TPL-ENTITY-FACTS owns geometry and rendering rules The Reader outputs bindings; the Template turns those bindings into bounded presentation. Figure 15. SK Reader binding TARGET: COLOR-32-64 READER OUTPUT +------------------------+---------------------------+ | SLT-NAME | COLOR-32-64 | | SLT-BITWORD | linked BitWord | | SLT-BITGROUPS | linked BitGroups | | SLT-BITS | linked Bits | | SLT-DEFINITION | formal definition | | SLT-DEPENDENCIES | related SK routes | +------------------------+---------------------------+ | v TPL-SK-BITWORD owns geometry and MIRROR placement This creates a direct target for the upcoming BitWord and Formula/Reader work. Minimum Registry Surface for a Later Airtable Build This paper does not implement the Base, but it defines a compact record model that can later be represented transparently in Airtable. The implementation can remain small at first and become more granular only when the renderer requires it. Conceptual registry surface Registry Minimum responsibility Templates Template identity, canvas, purpose, version, status Regions Template membership, bounds, behavior, order Slots Region membership, type, role, geometry, presence, fit policy Bindings Allowed or active semantic/data/material route for a Slot Instances Optional populated/template-run record when persistence is useful Implementation Boundary The Airtable Base should make the Template grammar visible and routable; it should not turn every rendered paragraph or image into unnecessary registry overhead. 6 Template System Rules TPL-R01 - Placement Ownership Templates own bounded presentation geometry, not semantic meaning. TPL-R02 - Slot Binding Readers bind content to stable Slot identities rather than directly controlling coordinates. TPL-R03 - Material Independence A visual Slot references material without owning the MIRROR asset itself. TPL-R04 - Optionality Slots and Regions may be Required, Optional, or Conditional. TPL-R05 - Renderer Independence A Template's logical layout may be manifested by multiple renderers. TPL-R06 - Media Fallback Interactive content may provide static fallback material without changing its semantic Slot. TPL-R07 - Repeating Content Variable-length structures should populate repeating Slots rather than requiring fixed arbitrary counts. TPL-R08 - Reusable Composition Regions and Templates should reuse approved bounded presentation components where practical. System Questions Figure 16. Three routing questions READER What belongs in SLT-HERO? | v TEMPLATE Where is SLT-HERO and how does it behave? | v MIRROR What exact visual material satisfies it? | v RENDERER How is that bounded contract manifested here? Each subsystem answers a different question. Their responsibilities remain separable. Overall Architecture Figure 17. Template-aware document compilation CERBERUS DATA / MEANING | v FORMULA / READER Slot bindings | v +------------------+ | TEMPLATE | | Regions / Slots | | Geometry / Rules | +---------+--------+ | visual Slots | v SOLAR | v MIRROR exact visual material | v +------------------+ | TEMPLATE RENDERER| +----+--------+----+ | | +----+--+ +--+---------+ | DOCX | | INTERACTIVE| +-------+ +------------+ | +----------> PDF / STATIC OUTPUT The architecture separates semantic selection, asset routing, layout, and renderer capability. Starter Build Sequence The first implementation can stay intentionally small. The purpose of this paper is to give the next build a stable target rather than to predetermine every renderer feature. Recommended first build Step Deliverable 1 Create Templates, Regions, and Slots as explicit registry objects 2 Implement the six canonical Template families 3 Add Required / Optional / Conditional and fit behavior 4 Bind MIRROR-capable visual Slots to Preferred Image, Asset Folder, exact assets, and models 5 Create one DOCX/static renderer path 6 Use the expanded BitWord graph as the first large-scale structured-content test 7 Connect Formula/Reader outputs to stable Slot IDs Final Compression CERBERUS Template System A reusable bounded presentation architecture in which Templates contain Regions, Regions contain addressable Slots, Readers bind semantic content to those Slot identities, SOLAR MIRROR resolves visual material, and renderers manifest the same logical contract across static and interactive surfaces. Reader chooses the Slot. Template places the Slot. MIRROR supplies the asset. Renderer manifests the result.