OctoGroove_Document_Construction_System_Pass7-2.docx

OCTOGROOVE Document Construction System Shane Conrad Independent researcher Operational paper and workbook companion Pass 7 document candidate • Version 0.2 Abstract OctoGroove externalizes document construction into versioned content, figure contracts, asset requirements, typed placements and evidence-bearing checks. A linked Excel workbook supplies the operational record and Reader surface; physical files remain separately addressable. Eight Passes divide responsibility from type declaration through final verification. This paper specifies the current operating boundaries, explains selective repair and reusable asset lifecycle, and applies the method to its own twelve-section construction. Seven figures connect the readable explanation to concrete workbook examples. Website publication and reviews after 1, 3, 8 and 15 EFFECTS papers are planned subsequent evaluations. Reading route Sections 1–4 establish scope, identity and Pass ownership. Sections 5–9 describe construction, presentation, assets, checks and reuse. Sections 10–12 explain self-application, the website handoff and the trial programme. References identify the supplied project sources; field-level instructions remain in the workbook dictionaries. 1 Purpose and scope OctoGroove is a method for constructing documents from explicit, inspectable project state. It separates the meaning of a paper, the explanatory obligations of its figures, the ingredients needed to build those figures, and the ordered placements used to compose the document. The accompanying workbook makes these decisions addressable through Tables, Fields, records and revision links. This paper describes the operational arrangement and uses that arrangement to construct itself. [1–3] The intended reader is an author, researcher or builder who needs a repeatable process for a technical paper with reusable visual material. The immediate deliverable is a document candidate and its operational record. The longer-term objective is cumulative improvement: later papers should be able to reuse compatible definitions, assets and repairs without reconstructing every earlier decision from conversation. The system is an explicit construction method, not a guarantee that content is true or that all recorded procedures already have an automated executor. A valid reference shows that a target exists. A successful semantic check must separately establish that the target supports the intended claim. A rendered-page check must separately establish that the reader can see and interpret the result. This candidate consolidates the earlier Graph Assembly Fabric architecture around the current workbook. Where the earlier paper assigns different responsibilities to numbered Passes, the current Pass Definitions govern this implementation. Likewise, HEADER now emits a heading only; prose occupies CONTINUANCE placements. Earlier proposals for particular hosting services, live asset routing and human-gated generation are not prerequisites for this offline sandbox workflow. [1,2] The present scope includes a twelve-section paper, seven numbered figures, a worked-example workbook and an existing starter reference. Website publication and the EFFECTS trial programme follow later. No speed, cost or quality improvement is claimed as a measured result before those trials. 2 Paper and workbook relationship The paper is the readable explanation of the method. The workbook is the operational surface for a particular build: it stores decisions, links, checks and handoffs. Physical documents, images, source files and evidence remain separate files. A File Revision records their identity, location and hash; it does not place their bytes inside a spreadsheet cell. Figure OG-F01 shows these distinct responsibilities. [1,3] The starter provides a starting structure, field instructions and reusable definitions. The worked example provides inspectable records showing how the structure is populated. Cloning a project means retaining the relevant reference definitions, assigning identities to new project-owned material and clearing execution outcomes that did not occur in the new project. Copying a completed check must never imply that its result applies to new inputs. For offline use, extract the package at one operational root and resolve each Local Path relative to that root. Keep the workbook and its physical dependencies together when moving the package. An Online URL is an optional route, not proof that the file is available offline. Recheck file existence and hashes against the recorded File Revisions after transfer. The current worked workbook supports record lookup and validation through row 1200. The older starter reference retains its row 600 capacity. A matched public starter/worked release must align these capacities and repeat clone and empty-state checks. Native desktop Excel execution remains pending; the current evidence covers exported structures and local Reader behavior. [3] The Reader can resolve a selected link and display the destination fields. That is useful operational behavior, but it does not execute an Assembly Instruction, fetch every external file, or prove that a production document compiler exists. Those actions require an operator or an explicitly implemented executor. OG-F01. The operating package separates reusable definitions, project records, reference examples, and physical files. A recorded file reference does not embed its bytes. 3 Terminology and identity A Table identifies a class of records. A Field Number identifies a slot within that Table. The compact notation is “Table – Field Number – Field Type – Description”. A field address is therefore not a record identity: T25 Field 6 names the Template slot on Document Plans, while OG-PLAN names one particular plan. The full schema contains 33 Tables and 382 Fields. [1] The canonical compact symbols remain in the workbook Table Dictionary and Field Dictionary. This paper and its figures use the declared fallback of Table ID plus readable name where emoji rendering is unreliable. This preserves the exact mapping without substituting a new visual vocabulary. Field numbers remain local to their Table; the same number in another Table does not imply the same meaning. A Record ID identifies a particular row. A Record Revision identifies a versioned payload and records its Artifact ID, revision number, producing run and evidence origin. Artifact identity can persist across revisions; the payload record for an old revision remains available. A File Revision additionally identifies concrete bytes through its path, media type, size and SHA-256 value. When content changes, create a new versioned payload and connect it to the previous revision. Do not silently overwrite historical meaning and keep the same evidence claim. Mutable run status is a separate operational concern: marking a run complete records progress, while replacing a source assertion requires revision provenance. Evidence origin and example status answer different questions. CONTEMPORANEOUS identifies material recorded during the current activity; IMPORTED identifies brought-in material; RECONSTRUCTED identifies history assembled from retained evidence. A DEMO can be created contemporaneously and still illustrate only expected behavior. Neither label establishes that a repair, promotion or generation job was executed. 4 The eight Passes The eight Passes allocate decision ownership. Each Pass consumes inspectable inputs and produces an inspectable output. The Pass Definition is reusable; a Pass Run records one execution in a project. Run Artifacts identify the exact revisions consumed or produced by that run. The current allocation below is taken from the operational workbook. [1] Pass 1 — Type: classify audience, artifact kind and intended use. Output: Document Type Declaration. Pass 2 — Govern: bind writing, formatting, scope and verification requirements. Output: Document Contract. Pass 3 — Content: establish meaning, boundaries, claims and the ordered Document Spine in Document Plans and Document Placements. Output: Content Map. Pass 4 — Figures: assign explanatory obligations, encodings and misleading implications to prevent. Output: Figure Contracts. Pass 5 — Assets: identify stable ingredient roles and how to obtain them. Output: Asset Requirements. Pass 6 — Build: build in project-specific Waves and check semantic and visual correctness separately. Output: Figure Set and Production QA. Pass 7 — Compose: compose resolved text and figures and render actual pages. Output: Document Candidate. Pass 8 — Verify: compare the rendered candidate against contracts, route defects to the earliest owner and recheck repairs. Output: Verified Release and QA. A Wave is a bounded portion of a build, not a new global Pass definition. Its ordering follows actual dependencies: a figure can be built when its required ingredients are available, while independent branches need not wait for unrelated work. Missing inputs, contradictory requirements and cycles must be resolved before dependent execution. In this sandbox, routine work proceeds without a human approval gate. Inspectability, explicit outcomes and repair routing still apply. A meaning defect returns to Pass 3; a misleading visual obligation to Pass 4; an ingredient problem to Pass 5; execution to Pass 6; placement or pagination to Pass 7; final release review to Pass 8. Repeating every Pass is unnecessary when the affected scope is known. 5 Core transformation chains The graph has two principal construction paths. Sources support Content Items through Source Support records. Content obligations inform Figure Contracts, whose Figure Requirements refer to Asset Requirements. Requirement Fulfillment binds selected files to those requirements. Completed Figure Outputs and Content Items then converge in Document Placements under a Document Plan. Figure OG-F02 distinguishes these stored relationships from the procedures that produce new outputs. [1,3] A relationship does not itself perform a transformation. “This file fulfills this requirement” is a recorded selection that must be justified by checks. “Build the figure from the selected files” describes work. “Find all slots whose Template equals this template” is a reverse query. These three statements must not be drawn or read as interchangeable executable links. For a concrete Reader traversal, select Document Plans record PLAN-EFX and link Field 6. It resolves TPL-TECH in Templates. Read Templates Field 6 for the Assembly Instructions. Then search Template Slots for rows whose Field 5 Template equals TPL-TECH. The matching HEADER, CONTINUANCE and FIGURE slots are found by that reverse lookup, not by an outgoing slot-list field on the Template. Figure OG-F03 preserves this exact distinction. The instruction is to read the Document Plan, sort its placements by Position ascending, resolve each typed Slot and content or figure link, and emit once in that order without reauthoring source meaning. An executor must implement that behavior explicitly. The Reader supplies the referenced instruction and data; displaying the instruction is not evidence that assembly ran. Before assembly, reject missing targets, duplicate positions within the plan, incompatible slot types and placements with both or neither payload link. Each figure placement must resolve a completed output with the expected caption and alternative text. A dependency edge should identify the consumed revision and the scope that makes a future upstream change relevant. OG-F02. Content and figure paths converge in ordered Document Placements. Solid links denote stored references; labelled procedural transitions describe work performed by an operator or executor. OG-F03. Document Plans Field 6 resolves its Template. Template Field 6 supplies Assembly Instructions. Finding matching Template Slots is a reverse lookup, not a stored outgoing list. 6 Document Spine and presentation The Document Spine is the ordered set of placements belonging to one plan. HEADER emits the section heading from a Content Item. CONTINUANCE emits prose without opening another section. FIGURE emits its linked Figure Output. Each placement carries a positive Position and a Section Anchor; each resolves the corresponding typed Template Slot. Figure OG-F04 demonstrates the expected five-placement sequence. [1,3] Content and figure payloads are exclusive. A CONTENT placement carries a Content Item and no Figure Output. A FIGURE placement carries a Figure Output and no Content Item. The Spine Type refines content behavior into HEADER or CONTINUANCE; it is checked against the slot rather than inferred from the first sentence. Position controls emission order, while a Section Anchor identifies logical membership. Sparse positions allow later prose or figures to be inserted without renumbering existing identities. The paper uses the approved headings at 100 through 1200 and retains the seven figure positions from the composition manifest. New prose occupies separate CONTINUANCE placements between those anchors. Presentation remains a contract. Templates and Slots own placement behavior; Rulesets and Rules constrain allowed behavior; Themes provide visual vocabulary and optional generation guidance. None of these may silently revise a semantic claim. If a figure does not fit, change layout or route the issue to its owner rather than cropping evidence or shrinking labels until they become unreadable. The seven source figures are placed at 6.5-inch width with their original proportions. The two tallest require dedicated pages. Captions and alternative text travel with the selected outputs. Actual page rendering is required because valid records cannot predict every font substitution, line wrap or page break in a Word document. OG-F04. HEADER emits a heading, CONTINUANCE emits prose, and FIGURE emits its resolved output. The illustrative page shows expected emission behavior, not evidence of an automated renderer. 7 Assets and generation An Asset Requirement states the role an ingredient must satisfy. A file is a candidate until selection and checking establish its suitability. Requirement Fulfillment records that binding; Figure Requirements associate ingredient roles with a figure. This keeps an available file from being mistaken for a satisfied obligation merely because its name looks relevant. [1] Retrieval and generation use different parts of a Theme. Include and Exclude constrain the retrieval surface. The generation readback combines the local requirement, applicable Rules, relevant exclusions and Theme Added Details only when Apply to Image Generation is enabled. Theme Include terms are not automatically copied into prompt prose. Applicable Rules retain precedence over optional Theme guidance. [2,3] Figure OG-F05 compares reuse with an unmet requirement and shows paired readbacks with Theme Added Details disabled and enabled. In the paired cases, the Added Details contribution changes while retrieval filters persist. The recorded requests have no generation result files. They demonstrate contract compilation, not a completed image-generation service. Before executing a request, inspect the resolved readback for contradictions, missing qualifications and inappropriate content. If a recurring error originates in a Rule or Theme, revise that owning definition and recompile affected requests. A local exception belongs in the local requirement when it does not generalize. After actual execution, retain the exact input revisions, request text, result file identity and checks. A generated file must still pass the figure obligation and rendering checks. Precise labels, graph topology and field mappings should be produced with tools that preserve exact structure; decorative generative output does not establish technical correctness. OG-F05. Asset selection uses retrieval filters. Generation readback combines local requirements, applicable Rules, exclusions, and enabled Theme Added Details; the request and its execution results remain distinct. 8 Verification and PATCH Verification is divided by what the check can establish. Structural checks inspect required fields and valid types. Link checks resolve references. Semantic checks compare meaning with source and contract. Visual checks inspect the rendered result. Offline checks inspect physical availability. Clone checks inspect retained definitions and cleared project state. A PASS in one category is not a PASS in every category. [1,3] A check records its target revision, instruction, executing run, expected result, observed result and evidence. Record a failure as a failure. Open an Issue describing the defect and its scope; identify the earliest owning input; create the required revision; assess downstream dependencies; repair affected outputs; and run the relevant checks again. Figure OG-F06 illustrates this sequence without claiming that its demonstration is a live repair history. Selective PATCH depends on explicit scope. When a source revision changes, review the edges that consumed that revision. An output affected by the changed label or meaning needs repair or a documented reassessment. An independent branch should retain its identity and evidence. History is preserved by retaining the earlier revisions and earlier check results. File integrity is independently inspectable: resolve the relative path, read the bytes and compare their hash and size with the File Revision. A correct hash establishes byte identity, not semantic quality. Likewise, a link that resolves to the wrong conceptual source is structurally valid but semantically defective. For this paper, Pass 7 performs composition and page inspection. Pass 8 remains the final consistency and release review. Native desktop Excel execution and later website behavior are still separate pending checks. The current candidate must not be labeled a verified release merely because its source figures already passed Pass 6. OG-F06. An upstream revision change initiates scoped impact assessment. Repairs and rechecks update affected outputs while independent branches and historical revisions remain identifiable. 9 Reuse and cumulative improvement Reuse begins with compatibility, provenance and use conditions. A later project can reference a suitable Template, Rule, Theme, component or file revision. It must still check the new use against its own scope. A technically reusable asset is not automatically authorized for every public use. Source use conditions remain part of the decision. [1,2] Asset identity and lifecycle are separate. Reversible placement operations such as scaling, rotation, alignment and opacity normally preserve source identity. A materially new derivative that must be addressed independently receives its own identity and derivation provenance. Creating that derivative does not automatically promote it to a shared pool. The lifecycle distinguishes project-only, candidate, promoted and archived material. Candidate status records an intention for review. Completed promotion requires an actual destination and persistent identity. It is not established by changing a label while leaving the file in temporary project storage. Figure OG-F07 shows three illustrative projects and this promotion boundary. Shared pools should contain useful stable material, not every transient intermediate. Preserve enough provenance to rebuild or assess the promoted object. Archive project-specific evidence where it is needed to explain a result. A later improvement to a shared object should create a new revision and trigger scoped review of consumers rather than silently altering their inputs. The expected benefit is less repeated reconstruction of resolved decisions. That remains an architectural expectation until trials measure it. The three demonstration projects in Figure OG-F07 count as zero completed EFFECTS trials. Patterns, exceptions and proposed pool combinations will be assessed at the actual trial milestones. OG-F07. Projects reuse compatible definitions and assets. Candidate designation does not perform promotion; completed promotion records its destination and persistent identity. Placement transforms preserve source identity. 10 Worked example and self application This paper is the current self-application project OG-PROJECT. Its plan is OG-PLAN. The approved spine contains twelve HEADER placements, and Pass 6 supplies seven Figure Outputs with checked assets, captions and alternative text. Pass 7 adds the prose as distinct CONTINUANCE records and composes a Word candidate from the ordered placements. [1,3] To inspect it, open the worked workbook, locate OG-PROJECT and follow the active Pass Run. Inspect its Run Artifacts for exact input and output revisions. In Document Placements, select OG-PLAN and sort by Position. Resolve a HEADER to its heading Content Item, a CONTINUANCE to its prose, and a FIGURE to its Figure Output. Then resolve the selected physical file and compare it with the rendered paper. The workbook also contains historical EFFECTS material reconstructed from retained artifacts. Those records are useful reference examples but do not constitute a full contemporaneous execution transcript. Their physical files are outside the current OctoGroove asset-byte audit and may require the original EFFECTS package. Keep that boundary visible when teaching offline use. This composition is an implemented local build for the present plan. It establishes a concrete path from registered content and figure placements to this document. It does not establish a general renderer for every possible Template, arbitrary workbook schema or external media service. The reproducible build source and check evidence let later work extend that capability without changing the meaning of what has already been demonstrated. A practical first trial should follow the same inspection route on a new paper, recording every point where instructions are missing, a field is ambiguous, an asset cannot be found or a rendered result diverges from its contract. These observations become the first revision backlog. 11 Sites handoff The website is a later distribution and explanation surface. It should orient a reader to the method, provide the paper and companion workbooks, and explain how to extract and operate the offline package. An optional Airtable mirror graph can demonstrate table links and traversal without becoming a required dependency for the operational workbook. Before publication, prepare a matched starter/worked pair, verify downloadable bytes and relative paths, and state which parts are examples, implemented operations or planned extensions. Each download should identify its version and accompanying instructions. Public source and asset use conditions must be resolved for the actual files being distributed. The site should preserve the same identity vocabulary as the paper and workbook. A Table ID, field address, record link and file download have different destinations; the interface should make those differences visible. Demonstrating a traversal must not imply that the site executes the procedure described by the destination record. No website behavior is claimed by this candidate. The paper and workbook become source material for the Sites stage after paper review. Website navigation, downloads, accessibility and mirror behavior must then be tested in that environment. 12 Trial and revision programme The trial programme evaluates the method through actual EFFECTS paper upgrades. Count completed papers, not figure demonstrations or partial builds. Review at cumulative totals of 1, 3, 8 and 15 papers. The OctoGroove self-application and illustrative reuse projects do not silently consume those EFFECTS milestones. After 1 paper, troubleshoot the complete route and PATCH immediate usability failures. Record missing instructions, ambiguous fields, broken links, unavailable files, rendering defects and any manual step that lacks an explicit owner. Recheck the repaired path before treating the correction as reusable. After 3 papers, compare repeated construction work. Identify compatible definitions and assets that could share a pool, while retaining meaningful differences in scope and use conditions. A proposed combination should name its consumers, identity rules and migration consequences before it replaces separate assets. After 8 papers, inspect outliers. Look for special cases that reveal a missing general rule, and for exceptions that should remain local. Compare the outlier against the existing contract before widening the schema or weakening a check. After all 15 EFFECTS papers, audit the system as a cohesive bundle: identities, revision history, dependencies, reuse, evidence and physical availability. Confirm that each paper can be traced to its inputs and that shared changes have been assessed across consumers. At each milestone retain the evaluated paper set, observed failure patterns, proposed changes, affected dependencies and recheck results. Measures can include unresolved issues, repeat repairs, unavailable files and avoidable reconstruction steps, provided their counting rules are recorded consistently. These are planned evaluations; this candidate reports no completed trial statistics. References and operational addresses [1] OctoGroove operational workbook and schema. Worked-example state at the Pass 6 handoff; 33 Tables and 382 Fields. Governing records include PASS-1 through PASS-8, OG-PLAN, TPL-TECH and the Table and Field Dictionaries. The accompanying Pass 7 workbook adds the prose, document candidate and composition evidence. [2] Conrad, Shane. OCTOGROOVE Graph Assembly Fabric, version 0.1. Supplied earlier architecture paper. Its architectural proposals are interpreted through the current operational definitions; earlier Pass allocation, HEADER behavior and mandatory human-gating language do not override the current sandbox contract. [3] OctoGroove Pass 6 verified asset handoff. Composition_Manifest.json, Pass_7_Handoff.txt and Combined_Verification.json; Waves A–H. Exact figure files, captions, alternative text, source evidence and verification limits are retained in OctoGroove_Pass6_Handoff.zip. Selected field addresses T25 Document Plans – 6 – Link – Template governing this plan. T26 Templates – 6 – Long Text – Assembly Instructions read after resolving the Template. T27 Template Slots – 5 – Link – Template owning the Slot; use for reverse slot discovery. T12 Document Placements – 6 – Integer – Position in the plan’s ascending emission order. T12 Document Placements – 14 – Single Select – Spine Type: HEADER, CONTINUANCE or FIGURE. T12 Document Placements – 15 – Link – Template Slot whose type must match the placement. The workbook is the complete field list. Canonical compact table symbols remain in its dictionaries; Table IDs and readable names are the paper’s glyph-safe fallback.