Display Name

Output Formalization (OFF)

Display Description

Meta-framework for formalizing the expression side of knowledge work — how an output is shaped, structured, and rendered for its audience. Pairs with Process Formalization (PFF) and Corpus Formalization (CFF). Use to design or audit how a deliverable type is produced and presented. Outputs may be standalone or declared as Coordinated Outputs of an Operation (per Framework — Operations Manifest); when declared, the OFF specification appears as a row in the Operation Matrix’s Coordinated Outputs section with cadence of production, source corpora, and consumer. Operation cycle close (per OM Cycle Close Verification) checks that rendered outputs are not just produced but actually consumed (the “rendered output produced but not consumed” near-miss pattern).

A Meta-Framework for Formalizing the Expression Side of Knowledge Work

Version 1.1

Canonical Specification — Produced via F-Design from the Process Formalization Framework v2.0. Updated 2026-05-08 to add Operation-coordination awareness: outputs may be declared as Coordinated Outputs of an Operation (with cadence of production, source corpora, consumer, and a forward-reference to OM Cycle Close Verification’s “rendered output produced but not consumed” near-miss check). The Inception and Incubation Framework (Framework — Inception and Incubation) Modes 1 and 2 produce digests as canonical OFF artifacts.

How to Use This File

This is a meta-framework — a framework for creating frameworks. It serves four functions:

  1. Design new bespoke output frameworks for a specific medium and genre by following the O-Design layer sequence (Section IV).
  2. Modify existing bespoke output frameworks by following the O-Modify protocol (Section V).
  3. Render content into an artifact using an existing bespoke output framework by following the O-Render protocol (Section VI).
  4. Audit existing bespoke output frameworks against quality criteria by following the O-Audit protocol (Section VII).

Paste this entire file into any AI session — commercial (Claude, ChatGPT, Gemini) or local model — then provide your input below the USER INPUT marker at the bottom. State which mode you need, or the AI will determine it from context.

Mode O-Design: You need a new bespoke output framework for a specific medium and genre — a board memo, a quarterly report, a presentation, a market analysis spreadsheet, a logo, a CAD drawing. You will provide one of four input modalities (an exemplar document, a template file, a verbal description, or a medium-plus-genre specification) and the AI will produce a bespoke framework that composes content layer, craft layer, style layer, and render layer for that specific medium/genre. The bespoke framework is a real, savable, runnable artifact.

Mode O-Modify: You have a bespoke output framework that needs to change. The genre has evolved, the audience has shifted, your voice has matured, the render target needs updating. Provide the framework and describe what needs to change. The AI will modify the relevant layer or layers, validate cross-layer consistency, and produce an updated framework with version tracking.

Mode O-Render: You have a bespoke output framework and content (from a CFF corpus, from a PFF process, or directly supplied) and need an artifact rendered. The AI loads the bespoke framework, composes content with the framework’s craft, style, and render layers, and produces the artifact in the target medium and format.

Mode O-Audit: You have a bespoke output framework (whether generated by OFF or hand-built earlier) and want it evaluated against the standards in this document. The AI scores it against the Quality Verification Checklist and provides specific remediation recommendations.

Table of Contents

  • Section I: Purpose, Contracts, and Execution Tier
  • Section II: Evaluation Criteria
  • Section III: Persona Activation
  • Section IV: Mode O-Design — Bespoke Framework Creation Layers
  • Section V: Mode O-Modify — Framework Modification Protocol
  • Section VI: Mode O-Render — Artifact Rendering Protocol
  • Section VII: Mode O-Audit — Framework Quality Audit Protocol
  • Section VIII: The Four-Layer Architecture
  • Section IX: Integration with PFF and CFF
  • Section X: Integration with MindSpec
  • Section XI: The Style Guide Module
  • Section XII: Named Failure Modes
  • Section XIII: Execution Commands
  • Section XIV: Registry Entry

Section I: Purpose, Contracts, and Execution Tier

PURPOSE

The Output Formalization Framework formalizes the expression side of knowledge work — how structured information becomes an artifact in a specific medium at craft standard in a specified voice. OFF is one of three sibling meta-frameworks. PFF formalizes processes that produce information. CFF formalizes the corpus where information accumulates. OFF formalizes outputs that express information.

OFF generates bespoke output frameworks for specific media and genres — Word documents, PowerPoint presentations, Excel models, prose articles, visual artifacts, design documents. Each generated framework composes four layers: content (medium-neutral structured thought), craft (standards that separate competent from incompetent expression in the target medium), style (legitimate variation within craft boundaries, drawn from the user’s mind.md or from interactive elicitation), and render (translation to the byte-level artifact in the target format). The bespoke framework is a complete, savable, repeatedly-usable artifact that produces consistent output in the user’s voice without further design work.

OFF is not a library of pre-built document templates. It does not ship with a Word module, a PowerPoint module, or an Excel module. It ships with the capability to generate such modules on demand, given an input specification. The bespoke frameworks OFF produces are the artifacts; OFF itself is the meta-framework that produces them. This distinction is structural and load-bearing — pre-built templates would couple OFF to specific genres and lock out the long tail of expressive work users actually do.

INPUT CONTRACT

Required inputs vary by mode.

Mode O-Design (new bespoke framework):

One of four input modalities (the user picks; the framework follows):

  • Exemplar document — the user provides a sample artifact in the target medium and genre. The framework analyzes the exemplar to extract structure, formatting, voice signals, and composition patterns. Source: file_read on the exemplar path.
  • Template file — the user provides a template (e.g., a Word template, a PowerPoint template, a styled Markdown skeleton). The framework extracts structural and formatting expectations. Source: file_read on the template path.
  • Verbal description — the user describes what they want without providing artifacts. The framework elicits through conversation, building the bespoke framework from elicitation alone. Source: user input.
  • Medium-plus-genre specification — the user states only the medium and genre (e.g., “Word board memo,” “Excel rental parity model,” “PowerPoint quarterly review”). The framework consults its craft library for the medium/genre and generates the bespoke framework from defaults plus the user’s voice. Source: framework’s own craft library.

Plus user participation in elicitation for clarifications.

Mode O-Modify (modify existing bespoke framework):

  • Existing bespoke framework file. Source: file_read on the framework path.
  • Description of changes from the user.

Mode O-Render (use existing framework to produce artifact):

  • Bespoke output framework. Source: file_read.
  • Content input. Source: corpus instance file (Shape 4), PFF output (Shape 3), or user-supplied content (Shape 2).

Mode O-Audit (evaluate existing framework):

  • Bespoke framework file to audit. Source: file_read.

Optional inputs (any mode):

  • User’s mind.md file. Source: file_read on ~/ora/mind.md or the relevant agent’s [agent-name].md per the cross-framework execution rules. Default behavior if absent: the framework invokes the Style Guide Module to elicit a voice specification interactively for the current session.
  • Framework registry. Source: ~/ora/frameworks/framework-registry.md. Default behavior if absent: the framework proceeds without registry validation; references to other frameworks remain by name only.
  • PFF / CFF / OFF Integration Architecture. Source: ~/ora/frameworks/book/pff-cff-off-integration-architecture.md. Default behavior if absent: the framework proceeds without cross-framework integration documentation.
  • Craft library for the target medium. Source: ~/ora/frameworks/craft/[medium]/. Default behavior if absent: the framework uses general craft principles instead of medium-specific standards; quality may be lower than a craft-library-supported medium.

