2 - OCTOGROOVE_AI_Execution_BOOTSTRAP_Guide_v1.0.docx

OCTOGROOVE AI EXECUTION & BOOTSTRAP GUIDE Worked Artifacts for Human-Gated Document Compilation How an AI moves from user intent to a verified professional document through eight controlled passes 1 TYPE 2 GOVERN 3 CONTENT 4 FIGURES 5 ASSETS 6 BUILD 7 COMPOSE 8 VERIFY Decide → Govern → Design → Visualize → Source → Build → Compose → Verify AI Instruction Manual | BOOTSTRAP Reference | Version 1.0 Human-gated execution • explicit artifact ownership • controlled rollback • rendered release verification EXECUTIVE SUMMARY Purpose of This Guide OctoGroove is an eight-pass document-compilation protocol. This guide teaches an AI how to execute it, not merely how to describe it. Every pass consumes approved upstream state, owns a bounded class of decisions, produces an explicit artifact, performs an AI self-check, and stops at a human gate before downstream work becomes authoritative. The worked examples are drawn from real OctoGroove runs. They show user intent becoming a Document Type Declaration, governing constraints becoming a Document Contract, conversation becoming a Content Map, semantic claims becoming Figure Contracts, Figure Contracts becoming numbered asset requirements, approved visuals becoming composed pages, and a candidate DOCX becoming a Verified Release. They also show controlled failure: a later pass can discover an upstream defect, stop, roll back to the pass that owns the mistake, repair the dependency, and resume without silently patching the wrong layer. BOOTSTRAP directive When this guide is loaded for document creation, first determine the active pass and identify the approved upstream artifacts. Perform only the decisions owned by the active pass. Produce its artifact, run its completion check, and stop for human approval. If downstream work exposes an upstream defect, return to the earliest pass that owns it. Do not silently cross a human gate. What the reading AI should learn How to identify the current OctoGroove pass before acting. Which decisions belong to each pass and which decisions must wait. What artifact each pass must produce before it can close. How APPROVE, REVISE, ROLLBACK, BLOCKED, REOPENED, and STALE change execution state. How semantic QA differs from visual QA. Why Pass 7 composes approved architecture rather than reinventing it. Why a saved file is not complete until Pass 8 renders and verifies the artifact. Scope This is an execution and BOOTSTRAP guide. It does not teach Microsoft Word generally, diagramming generally, image licensing in depth, or the subject matter of the worked SCE examples. Subject-specific examples are included only to demonstrate how OctoGroove manipulates information across passes. NAVIGATION Guide Map Part What it teaches I — Operator Model The pass grammar, artifact spine, active-pass routing, Pass Record, and state model. II — Passes 1–3 How user intent becomes an artifact class, a governing contract, and an approved semantic architecture. III — Passes 4–5 How semantic claims become Figure Contracts, then stable visual requirements and asset identities. IV — Rollback & Dependencies How a later pass detects an upstream omission, rolls back, marks affected work stale, and resumes. V — Pass 6 How approved contracts become real assets and figures, with semantic and visual QA. VI — Pass 7 How the approved semantic and visual architecture is composed into a coherent document. VII — Pass 8 How the candidate document is rendered, inspected, repaired, rerendered, and released. VIII — BOOTSTRAP Reference A compact execution model, pass ownership rules, identity rules, and five questions the AI should always answer. Central transformation INPUT → PASS TRANSFORMATION → OUTPUT ARTIFACT → AI CHECK → HUMAN GATE → APPROVED STATE → NEXT PASS PART I The Operator Model OctoGroove is a controlled transformation system. The first job is to know the current state, not to start writing. 1. One Pass Has a Stable Internal Grammar Every OctoGroove pass follows the same operating pattern. The AI reads approved upstream artifacts, performs only the reasoning owned by the active pass, creates a bounded output artifact, checks its own work, and presents the artifact for human review. The human can approve the pass, request revision within the same pass, or roll the build back to an earlier owner. Figure 1. One OctoGroove pass: approved inputs become a reviewable artifact, then stop at the human gate. A pass transforms approved input into a reviewable artifact. It does not silently advance itself. 2. The Eight-Pass Artifact Spine The final document is only one artifact in a longer compilation chain. Document Type, Document Contract, Content Map, Figure Manifest, Asset Manifest, production outputs, Document Candidate, and Verified Release are all explicit intermediate states. Each exists so downstream work can be checked against something more precise than conversational memory. Figure 2. The eight-pass artifact spine: each pass emits a defined artifact that constrains the next pass. Pass Primary artifact 1 — Type Document Type Declaration 2 — Govern Document Contract 3 — Content Content Map 4 — Figures Figure Manifest + Figure Contracts 5 — Assets Asset Manifest + numbered requirements 6 — Build Asset Pool + Figure Set + Production QA 7 — Compose Document Candidate 8 — Verify Verified Release + QA result 3. Find the Active Pass Before Acting An AI should not infer that “make me a professional paper” means “begin Pass 7.” The request identifies the intended final artifact, but the current build state determines the next action. If Passes 1 and 2 are already satisfied by a known document profile and writing specification, Pass 3 may be active immediately. If no Content Map exists, composition is premature. Figure 3. Active-pass routing: pre-satisfied upstream passes remain authoritative while the first unresolved pass becomes active. Pre-satisfied is not skipped A pass may already be satisfied by BOOTSTRAP, a known document profile, or an approved Writing Spec. Its artifact still exists conceptually and still constrains the build. 4. Use a Common Pass Record A stable Pass Record makes the build inspectable. It identifies the pass, status, authoritative inputs, owned decisions, output artifact, unresolved questions, AI check result, and gate. The structure is deliberately simple enough to reuse in conversation, an AI Skill, a BOOTSTRAP bundle, or a project registry. Figure 4. Anatomy of a Pass Record: the same state schema can govern all eight passes. Minimal Pass Record Pass: 4 — Figure Architecture Status: READY FOR REVIEW Authoritative Inputs: Pass 1 + Pass 2 + approved Content Map Owned Decisions: figure need, purpose, visual relationships, cautions Output: Figure Manifest + Figure Contracts AI Check: PASS Gate: APPROVE | REVISE | ROLLBACK PART II Passes 1–3: From Request to Meaning The first three passes determine what is being built, what governs it, and what the document must actually say. 5. Pass 1 — Document Type Pass 1 classifies the artifact before content architecture begins. A request such as “write this as a professional Word document” is not yet a paper. The AI uses the user’s request and context to declare the artifact class, delivery format, primary mode, and intended use. This avoids treating every document request as the same generic report. Figure 5. Pass 1 worked transformation: user intent becomes a Document Type Declaration. Manipulation Unstructured user intent → explicit artifact class. 6. Pass 2 — Document Contract Pass 2 binds the artifact to a governing template, writing specification, style, and QA expectation. An exact document-specific specification is useful when one exists, but OctoGroove does not require the AI to fabricate an elaborate new standard whenever it does not. The strongest approved applicable standard can satisfy the pass for the current build. Figure 6. Pass 2 worked transformation: the approved artifact type is bound to explicit document rules. Provisional does not mean undefined. Manipulation Artifact class → explicit governing constraints. 7. Pass 3 — Content Architecture Pass 3 turns discussion, notes, corrections, and source material into a semantic hierarchy. Its output is not polished prose. It is the approved architecture of meaning: thesis, sequence, scope, terminology, section relationships, examples, and non-scope. The AI is allowed to reorganize raw conversation into a coherent argument, but it should preserve authoritative terminology and surface unresolved material decisions instead of guessing them downstream. Worked example: a single correction changes the center of gravity During the SCE build, the user clarified that the Atlas runtime stages map to Bits and routing, and that once those contracts are defined for Assets, the same computational process applies. That correction changed the paper from a loose collection of simulation topics into an argument centered on a shared computational grammar. Figure 7. Pass 3 worked transformation: an architectural correction from conversation becomes a new semantic hierarchy. Manipulation Conversation → semantic hierarchy. Pass 3 owns meaning and sequence Core proposition and thesis. Major sections and their order. Scope and explicit non-scope. Terminology and conceptual relationships. Which examples deserve worked treatment. Which concepts appear likely to need visual explanation later. Do not cross the boundary Pass 3 may note that a concept needs visual explanation. It does not yet number, source, or construct the figure. PART III Passes 4–5: Make Meaning Visible and Buildable The visual passes first specify explanatory obligations, then identify the visual ingredients needed to satisfy them. 8. Pass 4 — Figure Architecture A Figure Contract is not a request for decoration. It is a semantic obligation. Pass 4 asks which concepts need visual explanation, what each figure must teach, what relationships must appear, and what misunderstandings the drawing must avoid. This turns approved Content Architecture into a parallel visual argument before any image sourcing begins. Figure 8. Pass 4 worked transformation: a semantic claim becomes a Figure Contract. Manipulation Semantic proposition → visual obligation. 9. MUST SHOW and MUST NOT IMPLY Positive requirements tell the figure what it must communicate. Negative constraints protect the document from plausible but incorrect visual interpretations. This is especially important when diagrams compress complex architecture: a polished arrow, nesting box, or branch can imply ownership or equivalence that the prose never intended. Figure 9. Figure Contract safety: positive obligations and negative implications are checked together. A figure can be visually elegant and still teach the wrong architecture. 10. Pass 5 — Asset Architecture Once figures have defined obligations, Pass 5 determines which visual ingredients must exist to make those figures buildable. Stable asset identities are assigned to requirements before sourcing or generation. This reverses the common image-first workflow in which a convenient file gradually dictates what the figure means. Figure 10. Pass 5 worked transformation: Figure Contract dependencies become numbered asset requirements. Manipulation Figure dependency → stable asset requirement. 11. Stable Identity, Replaceable Implementation The asset identifier belongs to the visual role, not to the first file that happens to satisfy it. A photograph may be replaced by a generated illustration; a crop may be replaced by a cleaner source; a local canonical screenshot may be redrawn for document scale. If the role remains the same, the stable identity allows dependent figures and manifests to remain intelligible. Figure 11. Stable asset identity: an asset requirement can survive source replacement without changing its semantic role. Do not search first Define what visual role is needed, assign its identity, then acquire or generate an implementation. PART IV Rollback, Blocking, and Dependency Staleness OctoGroove is not a one-way checklist. It is a controlled dependency system that can stop and repair itself. 12. Worked Rollback — Fix the Defect Where It Is Owned The SCE build produced a useful real failure case. Pass 5 audited the approved Content Map against the Figure Manifest and found three content concepts that did not yet have adequate visual coverage: seasonal and generational continuity, natural baseline with civilization and reclamation, and general projection independence. The wrong response would have been to invent asset requirements and compensate inside Pass 5. Asset Architecture did not own the missing explanatory decisions. The correct response was to mark Pass 5 blocked, reopen Pass 4, add the missing Figure Contracts, approve Pass 4 again, and then resume Pass 5. Figure 12. Real OctoGroove rollback: Pass 5 detects missing Figure Architecture and returns the build to Pass 4. Correct an error in the earliest pass that owns it. 13. Dependency Staleness Is Selective Reopening an upstream pass can invalidate downstream assumptions, but it does not require deleting the entire build. A changed Figure Contract may stale one asset requirement and one finished figure while leaving twenty-four others unaffected. OctoGroove therefore separates dependency staleness from automatic destruction. Figure 13. Dependency staleness: an upstream revision triggers impact assessment rather than indiscriminate rebuilding. Condition Meaning BLOCKED The active pass cannot continue correctly because a required dependency is unresolved. REOPENED A previously approved pass has been returned to active consideration. STALE A dependency changed; the artifact must be reassessed before it can still be treated as authoritative. REVISE Human requests change within the current pass. ROLLBACK Execution returns to an earlier pass because that pass owns the incorrect or missing decision. PART V Pass 6: Build the Approved Visual System Production is where abstract requirements become real files. The build remains constrained by the Figure Contracts that justified it. 14. Pass 6 — Asset and Figure Production Pass 6 acquires, generates, derives, and composes the approved visual ingredients. Each Figure Contract is combined with its asset dependencies and canonical references, then built into a finished figure. Production is not complete when an image looks polished. It must pass both semantic and visual checks. Figure 14. Pass 6 production pipeline: Figure Contracts, Asset Dependencies, and canonical references become checked finished figures. 15. Semantic QA — Pretty but Wrong During SCE production, the first Map projection figure generalized Map into Game, Film, and Prose. The drawing was coherent, but it violated the Figure Contract. That contract owned Map representations specifically. The corrected figure used Game Map, Strategic Map, Debug Map, Educational Map, and Cinematic Layout. General media projection belonged to a different figure. Figure 15. Semantic QA failure: a polished figure can fail when it teaches a relationship outside its approved contract. Aesthetic success does not equal semantic success. 16. Visual QA — Correct Meaning, Poor Execution Semantic correctness does not guarantee legibility. The Infinite World Loop contained the right conceptual layers, but production still had to preserve all 0–9 Ring positions while keeping computational substrate, active runtime, world fabric, continuity, and projection independently readable. Crowding required a rebuild even though the intended meaning was already correct. Figure 16. Visual QA failure: a semantically correct figure is rebuilt when its information cannot be read reliably. 17. Two Independent Quality Axes Pass 6 should evaluate every figure on two axes. Semantic QA asks whether the figure teaches the approved meaning. Visual QA asks whether a human can actually perceive that meaning at the intended document size. The most dangerous failure is a visually excellent figure that is semantically wrong because its polish can conceal the defect. Figure 17. Semantic QA versus visual QA: polished-and-wrong is a distinct and dangerous failure state. Pass 6 completion test The asset exists. The figure exists. The figure matches its contract. The figure is readable at intended size. The production set has been reviewed as a whole. PART VI Pass 7: Compose the Approved Architecture Composition is late on purpose. It is the first pass that turns the already-approved semantic and visual architecture into a continuous reading experience. 18. Pass 7 — Composition By Pass 7, the writer already knows what kind of document is being made, what rules govern it, what the argument is, what the figures must teach, which assets those figures use, and which finished visual files are approved. Composition can therefore concentrate on explanation, transitions, pacing, emphasis, and the relationship between prose and visuals. Figure 18. Pass 7 composition: approved content and visuals are integrated into a coherent reading sequence. Pass 7 composes the approved architecture; it does not silently rediscover it. 19. When Writing Exposes an Upstream Problem Composition can still discover defects. A paragraph may reveal that an argument is incomplete, a figure may not support the surrounding explanation, or an asset may be missing. The discovery occurs in Pass 7; ownership may lie elsewhere. The AI should classify the defect and route it to the earliest owning pass instead of solving every problem by improvising more prose. Figure 19. Diagnostic routing from Pass 7: content, figure, asset, and visual-production defects return to their owning passes. Problem discovered during composition Owning pass The argument itself is incomplete or incorrectly ordered. Pass 3 — Content Architecture The visual explanation is conceptually missing or misleading. Pass 4 — Figure Architecture The required visual ingredient has never been specified. Pass 5 — Asset Architecture The figure is specified correctly but executed poorly. Pass 6 — Production The prose, spacing, page flow, or figure placement is poor. Pass 7 — Composition PART VII Pass 8: Verify the Artifact That Actually Exists A DOCX that saves successfully is only a candidate. Release requires rendered conformance and visual inspection. 20. Pass 8 — Conformance and Visual QA Pass 8 compares the composed document with the approved upstream architecture and then verifies the rendered artifact. The DOCX is rendered to page images, every page is inspected, defects are repaired in the owning layer, and the document is rerendered. Accessibility and structural audits can be added where relevant. The release gate is based on the artifact as a reader receives it, not on the fact that a program wrote a valid file. Figure 20. Pass 8 QA loop: render, inspect, repair, rerender, and verify. Worked SCE verification event 40-page candidate rendered → blank-page defect detected → composition repaired → all 31 figures audited for accessibility descriptions → corrected document rerendered → every page visually inspected before release. A successful save operation does not constitute completion; release follows rendered conformance and artifact QA. PART VIII Cross-Pass Learning and BOOTSTRAP Execution The method becomes easiest to understand when one idea is followed through every representation it acquires. 21. One Idea Traveling Through OctoGroove The statement “the world exists between frames” began as an architectural idea. OctoGroove did not preserve that sentence by copying it everywhere. It preserved the meaning while changing its representation at each pass. Pass 3 made it a semantic claim. Pass 4 turned the claim into a Figure Contract. Pass 5 identified Bat, Elk, and forest assets. Pass 6 built the figure. Pass 7 integrated it into the opening argument. Pass 8 verified the figure in the rendered document. Figure 21. One idea through OctoGroove: semantic identity is preserved while representation changes from conversation to verified artifact. Manipulation across passes Idea → Semantic Claim → Figure Contract → Asset Requirements → Authored Figure → Document Section → Verified Artifact 22. Related Does Not Mean Identical Cross-pass objects are linked but should not be collapsed. A concept is not a Content Map entry; a Figure Contract is not the same object as an asset; an asset identity is not the same as the file currently implementing it; a finished figure is not the same as its placement in the final DOCX. Preserving these distinctions is what makes replacement, rollback, and dependency tracking possible. Figure 22. Cross-pass identity: concept, Content Map entry, Figure Contract, Asset Requirement, Asset File, Finished Figure, and Document Placement are related but distinct objects. Contextual artifact role A finished SCE figure was a Figure in the SCE paper. When reused as evidence in this guide, the same file becomes an input Asset to a new instructional Figure. Artifact role is contextual; provenance is retained. 23. DO NOW / DO NOT YET Pass ownership is easier to execute when each pass has an explicit permission boundary. The AI should know not only what it may do now, but what it must deliberately defer. Figure 23. Pass ownership quick reference: every OctoGroove pass has a DO NOW responsibility and a DO NOT YET boundary. 24. Pass State Machine States describe the condition of an artifact or pass. Actions describe what the human or execution controller does. Keeping these categories distinct prevents phrases such as “rollback state” or “approve status” from becoming ambiguous in AI Skills and project records. Figure 24. OctoGroove pass state machine: normal lifecycle states are separated from independent blocked and stale conditions and from gate actions. State / action Operational meaning NOT STARTED No work is authorized for this pass yet. ACTIVE This pass currently owns the build work. READY FOR REVIEW The AI has produced the pass artifact and believes its checklist is satisfied. APPROVED Human accepts the artifact as authoritative downstream input. REOPENED An approved artifact has been returned to active consideration. BLOCKED The pass cannot proceed correctly because a dependency is unresolved. STALE A dependency changed and validity must be reassessed. APPROVE / REVISE / ROLLBACK Human gate actions, not artifact states. 25. BOOTSTRAP to Verified Release A BOOTSTRAP bundle can pre-satisfy familiar decisions. For example, an AI may load this guide together with a Professional Paper Writing Spec and a known Document Profile. Passes 1 and 2 can then be identified as already approved while Pass 3 becomes active. The method remains intact because the outputs of the earlier passes are still identifiable and authoritative. Figure 25. BOOTSTRAP to Verified Release: the complete executable mental model for an unfamiliar AI. What pass am I in? What approved artifacts constrain me? What decisions belong to this pass? What artifact must I produce? Has the human approved advancement? 26. BOOTSTRAP Instruction Block Instruction for the reading AI When using OctoGroove, first determine the active pass and authoritative approved upstream artifacts. Perform only decisions owned by the active pass. Produce the corresponding pass artifact, run its completion checklist, present the result to the human, and wait for approval before advancing. Do not silently cross human gates. If downstream work exposes an upstream defect, mark the current pass blocked or affected outputs stale and return to the earliest pass that owns the incorrect decision. Composition occurs only after content, figure architecture, asset architecture, and visual production are approved. A document is complete only after conformance and rendered visual QA. Ten execution rules Rule Instruction Active Pass Rule Only make authoritative decisions owned by the active pass. Approved Input Rule Approved upstream artifacts constrain downstream work. Artifact Output Rule Every pass must produce its defined artifact before closing. Human Gate Rule Do not silently advance across a human approval gate. Earliest Owner Rule Correct defects in the earliest pass that owns the wrong decision. Staleness Rule Changed dependencies require downstream impact assessment. Semantic QA Rule A visually polished output can still fail its semantic contract. Composition Rule Composition consumes approved architecture rather than reinventing it. Verification Rule A successful file operation does not constitute artifact completion. Pre-Satisfied Pass Rule A pass may already be resolved, but its governing artifact must still be identifiable. 27. Compact End-to-End Trace Normal execution USER REQUEST ↓ PASS 1 Document Type Declaration ↓ HUMAN GATE PASS 2 Document Contract ↓ HUMAN GATE PASS 3 Content Map ↓ HUMAN GATE PASS 4 Figure Manifest + Contracts ↓ HUMAN GATE PASS 5 Asset Manifest ↓ HUMAN GATE PASS 6 Assets + Figures + Production QA ↓ HUMAN GATE PASS 7 Document Candidate ↓ HUMAN GATE PASS 8 Conformance + Rendered QA ↓ VERIFIED RELEASE Correction execution DEFECT DISCOVERED ↓ IDENTIFY EARLIEST OWNING PASS ↓ ROLL BACK / REOPEN ↓ CORRECT UPSTREAM ARTIFACT ↓ REASSESS DOWNSTREAM STALENESS ↓ REBUILD ONLY AFFECTED DEPENDENCIES ↓ RESUME 28. Closing Operator Test An AI executing OctoGroove should always be able to answer five questions before doing substantial document work. If any answer is unclear, the build state is not sufficiently resolved to proceed safely. Question Why it matters 1. What pass am I in? Determines which decisions the AI currently owns. 2. What approved artifacts constrain me? Prevents downstream reinterpretation of settled decisions. 3. What decisions belong to this pass? Defines the current reasoning boundary. 4. What artifact must I produce? Makes completion concrete and reviewable. 5. Has the human approved advancement? Preserves human authority over meaningful semantic and design commitments. PART A Appendix: Pass Ownership Reference A compact operational reference for BOOTSTRAP, AI Skills, and human supervisors. Eight Passes at a Glance # Pass Owns Output 1 Document Type Classify the artifact. Document Type Declaration 2 Govern Bind template, writing spec, and QA rules. Document Contract 3 Content Architect meaning, sequence, scope, and terminology. Content Map 4 Figures Define what must be visually taught and what must not be implied. Figure Manifest + Contracts 5 Assets Define stable visual requirements before implementation. Asset Manifest 6 Build Acquire/generate assets, construct figures, run semantic + visual QA. Asset Pool + Figure Set 7 Compose Write and integrate approved semantic + visual architecture. Document Candidate 8 Verify Check conformance, render every page, inspect, repair, rerender. Verified Release The DO NOW / DO NOT YET discipline Pass Boundary 1 — Type Do classify the artifact. Do not draft it. 2 — Govern Do establish the contract. Do not brainstorm the entire content architecture. 3 — Content Do architect meaning. Do not build figures. 4 — Figures Do define visual obligations. Do not search random images. 5 — Assets Do define requirements and identities. Do not let source files dictate meaning. 6 — Build Do construct and verify. Do not approve on appearance alone. 7 — Compose Do integrate approved architecture. Do not silently invent new architecture. 8 — Verify Do render, inspect, repair, and rerender. Do not equate save success with completion. APPENDIX B Appendix: Evidence and Provenance The worked examples in this guide are based on actual OctoGroove outputs and controlled derived evidence. Evidence Classes Class Meaning LOCAL-ACTUAL A real artifact produced during an OctoGroove run, such as a completed document cover or finished SCE figure. DERIVED-ACTUAL A crop, excerpt card, manifest rendering, or comparison built from an actual execution event. GENERATED-INSTRUCTIONAL A visual component created specifically to explain the protocol, such as pass badges or operator symbols. NATIVE-FIGURE An instructional diagram constructed directly from shapes, text, and arrows without external image dependencies. The examples are intentionally labeled so a reading AI can distinguish literal prior output from an instructional reconstruction. A discarded failed figure may be reconstructed from the execution record for teaching purposes, but it should be marked as derived rather than presented as an original surviving file. Primary worked-build evidence GROOVED PASS / OctoGroove methodology paper — a completed professional document produced through the method. CERBERUS Storyboard Continuity Engine v0.2 — a 40-page verified release containing 31 custom figures. SCE Figure Manifest and Asset Manifest — machine-readable intermediate pass artifacts. SCE Pass 5 rollback event — actual detection of missing Figure Architecture during Asset Architecture. SCE Map Projection correction — actual semantic Figure Contract failure and rebuild. SCE Infinite World Loop rebuild — actual visual QA correction. SCE Pass 8 render cycle — actual pagination repair, accessibility audit, rerender, and release verification. Provenance rule Actual output can become an input asset in a later document. Its role may change; its provenance should not.