CERBERUS PATCH Procedural AI Transmission Communication Handbook Scaffolding • Human-AI • Governance • Transformation • Portability CORE SYSTEM STATEMENT PATCH is a temporary, machine-legible communication and reasoning layer for inspecting, describing, proposing, comparing, routing, and staging change around a canonical system without making the proposal canonical. SHORT FORM Express the change. Gate the change. Commit the change. Remove the conversation. Version 0.1 • 7 September 2026 • Pass 8 Verified Release ​ Abstract PATCH formalizes a practical class of temporary work that often appears during human-AI system building: inspection notes, migration cues, candidate links, approval checkboxes, comparison fields, routing instructions, connector workarounds, and other scaffolds that are useful while a change is being reasoned about but should not become part of the finished architecture. The system gives these temporary structures an explicit grammar, a bounded semantic habitat, a human-gated lifecycle, and a deletion invariant. The central safety claim is deliberately narrow: deleting a PATCH may destroy temporary reasoning, review progress, or coordination state, but it must not change canonical Base state. PATCH is therefore disposable with respect to the Base, even when it is valuable to the current work. This separation makes aggressive analysis compatible with restrained execution. LOSSY TO THOUGHT. HARMLESS TO STATE. Reader destination Understand what PATCH is, what it is not, and why it exists. Read and write the P1, P2, and P3 notation. Resolve a PATCH Habitat from context and narrow the available P1 vocabulary. Reuse BOSS Structural Operators inside temporary PATCH relations without creating canonical edges. Use human gates to separate proposal from mutation. Apply PATCH Waves to table cleanup, migration, porting, and other bounded transformations. Implement the first PATCH System Tables without prematurely freezing recurring P2/P3 groupings. ​ Contents Section Topic 1 System proposition and safety boundary 2 Natural habitat and contextual resolution 3 P1/P2/P3 grammar 4 Structural operators and relational PATCHes 5 Human gates and the PURGE pattern 6 PATCH Waves and temporal co-presence 7 Routing across Habitats 8 PORT: Airtable to SQLite 9 Complete lifecycle 10 Implementation handoff 11 Starter P1 and Habitat registries 12 Normative rules and conformance 13 Evolution, pruning, and teleological use 14 Conclusion ​ PATCH SYSTEM LAW NON-AUTHORITY PATCH can matter to the work without becoming a truth layer or runtime dependency. 1. System proposition and safety boundary PATCH exists to make proposed transformation visible before it becomes state. A human and an AI can inspect the same operational surface, attach temporary notes or structured fields, compare old and proposed structures, express uncertainty, stage candidate actions, and record approval without immediately rewriting the canonical Base. This creates a clean separation between thought and state. The PATCH layer may be richly structured and machine-legible, but the finished system must remain able to operate when the entire PATCH layer is removed. A PATCH is disposable with respect to the Base, not necessarily disposable with respect to the current work. 1.1 Deletion safety Deleting a PATCH can be operationally lossy. It may erase an AI recommendation, a comparison, a candidate mapping, a human selection, or the record of how far a review had progressed. That loss can force the work to be repeated. What deletion must not do is alter canonical records, break canonical links, change governed Models, remove authoritative values, or change runtime behavior. Allowed loss: temporary analysis, recommendations, candidate mappings, review status, human notes, and PATCH-to-PATCH coordination. Forbidden consequence: any change to canonical Base state merely because PATCH scaffolding was removed. Conformance test: delete the PATCH. If canonical state or canonical behavior changes, the scaffold was not a valid PATCH. ​ ​ ​ PATCH SYSTEM LAW HABITAT BOUNDING PATCHes live where their problem lives; context determines which temporary tools are sensible. 2. Natural habitat and contextual resolution PATCH is not a single undifferentiated toolbox. A table-to-table structural problem belongs in different semantic territory from a Reader decoding problem or an Airtable-to-SQLite port. PATCH therefore separates what an operation does from where that operation makes sense. PATCH Class describes the temporary operational meaning. PATCH Habitat describes the semantic environment in which that operation is valid, useful, or restricted. This lets the system derive a bounded list of available PATCHes from context before matching the list against intent. ​ 2.1 Initial Habitats The first Habitat map is intentionally provisional. It is a starting topology for real use, not a claim that the list is eternally exhaustive. The important invariant is the bounding mechanism: specialized PATCHes remain close to the Stack or boundary that already owns the underlying meaning. Habitat Natural territory GENERAL Local fields, records, notes, verification, selection, temporary governance. VISOR Table-to-table, Stack-to-Stack, and other explicit structural relationships. QUIVER Interface bindings, controls, display surfaces, and human interaction structures. SOLAR Lexical routes, aliases, names, and human-facing references. BIGFOOT / BOSS Semantic construction, symbolic placement, and governed structural operators. DRAGON Registration, Determination, Models, operations, and values. READER BitWord interpretation, bindings, validation, width, version, and decode behavior. MIRROR Bounded graph membership, edges, branches, and graph limits. DARTBOARD Runtime route selection, fallbacks, redirects, and resolution. PIECE / EDIFICE Composition, placement, component replacement, and assembly. BOOTSTRAP Learning sequence, resources, instructions, and navigation. PORT Representation-to-representation or system-to-system translation. CONNECTOR Tool/API capability gaps and operational workarounds. HUMAN Authorization, semantic adjudication, preference, and bounded choice. ​ ​ ​ ​ PATCH SYSTEM LAW COMPRESSION GRAMMAR P1 carries one meaning; P2 and P3 are composition boundaries, not new semantic primitives. 3. P1, P2, and P3 grammar PATCH begins with P1. A P1 expresses one temporary operational meaning. Richer structures emerge by placing P1s together. The system does not need to invent a second meaning layer for P2 or P3: a PATCH Group is simply a useful composition of P1s, and a PATCH Cluster is a useful boundary around multiple Groups. The notation makes those boundaries visible directly in field names. This reduces metadata, helps humans scan the table, and lets an AI recover the temporary sentence structure mechanically. X = interior. XX = Group boundary. XXX = Cluster boundary. ​ 3.1 P2 - PATCH Group A P2 does not deserve a registry entry merely because a combination is possible. The initial system should allow arbitrary useful P1 composition and observe which combinations recur. Stable P2 templates are harvested from actual work rather than designed in advance. A relational Group such as |XX| Legacy Field | / |X| COMPARE |X| / | Proposed Field |XX| is already a complete temporary statement. The first and last fields mark the group boundary; middle fields carry operators, gates, notes, or additional operands. 3.2 P3 - PATCH Cluster P3 applies the same idea one level outward. The first opening XX boundary becomes XXX and the final closing XX boundary becomes XXX. Everything inside remains ordinary P2 grammar. This is enough to mark a larger bounded transformation Wave without inventing separate Cluster semantics. ​ ​ PATCH SYSTEM LAW OPERATOR REUSE PATCH can temporarily use the existing CERBERUS language rather than inventing another relational vocabulary. 4. Structural operators and relational PATCHes Where a PATCH is relational, BOSS can supply the structural verb. The canonical meaning of COMPARE, REPLACE, LINK, MAP, VERIFY, TRANSLATE, or another registered operator remains owned by BOSS. PATCH merely applies that meaning temporarily to bounded operands. This distinction matters: a canonical operator does not make the temporary relation instance canonical. The PATCH relation can be deleted, rejected, or replaced without altering the operator definition or the Base. BOSS owns operator semantics. PATCH owns only the temporary invocation and its local operands. A PATCH reference or operand pointer is scaffolding, not a permanent graph edge. If a temporary relation becomes approved canonical structure, that canonical relation is written through the owning system, not by preserving the PATCH as architecture. ​ ​ PATCH SYSTEM LAW HUMAN SEPARATION Writing a proposal and committing the proposal are distinct events. 5. Human gates and the PURGE pattern The original PATCH pattern emerged from a simple connector limitation. An AI could identify registry records pointing at tables that no longer existed, but deletion should remain human-gated. A temporary PURGE checkbox let the AI mark candidates directly in the Base while the human retained the destructive decision. This small pattern contains most of the architecture: machine inspection, visible temporary state, explicit human review, optional execution, and removal of the scaffold afterward. The checkbox is useful precisely because it is not the deletion itself. The Base only changes when an authorized operation crosses the human gate. ​ 5.1 Human gate semantics APPROVE - authorize the proposed canonical operation. REJECT - explicitly decline the proposal. HOLD - preserve the current PATCH for later work without committing it. SELECT - choose one among bounded alternatives. VERIFY - confirm that an expected condition or postcondition is true. PURGE - mark a target as a removal candidate; the PATCH itself remains separately purgeable. ​ PATCH SYSTEM LAW PATCH WAVE Aggressive analysis can be staged beside a live table while canonical mutation remains gated. 6. PATCH Waves and temporal co-presence A PATCH Wave is a bounded pass across a Table, Stack, migration region, or other work surface. The AI may insert temporary fields, inspect a defined scope, populate findings, propose replacements, compare old and new structures, and flag records for human review. None of those proposals become canonical merely because the analysis is extensive. This makes a table unusually legible during transformation because three temporal views can be co-present: legacy information that explains how the table arrived here, the actual canonical state that currently runs the system, and the proposed state represented by PATCH scaffolding. ​ ​ 6.1 Empty inspection is valid A PATCH Group may be inserted intentionally before the system knows whether a problem exists. The group then acts as a diagnostic fixture: it bounds the inspection lens, gives the AI a machine-legible place to write if something is found, and remains harmless if nothing is written. A clean result can simply end with scaffold deletion. ​ ​ PATCH SYSTEM LAW ROUTE, DO NOT BLOAT A PATCH should move to the Habitat that owns the real problem instead of dragging unrelated logic into the current one. 7. PATCH ROUTE across Habitats Investigation sometimes begins in the wrong semantic territory for good reasons. A Table-to-Table review may begin in VISOR, only to discover that the structural relation is correct and the actual problem is that an Airtable representation does not translate cleanly into SQLite. PATCH ROUTE moves the temporary work into PORT rather than teaching VISOR how to solve porting problems. The rule is simple: routes cross Habitats when the problem itself crosses Habitats. Local issues should not be routed away merely to avoid solving them, and the route remains temporary even when both endpoint Habitats are canonical systems. ​ ​ PATCH SYSTEM LAW PORT Representation gaps are information. PATCH makes the gap explicit before a permanent mapping is chosen. 8. PORT: Airtable to SQLite PORT is the immediate practical Habitat for the next CERBERUS migration phase. Airtable and SQLite can represent many of the same concepts, but their native field types, linked-record semantics, formulas, lookups, rollups, interfaces, and application behaviors do not map one-to-one. A PORT PATCH stages source, proposed translation, destination, verification, and approval without pretending the mapping is already settled. The field-type examples in Figure 17 are illustrative. They communicate the shape of the work, not a frozen portability standard. Real migration will refine the registry as actual schema cases are encountered. ​ 8.1 PORT design principle Expose a representation gap instead of silently inventing a mapping. Keep source and destination identities explicit. Use TRANSLATE or TYPE MAP only where the context belongs to PORT. Require human review where multiple mappings are plausible or semantics could change. Once the permanent porting rule exists, remove the temporary PATCH scaffolding. ​ PATCH SYSTEM LAW LIFECYCLE PATCH is a temporary conversation about a change that ends with either no change or a governed canonical change. 9. Complete PATCH lifecycle The complete lifecycle begins with a gap, resolves the semantic Habitat, selects the eligible P1 operation, composes additional P1s if necessary, inserts temporary scaffolding, and performs the bounded inspection. A human then reviews the visible proposal. Rejected or unnecessary work can be deleted; approved work is committed through the canonical owner, verified, and followed by PATCH removal. EXPRESS THE CHANGE. GATE THE CHANGE. COMMIT THE CHANGE. REMOVE THE CONVERSATION. The lifecycle is intentionally tolerant of failure and revision. A bad PATCH is not protected. Delete it, rewrite it, or PATCH the PATCH. The architecture remains safe because canonical systems are forbidden from depending on temporary scaffold state. ​ PATCH SYSTEM LAW IMPLEMENTATION HANDOFF Build the permanent vocabulary and Habitat registries first; let recurring Groups and Clusters emerge from use. 10. Implementation handoff The first implementation should be deliberately small. PATCH needs permanent definitions for atomic operations and the semantic Habitats that constrain them. It does not yet need a large library of pre-wired P2 or P3 templates. Those should be harvested after repeated real-world use reveals stable groupings. 10.1 PATCH P1 Registry - provisional fields Field Suggested type Purpose PATCH ID Stable identifier Permanent registry identity for the P1 definition. PATCH Name Short text Human-facing atomic operation name. Meaning Long text Exact temporary operational meaning; one P1 should express one meaning. Habitat Linked records Habitat or Habitats in which the P1 is eligible. Target Types Multiple select / linked records Allowed operands or target surfaces: Field, Record, Table, Stack, Model, System, etc. Compatible Intent Multiple select Compare, repair, migrate, verify, document, translate, approve, and other intents. Input Form Single select Text, checkbox, link, select, number, operator, reference, or other working representation. Authority Rule Single select Informational, human-gated, destructive-gated, or other authority condition. BOSS Operator Optional link Canonical operator invoked by the PATCH where applicable. Availability Constraints Long text Additional capability, context, or exclusion conditions. Example Long text Representative use in a target Table/Stack. Status Single select Candidate, Active, Deprecated, Experimental. Notes Long text Implementation observations and discovered edge cases. 10.2 PATCH Habitat Registry - provisional fields Field Suggested type Purpose Habitat ID Stable identifier Permanent identity for the Habitat definition. Habitat Name Short text GENERAL, VISOR, PORT, READER, etc. Owning Stack / Boundary Link or text Canonical system or system boundary that owns the underlying semantics. Eligible Entity Types Multiple select Kinds of operands that can appear in this Habitat. Available P1s Linked records Atomic PATCHes normally exposed in this Habitat. Excluded P1s Linked records Operations explicitly inappropriate here. Default Gate Single select Optional default authority requirement. Description Long text Why this Habitat exists and what it bounds. Notes Long text Practical routing and implementation observations. 10.3 Temporary field implementation PATCH Instances may initially remain exactly what inspired the architecture: temporary fields placed beside the canonical thing being inspected. The field name carries the PATCH notation; the field type carries the immediate working value; the permanent P1 and Habitat registries explain the semantics. Those temporary fields should never receive canonical downstream dependencies. Where a temporary field points to a canonical Table, Field, Record, Model, or another PATCH, the pointer is scaffolding. Removing it may lose the current work context, but it must not sever a canonical relationship. ​ PATCH SYSTEM LAW STARTER VOCABULARY The list below is a starting map. Real use is expected to merge, split, rename, or retire candidate P1s. 11. Starter P1 and Habitat registries The starter vocabulary is intentionally permissive enough to begin experimentation while remaining small enough to inspect. A candidate P1 should survive only if it adds operational distinction beyond an existing generic P1 combined with Habitat and context. For example, WIDTH may later collapse into ISSUE @ READER if no separate behavior justifies the extra primitive. P1 Atomic meaning Likely Habitat INFORMATION State useful temporary information GENERAL / many ISSUE Mark a detected problem GENERAL / many VERIFY Request or record confirmation GENERAL / many COMPARE Evaluate two bounded operands GENERAL / BOSS REFERENCE Point to context without canonical linkage GENERAL SELECT Choose among bounded alternatives HUMAN / GENERAL APPROVE Human authorization gate HUMAN / GENERAL HOLD Do not proceed yet HUMAN / GENERAL PURGE Mark removal candidate GENERAL / CONNECTOR PATCH ROUTE Continue work in another PATCH scope GENERAL / cross-Habitat REDUCTION Fewer components, equivalent required result GENERAL structural EXPANSION Add structure for new capability GENERAL structural MERGE Combine structures GENERAL structural SPLIT Separate overloaded structure GENERAL structural REPLACE Substitute one structure for another GENERAL structural RENAME Change human-facing label GENERAL / SOLAR MOVE Relocate same thing GENERAL structural MIGRATE Transfer useful state into a new structure GENERAL / PORT BACKFILL Populate missing state from authority GENERAL NORMALIZE Bring representation to governed form GENERAL / PORT LINKAGE Propose structural relation VISOR UNLINK Propose removal of relation VISOR RELINK Propose different relation target VISOR CARDINALITY Inspect/propose relationship multiplicity VISOR TRANSLATE Map one representation to another PORT TYPE MAP Map source type to destination type PORT PORT GAP Mark no direct equivalent PORT SOURCE Identify source representation PORT DESTINATION Identify destination representation PORT BIND Propose interface/system binding QUIVER UNBIND Propose removal of interface binding QUIVER DISPLAY Describe display behavior QUIVER INPUT Identify interaction input QUIVER OUTPUT Identify interaction output QUIVER REGISTER Propose Registration DRAGON DETERMINE Propose Determination DRAGON MODEL Associate governed Model DRAGON OPERATION Associate operation DRAGON VALUE Propose value/state correction DRAGON BINDING Propose Reader binding READER DECODE Request/test decode READER VALIDATE Test Reader legality/semantics READER WIDTH Flag width issue (candidate primitive) READER VERSION Flag version compatibility issue READER INCLUDE Propose graph membership MIRROR EXCLUDE Propose graph exclusion MIRROR EDGE Propose temporary graph relation MIRROR BOUNDARY Propose graph limiter MIRROR BRANCH Represent alternate graph interpretation MIRROR ROUTE Propose runtime/system route DARTBOARD FALLBACK Provide alternate runtime path DARTBOARD REDIRECT Point runtime work elsewhere DARTBOARD RESOLVE Request/record runtime resolution DARTBOARD SEQUENCE Change instructional order BOOTSTRAP RESOURCE Add/change learning resource BOOTSTRAP INSTRUCTION Propose instructional change BOOTSTRAP NAVIGATION Change learning path or link BOOTSTRAP ​ PATCH SYSTEM LAW NORMATIVE RULES PATCH safety depends more on dependency direction and authority separation than on preventing temporary mistakes. 12. Normative rules and conformance Rule Name Requirement P-R01 Non-Authority A PATCH SHALL NOT become canonical authority merely by existing. P-R02 Deletion Safety Removal of PATCH state SHALL NOT alter canonical Base state. P-R03 Temporary Dependency PATCH structures MAY depend on other PATCH structures; canonical structures SHALL NOT depend on PATCH structures. P-R04 Atomic Meaning A P1 SHOULD express one temporary operational meaning. P-R05 Composition P2 and P3 SHALL be compositions of P1 semantics rather than independent semantic primitives. P-R06 Habitat Bounding Available PATCH operations SHOULD be constrained by the semantic Habitat of the current context. P-R07 Intent Resolution PATCH selection SHOULD match available context against declared operational intent. P-R08 Operator Reuse PATCH MAY temporarily invoke governed BOSS Structural Operators without promoting the temporary relation to canonical status. P-R09 Human Separation Writing a PATCH proposal SHALL remain distinct from committing the proposed canonical mutation. P-R10 Purgeability Completed, rejected, abandoned, or unnecessary PATCH scaffolding MAY be removed without architectural consequence. P-R11 Explicit Boundaries P2/P3 notation SHOULD make temporary composition mechanically recoverable. P-R12 No Forced Persistence PATCH history SHALL NOT be required merely because the PATCH once existed. 12.1 Conformance questions Can the PATCH be deleted without altering canonical Base state? Does any canonical formula, relation, automation, interface, or runtime path depend on the PATCH? Is the proposal visibly distinct from the committed state? If the operation is destructive or ambiguous, is the human gate explicit? Does the PATCH live in the Habitat that actually owns the problem? Could an existing generic P1 plus Habitat/context express the same meaning more cleanly? If a BOSS operator is used, is operator meaning still owned by BOSS rather than redefined locally? When the work is complete, is there a clean purge condition for the scaffold? ​ PATCH SYSTEM LAW TELEOLOGICAL USE The paper gives PATCH a direction to aim for; implementation is expected to mutate the starting vocabulary. 13. Evolution, pruning, and teleological use PATCH is useful precisely because it tolerates provisional structure. The handbook therefore should not be mistaken for a frozen taxonomy. It provides a common destination and a legible starting grammar so experimentation can be compared against something explicit. As the real Base is cleaned and ported, candidate P1s will prove redundant, new ones will appear, and recurring combinations will reveal natural P2 Groups. Later, recurring Groups may reveal P3 Cluster templates. Those discoveries should be registered because they recur, not because the abstract architecture demanded them in advance. If a PATCH definition is wrong, purge or revise it. If two P1s always collapse to the same behavior, merge them. If one P1 hides meaningfully different operational behaviors, split it. If a PATCH recurs often because a native capability is missing, treat recurrence as evidence for building the native capability. When the native capability exists, retire the workaround while preserving the reusable lesson if it remains valuable. PATCH MAY TOUCH THE BUILDING. PATCH MUST NOT BECOME THE BUILDING. ​ PATCH SYSTEM LAW CONCLUSION PATCH makes proposed transformation a first-class temporary object without turning temporary thought into permanent authority. 14. Conclusion PATCH gives CERBERUS a disposable language for thinking about change before change becomes state. It allows a human and an AI to share the same work surface, express observations and proposals in machine-legible form, reuse governed structural language, constrain operations by Habitat, and place explicit gates between analysis and mutation. The result is not safe because PATCH cannot contain mistakes. PATCH can be wrong, incomplete, badly grouped, or useless. The safety comes from dependency direction: temporary scaffold may depend on the Base and on other scaffold, while the Base remains independent of the scaffold. A failed PATCH can therefore be deleted and rebuilt without making the failure architectural. The next step is practical use. Build the P1 and Habitat registries, start inserting PATCH fields during CERBERUS cleanup and porting work, and let repeated patterns reveal which Groups deserve names. The system should become cleaner by being used, not by being protected from revision. EXPRESS THE CHANGE. GATE THE CHANGE. COMMIT THE CHANGE. REMOVE THE CONVERSATION. CERBERUS PATCH • Version 0.1 • Pass 8 Verified Release