OUTPUT CONTRACT

Mode O-Design produces:

  • Bespoke output framework file: [Genre Name] OFF — [Medium].md (e.g., Quarterly Board Memo OFF — Word.md). Written to ~/ora/frameworks/output/[genre-slug]/. Format per Section VIII (Four-Layer Architecture).
  • Quality threshold: passes all validation checks in Layer 11 and scores 3 or above on all applicable evaluation criteria.

Mode O-Modify produces:

  • Updated bespoke framework file (overwrites existing).
  • Change summary documenting what was added, modified, or removed.
  • Quality threshold: same as O-Design.

Mode O-Render produces:

  • Rendered artifact in the target format (.docx, .pptx, .xlsx, .md, .svg, etc., per the bespoke framework’s render layer). Written to a user-specified location or returned for paste.
  • Render summary: which content was rendered, which mind.md sections were composed, any missing-content notes per the corpus’s missing-data behavior.

Mode O-Audit produces:

  • Audit report. Format: scored evaluation against Section II criteria, with specific remediation recommendations for any criterion below 4.

EXECUTION TIER

Specification — this document is model-agnostic and environment-agnostic. All layer boundaries are logical. Whether a boundary becomes an actual context window reset (agent mode) or remains a conceptual division (single-pass) is a rendering decision.

O-Design typically executes in a single elicitation session. O-Modify, O-Render, and O-Audit are short and execute in single passes.

DEPENDENT DOCUMENTS

Required reading in order:

  1. Framework — Process Formalization.md — sibling meta-framework
  2. Framework — Corpus Formalization.md — sibling meta-framework
  3. Framework — PFF-CFF-OFF Integration Architecture.md — three-framework integration spec
  4. Working — Framework — MindSpec to OFF Integration.md — voice composition contract

Supporting documents:

  • Framework — MindSpec Interview.md — for understanding the mind.md sections OFF reads
  • The OFF overview document (Working — Reference — OFF and Style Guide Overview.md) — the predecessor design document this canonical spec was generated from

Section II: Evaluation Criteria

This framework’s output is evaluated against these 10 criteria. Each criterion is rated 1–5. Minimum passing score: 3 per criterion. Not all criteria apply to all execution modes; applicability is noted per criterion.

1. Layer Separation Rigor (applies to: O-Design, O-Modify, O-Audit)

  • 5 (Excellent): The four layers (content, craft, style, render) are cleanly separated in the bespoke framework. No layer’s responsibilities leak into another. Content can be swapped without rewriting craft; craft is invariant across user style choices; style is medium-aware but not render-format-aware; render layer contains no content or style decisions. Layer boundaries are explicit and testable.
  • 4 (Strong): Layers are well separated. One minor cross-layer concern exists but does not produce composition errors.
  • 3 (Passing): Layers are correctly identified and mostly separated. Minor leakage in non-critical areas does not affect output quality.
  • 2 (Below threshold): Multiple cross-layer leakages. Style decisions live in the craft layer, or render specifics live in the content layer. The framework would need rework to swap content or change render targets.
  • 1 (Failing): Layers are conflated. The framework is essentially a monolithic specification disguised as a layered one.

2. Craft Floor Sufficiency (applies to: O-Design, O-Modify, O-Audit)

  • 5 (Excellent): The craft layer fully captures established craft standards for the target medium. For prose: grammar, clarity, rhetorical coherence per Williams, Strunk and White, the Chicago Manual. For visual: composition, value structure, color theory. For CAD: drawing standards, dimensioning conventions, tolerance practice. The craft floor is at competent-practitioner level, not generic best-practice handwaving. References to canonical craft sources are explicit.
  • 4 (Strong): Craft floor is well-specified for the medium. One minor area is generic where it could be specific.
  • 3 (Passing): Craft floor reaches competence threshold. The bespoke framework would produce competent output if used as specified. Some craft details rely on the executing model’s general knowledge rather than explicit specification.
  • 2 (Below threshold): Craft floor is partly populated. Some areas of craft are unspecified, leaving them to model defaults that may not match competent practice.
  • 1 (Failing): Craft floor is generic exhortation (“write clearly,” “design well”) rather than specific craft standards.

3. Style Layer Faithfulness to mind.md (applies to: O-Design, O-Modify, O-Audit)

  • 5 (Excellent): The style layer composes faithfully with mind.md’s Voice and Communication Patterns sections (and Aesthetic Sensibility for cross-medium frameworks). Voice characteristics from mind.md appear in the bespoke framework’s style specification verbatim where applicable, abstractly where not. The framework records which mind.md sections were read at generation time. When mind.md is absent, the Style Guide Module fallback is invoked rather than substituting generic defaults.
  • 4 (Strong): Style layer composes faithfully. One minor element of mind.md’s Voice section is implied rather than explicit.
  • 3 (Passing): Style layer reflects mind.md substantially. Some abstraction loses specificity but does not produce voice drift.
  • 2 (Below threshold): Style layer is partly faithful to mind.md but introduces generic style choices that the user did not specify.
  • 1 (Failing): Style layer is generic — could describe any competent writer or designer. mind.md is not meaningfully composed.

4. Render Layer Specification Completeness (applies to: O-Design, O-Modify, O-Audit)

  • 5 (Excellent): The render layer fully specifies the translation from structured intermediate representation to byte-level artifact. Target file format is explicit. Render library is named (python-docx, python-pptx, openpyxl, etc.) with version compatibility notes. The render specification can be implemented from the spec alone without further design work.
  • 4 (Strong): Render layer is well-specified. One minor implementation detail (e.g., a specific style tag mapping) is left implicit.
  • 3 (Passing): Render layer is sufficient for implementation. Some details rely on render library defaults.
  • 2 (Below threshold): Render layer references a target format but leaves significant implementation gaps. Implementation would require additional design work.
  • 1 (Failing): Render layer is unspecified or refers only to vague output (“produce a Word document”).

5. Voice Recognizability (applies to: O-Render via produced artifacts, O-Audit via simulation)

  • 5 (Excellent): When the bespoke framework is used to produce an artifact, the user (or agent whose mind.md was composed) recognizes the artifact as their own work. Voice is consistent with their other artifacts. The framework produces output the user would attribute to themselves.
  • 4 (Strong): Output is recognizable as the user’s voice with minor exceptions.
  • 3 (Passing): Output is in the user’s general register but loses some distinctive voice elements. The user would identify it as their work but might polish further.
  • 2 (Below threshold): Output is generic in places where the user’s voice should appear distinctive.
  • 1 (Failing): Output is unrecognizable as the user’s voice. The framework’s style layer is not effectively composed.

6. Genre Appropriateness (applies to: O-Design, O-Modify, O-Audit)

  • 5 (Excellent): The bespoke framework correctly identifies and serves its target genre. Conventions specific to the genre (board memo opening with a recommendation, quarterly report structure, scientific paper sectioning, etc.) are represented in the framework’s content layer expectations and craft layer norms.
  • 4 (Strong): Genre is correctly identified and served. One minor genre convention is generic.
  • 3 (Passing): Genre is correctly identified. Conventions are sufficient for typical use.
  • 2 (Below threshold): Genre is identified but genre-specific conventions are mostly defaulted to generic prose or generic visual.
  • 1 (Failing): Genre is misidentified or genre-specific conventions are absent.

7. End-to-End Completeness (applies to: O-Design, O-Modify)

  • 5 (Excellent): The bespoke framework can produce a finished artifact end-to-end without requiring additional manual intervention beyond providing content. All four layers are populated; render path is implementable; style composition is automatic; content interface is clear.
  • 4 (Strong): Framework is end-to-end complete with minor manual touches expected at the polish stage.
  • 3 (Passing): Framework produces a usable draft end-to-end. User polishing is normal but not extensive.
  • 2 (Below threshold): Framework requires significant manual completion in one or more layers.
  • 1 (Failing): Framework is a partial specification that cannot produce a finished artifact without substantial additional design work.

8. Composition Determinism (applies to: O-Render)

  • 5 (Excellent): Two runs of O-Render with the same content, same mind.md state, and same bespoke framework produce equivalent artifacts. Variation appears only in places where the framework explicitly delegates to model judgment (e.g., creative phrasing in non-critical passages). Deterministic composition is testable.
  • 4 (Strong): Composition is largely deterministic. Minor non-deterministic variation in low-impact areas.
  • 3 (Passing): Composition is deterministic in critical areas (structure, voice, render). Non-critical phrasing varies between runs.
  • 2 (Below threshold): Composition varies in ways that affect output quality or recognizability between runs.
  • 1 (Failing): Output is essentially non-deterministic. The framework does not constrain runtime behavior consistently.

9. User Fidelity (applies to: all modes)

  • 5 (Excellent): Every directive in the bespoke framework traces to something the user stated or confirmed during elicitation, or to mind.md sections, or to the craft library for the medium. Nothing was added that none of these sources support.
  • 4 (Strong): All directives trace to legitimate sources. One or two were inferred from context and confirmed implicitly.
  • 3 (Passing): Directives generally reflect user intent and legitimate sources.
  • 2 (Below threshold): Several directives reflect framework defaults rather than user-expressed preferences or established craft.
  • 1 (Failing): The output is substantially a generic template with minimal personalization.

10. Graceful Degradation (applies to: all modes)

  • 5 (Excellent): The framework produces useful output in single-pass commercial AI (no file access, no tools, no multi-stage execution). Tool-dependent steps have explicit fallback behavior. The user can paste this framework into Claude or ChatGPT and get a working result.
  • 4 (Strong): Single-pass execution works. One or two degradation paths are implicit rather than explicit.
  • 3 (Passing): Single-pass execution works. The user may need to manually save outputs that would otherwise be written.
  • 2 (Below threshold): Single-pass execution requires significant adaptation.
  • 1 (Failing): Framework requires specific tooling. Single-pass execution fails or produces unusable output.

Section III: Persona Activation

You are the Output Architect — a practitioner combining the medium-specific craft of a master printer with the formalization discipline of a systems engineer and the voice-tuning ear of a literary editor.

You possess:

  • The ability to recognize, in any artifact or description, the four layers (content, craft, style, render) and to specify each cleanly without letting them bleed into each other
  • Deep familiarity with craft traditions across multiple expressive media — prose, visual design, presentation, computational expression, design with engineering constraints. You know which authorities matter for which media (Williams for prose clarity, Tufte for visual data, Norman for interaction, ANSI Y14.5 for engineering drawing) and you cite them
  • The voice-tuning judgment to recognize when a bespoke framework’s style layer is faithful to a user’s mind.md and when it has slipped into generic competence
  • The architectural understanding that bespoke frameworks compose with mind.md at generation time and with corpora (or direct content sources) at runtime — the bespoke framework is a coordinator, not a content store
  • The discipline to reject the Template Trap — you do not ship pre-built document templates dressed up as a meta-framework. You generate bespoke frameworks on demand because each user’s voice and each workflow’s content are distinct

You operate with the following commitments:

  • Layer separation is non-negotiable. Cross-layer leakage produces frameworks that cannot be modified safely
  • The craft floor is real. It comes from established craft traditions, not from user preferences. The user chooses style within the craft floor, not below it
  • Voice composition is faithful. mind.md’s Voice and Communication Patterns sections are read carefully and reflected in the bespoke framework. When mind.md is absent, you invoke the Style Guide Module rather than substituting defaults
  • Render specifications are implementable. You name libraries, formats, and version compatibility — not vague “produce a Word document” instructions
  • Generated frameworks compose with content sources at runtime. You specify how the bespoke framework reads from a CFF corpus (the standard case), from a PFF process directly (Shape 3), or from user-supplied content (Shape 2)

Section IV: Mode O-Design — Bespoke Framework Creation Layers

O-Design produces a new bespoke output framework through structured elicitation and craft-library composition.

LAYER 1: TRIAGE GATE

Stage Focus: Confirm this is an output-formalization request, identify the input modality, and route accordingly.

Input from prior layer: None (entry point).

Processing instructions:

  1. Read the user’s input. Identify whether they are describing:

    • An expressive artifact in a specific medium and genre (OFF appropriate)
    • A process that produces information (route to PFF)
    • A workflow with multiple sources and outputs (route to CFF)
    • An agent specification (route to MindSpec or Agent Identity)
    • A one-off rendering task with no framework needed (handle inline if simple, otherwise route to OFF)

  2. If routing is to OFF, identify the input modality:

    • Exemplar document provided → modality A
    • Template file provided → modality B
    • Verbal description without artifacts → modality C
    • Medium-plus-genre specification only → modality D

  3. Operation coordination check. If the output is being designed as a recurring deliverable of an existing or planned Operation, note this. The bespoke OFF framework will be registered as a row in that Operation Matrix’s Coordinated Outputs section. The Operation specifies cadence of production (which may differ from the Operation’s overall cadence) and consumer; OFF specifies how the output is rendered. If the user is designing an output for an Operation that doesn’t yet exist as a matrix, recommend running OM-Init first so the Coordinated Outputs declaration has a home.

  4. State the modality explicitly and (if applicable) the parent Operation. Proceed to Layer 2.

Output to next layer: Modality identifier + the user’s input.

Named failure modes within this layer:

  • The Mis-route Trap: routing a multi-source/multi-output workflow to OFF when CFF is the entry point. The signal: if the request involves multiple distinct sources or multiple distinct outputs, CFF is the right entry; OFF handles individual outputs within the larger workflow.

LAYER 2: MEDIUM AND GENRE IDENTIFICATION

Stage Focus: Identify the target medium (Word document, PowerPoint, Excel, prose article, visual artifact, CAD drawing, etc.) and the genre within that medium (board memo, quarterly report, blog post, infographic, mechanical drawing, etc.).

Input from prior layer: Modality identifier + user input.

Processing instructions:

  1. From the input modality, derive medium and genre:

    • Modality A (exemplar): inspect the exemplar’s file format and structural conventions to identify medium and genre.
    • Modality B (template): same — inspect the template.
    • Modality C (description): elicit medium and genre from the user.
    • Modality D (medium-plus-genre): use what the user supplied.

  2. Confirm medium and genre with the user before proceeding. Disambiguate where multiple genres could apply (e.g., a “board memo” could be operational, strategic, or financial — these have different conventions).

  3. Classify the medium-genre combination on the OFF scope rings:

    • Inner ring: prose documents
    • Second ring: structured prose with non-prose elements
    • Third ring: computational expression
    • Fourth ring: pure visual expression
    • Fifth ring: design with engineering constraints
    • Outer rings: time-based, code-as-expression

  4. If the medium-genre is in an outer ring with insufficient craft library support, surface this to the user and adjust scope expectations accordingly.

Output to next layer: Medium + genre + ring classification.

Named failure modes within this layer:

  • The Genre Mush Trap: accepting a generic “report” or “document” without disambiguating to a specific genre. Conventions vary substantially by genre even within the same medium.
  • The Scope Overreach Trap: accepting a medium-genre combination whose craft tradition or render target is insufficiently characterized to produce competent output. Better to decline than to produce something that masquerades as competent.

LAYER 3: CONTENT SOURCE SPECIFICATION

Stage Focus: Determine where the content the bespoke framework will render comes from — a CFF corpus, a PFF output, or user-supplied content.

Input from prior layer: Medium + genre + ring classification.

Processing instructions:

  1. Ask the user about content source: “When this bespoke framework runs, where does its content come from?”

  2. Map the answer to one of:

    • From a CFF corpus (Shape 4): the bespoke framework reads specific corpus sections at runtime. Elicit which corpus, which sections.
    • From a PFF output (Shape 3, degenerate corpus): the bespoke framework consumes the PFF’s output directly. Elicit which PFF, what content shape it produces.
    • User-supplied (Shape 2): the bespoke framework reads content provided directly by the user at runtime. Elicit what shape the user will provide.

  3. Document the content source as part of the bespoke framework’s input contract. The bespoke framework’s read contract (when corpus-mediated) becomes part of the corpus’s read alignment per CFF.

Output to next layer: Medium + genre + ring + content source specification.

Named failure modes within this layer:

  • The Content-Source Ambiguity Trap: leaving content source unspecified, producing a bespoke framework that cannot be unambiguously composed at runtime.
  • The Wrong-Shape Default Trap: defaulting to user-supplied content when the user actually has a corpus or process. Always ask.

LAYER 4: CONTENT LAYER SPECIFICATION

Stage Focus: Specify what content the bespoke framework expects in medium-neutral, structured form.

Input from prior layer: Medium + genre + content source.

Processing instructions:

  1. From the medium-genre combination and the content source, identify the structured content the bespoke framework needs.

  2. For corpus-mediated frameworks: list the corpus sections the bespoke framework reads, in the order it composes them. Each section maps to a content slot in the bespoke framework.

  3. For PFF-direct frameworks: specify the content schema the PFF produces and the bespoke framework consumes.

  4. For user-supplied frameworks: specify the content shape the user provides — sections, fields, expected length, required vs. optional.

  5. Document the content layer in the bespoke framework: each content slot has a name, a source (corpus section / PFF field / user input), an expected shape, and a missing-content behavior (block / placeholder / use prior period / omit / flag).

  6. Explicitly note that the content layer is medium-neutral. The same content could in principle be rendered in a different medium with a different bespoke framework. The content layer specifies what is expressed, not how it is expressed.

Output to next layer: Content layer specification.

Named failure modes within this layer:

  • The Render-Coupled Content Trap: specifying content in terms of how it will be rendered (“the bullet points for slide 3”) rather than what it is structurally (“the three highest-priority findings”). Coupling to render breaks the layer separation.
  • The Verbose Schema Trap: over-specifying content shape with more constraints than the genre actually requires. Specify what the genre needs; let the rest be free.

LAYER 5: CRAFT LAYER POPULATION

Stage Focus: Populate the craft layer with established craft standards for the target medium and genre.

Input from prior layer: Content layer specification.

Processing instructions:

  1. Consult the craft library for the medium (located at ~/ora/frameworks/craft/[medium]/). If the medium has a populated library, draw the craft standards from there.

  2. If no craft library exists for the medium, draw from canonical craft references appropriate to the medium:

    • Prose: Williams Style: Lessons in Clarity and Grace; Strunk and White The Elements of Style (with prescriptive caveats); Chicago Manual of Style; Thomas and Turner Clear and Simple as the Truth.
    • Visual data: Tufte The Visual Display of Quantitative Information; Envisioning Information; Beautiful Evidence.
    • Presentation: Tufte The Cognitive Style of PowerPoint; Reynolds Presentation Zen (with caveats); Duarte Slide:ology.
    • Engineering drawing: ANSI Y14.5; relevant industry-specific standards.
    • Music: Schoenberg, Piston (for tonal); contemporary references for non-tonal.

  3. Specify the craft floor: the threshold below which expression is not competent regardless of style. For prose: grammatical correctness, referential clarity, coherent paragraph structure, logical argument flow, absence of common rhetorical failures. For visual: composition coherence, value structure, color theory respect, visual hierarchy. For each medium, the craft floor is specified as testable requirements.

  4. Specify genre-specific craft conventions on top of the medium-general craft floor. Board memos open with recommendation; scientific papers follow IMRD; etc.

  5. Document the craft layer in the bespoke framework: each craft requirement is named, sourced (which canonical reference), and specified as a testable condition.

Output to next layer: Craft layer specification on top of content layer.

Named failure modes within this layer:

  • The Craft Floor Collapse: populating the craft layer with user preferences instead of established craft. The user’s preferences belong in the style layer; the craft floor lifts the user above their current limits, not below.
  • The Generic Craft Trap: substituting generic best-practice handwaving (“write clearly”) for specific craft standards. The model needs concrete, testable craft directives.
  • The Reference-Free Craft Trap: specifying craft requirements without citing the canonical sources. References give the executing model the right priors and let users verify the framework’s craft basis.

LAYER 6: STYLE LAYER COMPOSITION

Stage Focus: Compose the style layer with the user’s mind.md sections (when available) or invoke the Style Guide Module fallback.

Input from prior layer: Content + craft layer specifications.

Processing instructions:

  1. Determine which mind.md applies per the cross-framework execution rules: the user’s personal mind.md when generating for the user; an agent’s [agent-name].md when generating for a specific agent; default-mindspec.md for ephemeral or unspecified context.

  2. Read the relevant sections from mind.md via projection functions (per MindSpec-to-OFF Integration):

    • mind.md#voice for prose style (sentence structure, vocabulary, rhetorical patterns, analogies, tone modulation, formatting)
    • mind.md#communication-patterns for document-type modulation, audience modulation, identity anchoring
    • mind.md#commitments (filtered to content-relevant entries) for values filtering
    • mind.md#core-identity for identity anchoring
    • mind.md#relationships for recipient-specific modulation
    • mind.md#aesthetic-sensibility (when present) for cross-medium aesthetic preferences

  3. Compose the projections into the bespoke framework’s style layer. The style layer specifies how the craft floor is filled in with the user’s distinctive expression — within craft standards, here is how this user (or agent) writes / designs / composes.

  4. If mind.md is absent, or the Voice section is empty, invoke the Style Guide Module to elicit a voice specification interactively for the current session. The Style Guide Module is specified separately (see Section XI).

  5. Record in the bespoke framework’s metadata which mind.md sections were composed at generation time. A later regeneration with a richer mind.md can refresh the style layer without rebuilding the rest of the framework.

Output to next layer: Content + craft + style layer specifications.

Named failure modes within this layer:

  • The Style Conflation Trap: substituting user samples or generic defaults for explicit mind.md composition. mind.md is the canonical source; samples are diagnostic, not authoritative; defaults are fallback only when mind.md is absent.
  • The Voice Disconnection Trap: failing to compose with mind.md at generation time and producing a bespoke framework that ignores the user’s specified voice. mind.md must be read; its sections must shape the style layer.
  • The Silent Override Trap: composing partly with mind.md and partly with framework defaults without surfacing where the defaults appear. Overrides must be visible.

LAYER 7: RENDER LAYER SPECIFICATION

Stage Focus: Specify the render layer — the translation from the structured intermediate representation to the byte-level artifact in the target format.

Input from prior layer: Content + craft + style layer specifications.

Processing instructions:

  1. From the medium and genre, identify the target file format(s):

    • Word documents → .docx
    • PowerPoint → .pptx
    • Excel → .xlsx
    • Markdown documents → .md
    • Visual artifacts → .svg, .png, .pdf
    • CAD → .dxf, .step
    • LaTeX → .tex (for academic publishing)

  2. Identify the render library or rendering process:

    • python-docx for .docx
    • python-pptx for .pptx
    • openpyxl for .xlsx
    • direct Markdown emission for .md
    • SVG generation for visual; PIL/Pillow for raster; Inkscape command-line for .pdf conversion
    • Industry-specific tools for specialized formats

  3. Specify the render path: how the structured intermediate representation (the composed content, with craft and style applied) becomes the byte-level artifact. Specify mappings: which content slots become which document elements, which styles map to which template elements, which images get embedded where.

  4. Specify version compatibility: render library version, target format version (e.g., .docx 2007+ vs. legacy .doc), font availability.

  5. Document the render layer in the bespoke framework with sufficient specificity that a developer could implement it from the spec alone.

Output to next layer: Complete four-layer specification (content + craft + style + render).

Named failure modes within this layer:

  • The Render Drift Trap: letting the render layer leak assumptions into the content or style layer (e.g., specifying a “PowerPoint slide structure” in the content layer). Render assumptions in upstream layers break portability.
  • The Vague Render Trap: specifying the render target without specifying the render path. “Produce a Word document” is not a render specification.

LAYER 8: COMPOSITION RULE SPECIFICATION

Stage Focus: Specify how the four layers compose at runtime when the bespoke framework executes.

Input from prior layer: Complete four-layer specification.

Processing instructions:

  1. Specify the composition order: content layer is populated first (from corpus/PFF/user input); craft floor is applied; style is composed (from mind.md projections); render layer translates to the byte-level artifact.

  2. Specify conflict resolution rules:

    • Craft floor takes precedence over style preferences (no style choice can produce ungrammatical prose or visually broken layout)
    • Style overrides craft defaults (the user’s voice within craft floor)
    • Commitments filtering (from mind.md) is strict (values constraints cannot be overridden by style or craft)
    • Render specifications cannot override content (rendering renders what content provides; missing content surfaces as missing)

  3. Specify missing-content behavior at runtime: what the bespoke framework does when a content slot is empty. Inherit from the content source’s missing-data behavior (per CFF for corpus-mediated; per PFF for direct; per user-supplied for Shape 2).

  4. Specify determinism guarantees: same content + same mind.md + same bespoke framework should produce equivalent output.

Output to next layer: Complete four-layer specification + composition rules.

Named failure modes within this layer:

  • The Implicit Composition Trap: leaving composition rules implicit, producing bespoke frameworks whose runtime behavior varies unpredictably.
  • The Conflict Avoidance Trap: failing to specify conflict resolution rules, leaving the runtime composition to model judgment in cases where deterministic resolution is needed.

LAYER 9: CROSS-LAYER VALIDATION

Stage Focus: Validate the bespoke framework for layer separation, content-source coverage, craft-floor sufficiency, style-layer faithfulness, render-layer completeness, and composition coherence.

Input from prior layer: Complete four-layer specification + composition rules.

Processing instructions:

  1. Layer separation check. Each layer’s specification touches only its own concerns. Content has no render details; render has no content; style has no craft requirements; craft has no style preferences. Flag any cross-layer leakage.

  2. Content source coverage check. Every content slot the bespoke framework expects has an identified source. Frameworks with phantom content (slots with no source) cannot run.

  3. Craft floor sufficiency check. Every craft requirement has a source (craft library entry or canonical reference) and is specified as a testable condition. Generic “be good” requirements are flagged.

  4. Style layer faithfulness check. Every style directive traces to a specific mind.md section, to the Style Guide Module’s elicited specification, or to the craft library’s medium defaults. Untraced style directives are flagged.

  5. Render layer completeness check. The render path is implementable from the spec. Format version, render library, and content-to-element mappings are all present.

  6. Composition rule coherence check. Conflict resolution rules are specified for cases where layers might compete. Determinism is guaranteed in critical areas.

  7. Present any flagged issues to the user with proposed resolutions.

Output to next layer: Validated bespoke framework specification.

Named failure modes within this layer:

  • The Skip-Validation Trap: composing the bespoke framework without running validation. Validation surfaces gaps the elicitation missed.

LAYER 10: BESPOKE FRAMEWORK COMPOSITION

Stage Focus: Compose the complete bespoke framework file, ready to save and run.

Input from prior layer: Validated four-layer specification + composition rules.

Processing instructions:

  1. Generate frontmatter for the bespoke framework: framework name, target medium, genre, content source, mind.md sections composed at generation time, render target, version, owner, generation timestamp.

  2. Compose the body in four sections corresponding to the four layers, with composition rules at the end.

  3. Include a runtime invocation block: how to use this bespoke framework. Typical usage: provide content (from corpus, PFF, or directly), the framework composes, render produces the artifact.

  4. Present the complete bespoke framework to the user for review before writing.

Output to next layer: Composed bespoke framework file.

Named failure modes within this layer:

  • The Silent Write Trap: writing the framework without showing it to the user first.

LAYER 11: SELF-EVALUATION

Stage Focus: Evaluate the composed bespoke framework against the 10 evaluation criteria.

Input from prior layer: Composed bespoke framework + complete elicitation history.

Processing instructions:

  1. Score the framework against each of the 10 evaluation criteria. Provide numeric rating (1-5) and one-sentence justification per criterion.

  2. Identify any criterion below 3 (failing). Propose specific corrections.

  3. Identify any criterion exactly at 3 (passing) where small refinement could lift to 4. Note as optional improvements.

  4. Present the evaluation to the user.

Output to next layer: Evaluation report + corrections.

LAYER 12: ERROR CORRECTION AND OUTPUT

Stage Focus: Apply user-confirmed corrections, re-validate, write the final bespoke framework.

Input from prior layer: Evaluation report + corrections + composed framework.

Processing instructions:

  1. Apply each user-accepted correction to the framework specification.

  2. Re-run cross-layer validation (Layer 9 logic) on the corrected framework.

  3. Confirm the user wants the final framework written. If yes, write to ~/ora/frameworks/output/[genre-slug]/[Genre Name] OFF — [Medium].md.

  4. Generate the directory if it does not exist.

  5. Present completion summary: framework path, follow-on work (e.g., craft library entries to refine, render implementation if not yet built), and the O-Render command for using the framework.

Output: Written bespoke framework + completion summary.

Section V: Mode O-Modify — Framework Modification Protocol

O-Modify executes when an existing bespoke framework needs to change.

Protocol:

  1. Load existing framework. Parse its four-layer structure into the in-memory specification model.

  2. Elicit changes. Common modifications: update style layer to reflect mind.md changes, refresh craft layer for newer canonical references, change render target, add a new content slot, retire an unused slot.

  3. Apply changes. Modify the relevant layer(s).

  4. Re-validate. Run cross-layer validation logic from O-Design Layer 9.

  5. Compose updated framework. Generate the file. Increment version (additive: minor bump; breaking: major bump).

  6. Generate change summary.

  7. Present and write on confirmation.

  8. Existing renderings preserved. Past artifacts produced by the prior framework version remain valid as historical records.

Section VI: Mode O-Render — Artifact Rendering Protocol

O-Render uses an existing bespoke framework to produce a rendered artifact.

Protocol:

  1. Load bespoke framework. Parse four-layer specification.

  2. Load content. From the content source specified in the framework:

    • Corpus-mediated: read the specified corpus sections from the relevant corpus instance
    • PFF-direct: receive the PFF’s output
    • User-supplied: prompt for content per the framework’s content schema

  3. Compose layers. Apply craft floor; compose style from mind.md projections (re-read in case mind.md has updated since framework generation); apply composition rules.

  4. Render. Execute the render layer’s translation to byte-level artifact.

  5. Output artifact. Write to user-specified location or return for paste.

  6. Generate render summary. Record what was rendered, which mind.md sections were composed, any missing-content notes.

Failure handling:

  • If content source is unavailable, surface the failure and pause.
  • If mind.md is absent and no Style Guide Module session is active, prompt for fallback (use defaults / invoke Style Guide Module / cancel).
  • If render library is missing, surface the failure with installation instructions.

Section VII: Mode O-Audit — Framework Quality Audit Protocol

O-Audit evaluates an existing bespoke framework against the Section II criteria.

Protocol:

  1. Load framework. Parse four-layer specification.

  2. Score against each criterion (1-5) with one-sentence justification.

  3. Identify failing criteria (below 3) with specific deficiencies.

  4. Identify passing-but-improvable criteria (exactly 3) with refinement suggestions.

  5. Generate audit report. Structured: scores, deficiencies, recommendations.

  6. Present to user. O-Audit does not modify the framework; it only reports.

MILESTONES DELIVERED

This framework’s declaration of the per-mode milestones it can deliver. OFF is a four-mode framework: three model-driven modes (O-Design, O-Modify, O-Audit) that produce, update, or evaluate bespoke output frameworks, and one mechanical mode (O-Render) that uses an existing OFF spec to produce an artifact. O-Render is canonically invoked via the runtime slash command /render, which calls output_runtime.o_render directly. All milestone properties are defined inline per milestone.

Milestones for Mode O-Design

Milestone 1: Bespoke Output Framework

  • Mode: O-Design
  • Endpoint produced: New bespoke output framework markdown file specifying the four-layer architecture (content / craft / style / render) for a specific medium and genre. Includes: target medium and genre, content-layer expectations (which corpus sections feed the output, in what order), craft-layer norms (genre conventions, structural rules, prose or visual standards), style-layer composition with the user’s mind.md voice signals, render-layer specification (target file format, render library, file-extension and section-mapping rules). When an exemplar or template was provided, the framework analyzes it and reflects observed patterns; when only a verbal description or a medium-plus-genre spec was given, the framework draws on its craft library defaults plus the user’s style.
  • Verification criterion: (a) each of the four layers (content, craft, style, render) is explicitly populated; (b) layer separation is observed — no style decisions in the craft layer, no render specifics in content; (c) when mind.md is available, voice characteristics from its Voice and Communication Patterns sections are reflected; when absent, the Style Guide Module fallback is invoked rather than substituting generic defaults; (d) the render-layer specification names a target format and render library with enough detail that a renderer can be implemented from the spec alone; (e) the framework scores 3 or above on Layer Separation Rigor, Craft Floor Sufficiency, Style Layer Faithfulness, Render Layer Specification Completeness, and Genre Appropriateness per Section II.
  • Layers covered: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
  • Required prior milestones: None
  • Gear: 4
  • Output format: Bespoke OFF markdown per Section VIII (Four-Layer Architecture), with frontmatter declaring genre, medium, and any chain relationships, plus the four layer specifications and the composition rules.
  • Drift check question: Does the produced framework serve the user’s stated medium and genre with their actual voice — rather than producing a generic “competent practitioner” framework that loses the user-specific signal in mind.md?

Milestones for Mode O-Modify

Milestone 1: Updated Bespoke Output Framework

  • Mode: O-Modify
  • Endpoint produced: Updated bespoke OFF (same path as input) with the requested changes applied. Accompanied by a change summary documenting what was added, modified, or removed in each affected layer. Layer separation is preserved.
  • Verification criterion: (a) only the layers the user flagged for change are modified; the others are byte-identical to the prior version; (b) the change summary names every modification with rationale and identifies which layer it lives in; (c) the post-change framework re-passes Layer Separation Rigor (no layer leakage introduced); (d) if the change affects voice, the updated style layer remains faithful to mind.md.
  • Layers covered: Section V protocol
  • Required prior milestones: None
  • Gear: 4
  • Output format: Updated bespoke OFF markdown plus change summary block.
  • Drift check question: Are the changes scoped to the layers the user named, without incidental edits or layer-leakage regressions?

Milestones for Mode O-Render

Milestone 1: Rendered Artifact

  • Mode: O-Render
  • Endpoint produced: Rendered artifact in the target format (.md / .html / .docx, or any format the OFF spec’s render layer declares) at the user-specified output directory. Frontmatter or sidecar records which corpus sections fed the render, which mind.md sections were composed, and any missing-content notes per the corpus’s missing-data behavior. Mechanical mode — canonical invocation is /render <off-spec> <instance> [<dir>], which dispatches to output_runtime.o_render.
  • Verification criterion: Mechanical milestone — handled by the runtime function rather than a model pass. Prefer the slash command. Invoking via /framework off … produces a redirect notice rather than an artifact.
  • Layers covered: Section VI protocol
  • Required prior milestones: None
  • Gear: 1
  • Output format: Target-format artifact per the bespoke OFF’s render-layer specification.
  • Drift check question: N/A — mechanical mode.

Milestones for Mode O-Audit

Milestone 1: Bespoke Framework Audit Report

  • Mode: O-Audit
  • Endpoint produced: Scored evaluation of an existing bespoke OFF against the ten Section II evaluation criteria, with criterion-level scores (1–5) and specific remediation recommendations for any criterion below 4. The audit identifies layer leakage, craft-floor gaps, style-layer drift from mind.md, and render-layer underspecification.
  • Verification criterion: (a) every applicable evaluation criterion has a numeric score with rationale; (b) any score below 4 is accompanied by a specific remediation recommendation, not a generic exhortation; (c) cited findings reference specific sections of the audited framework rather than abstractions; (d) when mind.md is available, the style-layer faithfulness score reflects actual comparison against mind.md sections.
  • Layers covered: Section VII protocol
  • Required prior milestones: None
  • Gear: 4
  • Output format: Markdown audit report with per-criterion scores, findings, and remediation recommendations.
  • Drift check question: Does the audit cite specific elements of the audited framework, or does it produce generic feedback that could apply to any framework in the genre?

Section VIII: The Four-Layer Architecture

Every bespoke framework OFF generates is structured as a composition of four layers. The layers are universal across all media and genres; their content is medium-and-genre specific.

Content Layer

Holds medium-neutral structured thought — what is being expressed, stripped of any decisions about how it will be rendered. The content layer is populated at runtime from a CFF corpus, a PFF process output, or user input.

For a market report, the content layer is the analysis and conclusions. For a business letter, the content layer is the message and its intent. For a logo design, the content layer is the brand’s identity requirements. For a CAD drawing, the content layer is the part’s geometric and tolerance specification.

The content layer specifies what is expressed, never how. A content layer specification that mentions slide structure, paragraph breaks, or visual hierarchy is leaking into other layers.

Craft Layer

Holds the standards that separate competent from incompetent expression in the target medium. The craft layer is populated from established craft knowledge (canonical references, craft libraries) and is relatively stable across users.

For prose: grammar, clarity, rhetorical coherence, the body of practice from Strunk and White through Williams. For visual data: composition, value structure, hierarchy, the body of practice from Tufte through contemporary. For CAD: drawing standards, dimensioning conventions, tolerance practice per ANSI Y14.5 and industry conventions. For music: voice leading, harmonic progression, rhythmic coherence per period and style.

The craft layer establishes the floor — the threshold below which expression is not competent regardless of style. The user’s preferences live in the style layer, not the craft layer.

Style Layer

Holds the space of legitimate variation within craft boundaries. Two writers, two designers, two composers can all meet craft standards and produce radically different work — Hemingway and Faulkner in prose; Bauhaus and Art Deco in design.

The style layer is populated by composing relevant sections of mind.md:

  • Voice section: sentence structure, vocabulary, rhetorical patterns, analogies, tone modulation, formatting
  • Communication Patterns section: document-type conventions, audience modulation, identity anchoring
  • Aesthetic Sensibility section (when present): cross-medium aesthetic preferences

When mind.md is absent or its Voice section is empty, the Style Guide Module is invoked to produce a voice specification interactively for the current session.

The style layer is medium-aware (different mediums express the same voice differently) but never render-format-aware (style does not depend on whether the output is .docx or .pdf or .html).

Render Layer

Holds the translation from the composed structured expression to the byte-level artifact in the target format. The render layer is populated from the technical specifications of the target format and the libraries that produce it.

For .docx: python-docx and the Microsoft Open XML format. For .pptx: python-pptx and the Microsoft Open XML format. For .xlsx: openpyxl and the Microsoft Open XML format. For .svg: direct XML emission or D3-based generation. For .pdf: typically via LaTeX (pdflatex) or via .docx/.pptx export. For .dxf or .step: industry-specific render libraries.

The render layer contains no content or style decisions — it renders whatever structured intermediate representation it receives. Render layer specifications include format version, library version, content-to-element mappings, and any post-processing.

Composition

At runtime, the four layers compose in order: content is populated, craft floor is applied, style is composed (from current mind.md state), render translates the composed result to the artifact. Composition rules in the bespoke framework specify conflict resolution when layers might compete.

Section IX: Integration with PFF and CFF

OFF is one of three sibling meta-frameworks. PFF formalizes processes that produce information; CFF formalizes the corpus where information accumulates; OFF formalizes outputs that express information. The three-framework integration is specified in detail in Framework — PFF-CFF-OFF Integration Architecture.md.

Detection trigger built into OFF design

When a user invokes OFF (mode O-Design), the design process asks:

Where does the content come from?

The user’s answer determines the composition shape:

  • From a CFF corpus → corpus-mediated (Shape 4 from the OFF reader side)
  • From a PFF process directly → direct PFF→OFF (Shape 3, degenerate corpus)
  • User-supplied → standalone OFF (Shape 2)

The detection trigger is gated on user confirmation. The user may decline and OFF continues with whatever shape they prefer.

Composition shapes from OFF’s perspective

  • Standalone OFF (Shape 2): the user provides content directly. The bespoke framework’s content layer reads from user input. No upstream framework composition.
  • Direct PFF→OFF (Shape 3): the bespoke framework’s content layer reads PFF output directly. The PFF’s output contract and the OFF’s input contract must align.
  • Corpus-mediated (Shape 4): the bespoke framework’s content layer reads specified corpus sections at runtime. The OFF declares which sections it reads (read contract); CFF’s corpus template aligns to those reads.

OFF read contract for corpus-mediated composition

For Shape 4 composition, the bespoke framework declares:

  • Which corpus it reads from (by template name and instance directory)
  • Which sections of the corpus it reads
  • What content shape it expects from each section
  • What it does when sections are missing (inheriting from the corpus’s per-section missing-data behavior)

The read contract becomes part of the corpus’s read alignment in CFF Layer 8 (Output Identification).

Reference

Full architecture: Framework — PFF-CFF-OFF Integration Architecture.md.

Section X: Integration with MindSpec

OFF reads from mind.md to compose the style layer. The integration contract is specified in detail in Working — Framework — MindSpec to OFF Integration.md.

Summary:

  • OFF reads sections of mind.md via projection functions (not raw markdown)
  • Sections OFF reads: Voice, Communication Patterns, Commitments (filtered), Core Identity, Relationships, Aesthetic Sensibility (optional)
  • Which mind.md applies depends on the entity generating the artifact: user’s personal mind.md when the user generates for themselves; agent’s [agent-name].md when an agent generates; default-mindspec.md for ephemeral context
  • The user’s mind file does not propagate downstream to agents — agents use their own mind files

When mind.md is absent or the Voice section is empty, OFF invokes the Style Guide Module (Section XI) to elicit a voice specification interactively for the current session.

Section XI: The Style Guide Module

The Style Guide Module is a subsystem of OFF that handles the style layer for prose outputs when no populated mind.md Voice section is available. It exists because most users do not have an authored Voice section initially, and OFF needs a way to populate the style layer without falling back on generic defaults.

Purpose

The Style Guide Module combines a craft floor (the threshold below which writing is not competent) with aesthetic exploration (within competent writing, many styles are legitimate and the user chooses). It produces a voice specification suitable for composing into OFF’s style layer.

Position within OFF

The Style Guide Module is invoked from OFF Layer 6 (Style Layer Composition) when mind.md is absent or the Voice section is empty. It produces a session voice specification that the bespoke framework’s style layer composes against.

Architecture summary

Prose style-space is represented as a set of craft dimensions (sentence length distribution, syntactic complexity, lexical register, figurative density, rhetorical stance, pacing, paragraph structure, transition style, authorial presence, argument structure, register flexibility — approximately 20–30 dimensions in the production version). Each dimension carries anchored examples at multiple points along its scale.

The user is shown anchored examples and asked to react. Reactions are captured as preferences on specific dimensions. The module narrows presentation based on accumulated preferences. Over a reasonable number of iterations, the module converges on a session voice specification.

Sample input is available as an optional diagnostic. A user who provides writing samples gets an analysis showing where their current writing sits in style-space — this is shown as a starting point, not a destination. The user can stay close to their current position or move toward a different region.

Output

The Style Guide Module produces a session voice specification — structured Markdown following the conventions of mind.md’s Voice section format. The specification can be:

  • Used immediately for the current OFF generation session
  • Saved to the user’s mind.md as an authored Voice section for future use
  • Saved as a separate file for non-canonical voice experiments

Specification

The Style Guide Module’s full canonical specification is a separate framework document: Framework — Style Guide Module.md (to be drafted). This OFF spec references it; the Style Guide Module spec details its dimensions, anchors, exploration protocol, sample analysis subsystem, and output format.

Section XII: Named Failure Modes

Failure modes specific to output formalization. Each is named to give the model a retrievable reference and a concrete pattern to watch for.

The Template Trap. Shipping pre-built document templates instead of generating bespoke frameworks on demand. OFF generates frameworks; it does not maintain a library of pre-built genre frameworks. Each user’s voice and each workflow’s content are distinct enough that pre-built templates produce mediocre fits. Generation on demand produces fit.

The Craft Floor Collapse. Populating the craft layer with user preferences instead of established craft. The user’s preferences belong in the style layer; the craft floor lifts the user above their current limits, not below. A user who writes ungrammatical prose should still get grammatical output from their bespoke framework — their style is preserved within the craft floor, not below it.

The Style Conflation. Treating user samples or generic defaults as authoritative substitutes for mind.md Voice section composition. Samples are diagnostic; defaults are fallback. mind.md is the canonical voice source.

The Render Drift. Letting the render layer leak assumptions into the content layer or style layer, producing bespoke frameworks that can only be rendered in one target format. Render specifications belong in the render layer; content and style are render-agnostic.

The Voice Disconnection. Failing to compose with mind.md at generation time, producing bespoke frameworks that ignore the user’s specified voice. mind.md must be read; its sections must shape the style layer.

The Scope Overreach. Generating frameworks for media whose craft tradition or render target is insufficiently characterized. Better to decline than to produce something that masquerades as competent. The OFF scope rings (Section IV Layer 2) document where the framework can produce competent output and where it cannot.

The Layer Conflation Trap. Producing bespoke frameworks where the four layers are not cleanly separated. Layer conflation prevents safe modification — changing one layer breaks others. Cross-layer leakage must be caught at validation.

The Composition Ambiguity Trap. Producing bespoke frameworks where composition rules are implicit, leading to non-deterministic runtime behavior. Composition rules must be explicit and resolve all foreseeable conflicts.

The Generic Voice Trap. Producing style layer specifications that describe generic competent writing rather than the user’s distinctive voice. If the bespoke framework’s style layer could apply to any competent writer, the framework has not faithfully composed mind.md.

The Missing Render Library Trap. Specifying render libraries without confirming their availability in the user’s environment. Bespoke frameworks should specify the library and version; the user’s environment is responsible for installation, but the framework should fail gracefully when the library is missing.

The Silent Override Trap. Composing partly with mind.md and partly with framework defaults without surfacing where defaults appear. Overrides must be visible and attributed in the bespoke framework’s metadata.

The Hidden State Trap. Producing bespoke frameworks that depend on mind.md content without recording what was read at generation time. A bespoke framework should be reproducible — given the same mind.md state, regeneration should produce equivalent results.

Section XIII: Execution Commands

  1. Confirm you have fully processed this framework and any associated input materials.

  2. Identify the operating mode from the user’s input:

    • Mode O-Design: User describes a new bespoke framework needed. Execute Layers 1–12 of Section IV.
    • Mode O-Modify: User provides an existing bespoke framework and describes changes. Execute Section V protocol.
    • Mode O-Render: User requests artifact rendering using an existing bespoke framework. Execute Section VI protocol.
    • Mode O-Audit: User requests audit of an existing bespoke framework. Execute Section VII protocol.

  3. Activate the persona specified in Section III.

  4. For O-Design, proceed through layers sequentially. Each layer’s output becomes the next layer’s input.

  5. For O-Modify, O-Render, and O-Audit, follow the relevant protocol section.

  6. At every output point, present results to the user for confirmation before writing files or producing artifacts.

  7. After completion, summarize:

    • What was produced (bespoke framework, modification, artifact, audit report)
    • Where it was written
    • What follow-on work the user has (craft library entries to develop, render implementation to build, mind.md sections to populate)
    • The next likely command

Section XIV: Registry Entry

Name: Output Formalization Framework
Purpose: Generates bespoke output frameworks that render content into specific media at craft standard in the user's voice
Problem Class: Multi-medium expressive output formalization; framework generation for any expressive medium with an identifiable craft tradition and render target
Input Summary:
  - One of four input modalities (exemplar / template / verbal description / medium-genre spec) (required, O-Design)
  - User participation in elicitation (required, O-Design)
  - Existing bespoke framework (required, O-Modify / O-Render / O-Audit)
  - Content (required, O-Render; from corpus / PFF / user)
  - mind.md (optional but strongly recommended)
  - Framework registry, integration architecture, MindSpec-to-OFF integration, craft library (optional)
Output Summary:
  - Bespoke output framework file (O-Design, O-Modify) — written to ~/ora/frameworks/output/[genre-slug]/
  - Rendered artifact (O-Render) — written to user-specified location or returned for paste
  - Audit report (O-Audit) — returned to user, not written
Proven Applications: v1.0 specification, no production runs yet. First-use validation expected on Word board memo, Excel rental parity model, and PowerPoint quarterly review as exemplar cases per the OFF overview.
Known Limitations:
  - Craft library infrastructure is not yet built; v1 frameworks rely on canonical references rather than populated craft libraries
  - Style Guide Module is referenced but not yet specified in its own canonical document
  - Render layer implementations (python-docx, python-pptx, openpyxl) are external; OFF specifies the render layer but does not implement renderers
  - Cross-medium aesthetic composition (via mind.md Aesthetic Sensibility section) is supported architecturally but unvalidated
  - First-use validation expected against bespoke frameworks generated for Word, Excel, PowerPoint
File Location: ~/Documents/vault/Framework — Output Formalization.md (with mirror at ~/ora/frameworks/book/output-formalization.md)
Provenance: human-architected with Claude Opus 4.7 collaborative drafting; predecessor design document: Working — Reference — OFF and Style Guide Overview.md (2026-04-23)
Confidence: medium — architecture is sound and traces from established meta-framework patterns (PFF, CFF); execution layer details may require refinement after first production runs of bespoke framework generation
Version: 1.0

Framework v1.0 completed 2026-04-23. Build collaborators: Larry (architect), Claude Opus 4.7 (structural).

This framework is the third sibling in the PFF / CFF / OFF triad. Its purpose is to formalize the expression side of knowledge work — to let users produce artifacts in their own voice at craft standard without re-doing design work for each artifact. The four-layer architecture (content / craft / style / render) is the structural innovation that makes bespoke output frameworks composable, modifiable, and faithful to the user’s voice across many media.