# Mainline Dense Infographic Prompt Pattern V01 Issue: https://github.com/pinklon/ai-capability-discipline/issues/385 Status: preferred future pattern for repo-aligned dense technical explainer infographic prompts. ## Purpose Mainline Dense Infographic Prompt Pattern V01 defines the reusable prompt and style standard for dense technical explainer infographics produced from this repository. This pattern replaces the older generic dense explainer style when the desired output is a repo-aligned technical architecture infographic. It preserves a white or near-white visual field, black and deep-red title treatment, red gray black hierarchy, strong architecture layout, governance callouts, and restrained color. This artifact is field guidance for prompt generation. It is not package authority, runtime behavior, source approval, provider approval, design-system migration, browser behavior, model configuration, Cloudflare configuration, or production approval. ## When To Use This Pattern Use this pattern when generating prompts for dense technical explainer infographics that need to communicate architecture, governance, lifecycle, risk, hardening, implementation sequencing, or system-design tradeoffs. Use it for: - repo-aligned architecture explainers - source-grounded assistant architecture diagrams - governance and hardening explainers - technical workflow and lifecycle explainers - implementation-path infographics - dense prompt outputs where the reader must inspect structure, sections, evidence, and boundaries Do not use it for: - marketing landing pages - SaaS hero graphics - glossy 3D product illustrations - cartoon explainer posters - neon or cyberpunk visual treatments - colorful gradient-first social graphics - teal, navy, or purple primary-palette enterprise slides ## Visual System The visual system must remain restrained and technical. Required: - White or near-white background. - Black and deep-red title and header treatment. - Red, gray, and black dominant palette. - Deep red for emphasis, warnings, arrows, highlights, governance boundaries, section numbers, and bottom verdict elements. - Gray for dividers, metadata panels, supporting structure, inactive states, low-emphasis content, and architectural scaffolding. - Black for main text, labels, concept names, section headers, and primary diagram labels. - Other colors only sparingly and only when functionally necessary. Rejected: - Teal, navy, or purple as the primary palette. - Colorful gradients. - SaaS marketing look. - Cyberpunk, neon, cartoon, playful, glassmorphism, glossy 3D, or decorative orb styling. - Low-density poster design that removes architecture detail. - Unstructured text-heavy layout without section hierarchy. ## Format Requirements The target format is a dense but readable portrait infographic. Required layout traits: - Portrait orientation. - White or near-white background. - Tight but readable information density. - Numbered sections with red section numbers. - Clear technical architecture composition. - Strong title band in black plus deep red. - Executive takeaway banner near the top. - Diagram-first body with dense annotation. - Structured metadata, governance, and risk callouts. - Bottom verdict banner that states the implementation stance. The prompt should ask for professional editorial precision, not decorative spectacle. ## Required Infographic Anatomy Each prompt should include the following anatomy unless the subject makes one section clearly irrelevant. 1. Executive takeaway banner. A short top banner that states the core conclusion in plain terms. It should use deep red emphasis sparingly and keep the background white or light gray. 2. Core idea flow. A left-to-right or top-to-bottom flow that explains the main conceptual movement. Use red arrows for critical movement, black labels for core concepts, and gray connectors for supporting relationships. 3. Layered architecture section. A stacked or tiered architecture diagram with clear layers, control boundaries, data or evidence movement, and governance checkpoints. Use gray structural bands and deep-red boundaries where decisions, refusals, or risk controls happen. 4. Concept, schema, or code example section. A compact example block that makes the concept concrete. This may be pseudo-schema, JSON-like structure, command shape, prompt snippet, policy clause, or code-like example. Keep it legible and rectangular. 5. Construction or workflow diagram section. A build path, operator workflow, or lifecycle map that shows how the thing is assembled or applied. Use numbered steps and red warning markers only where they signal meaningful gates. 6. Strengths section. A compact list or matrix showing what the pattern, architecture, or workflow does well. Use black text, gray cards, and sparse red check or emphasis markers. 7. Hardening and risk section. A high-visibility risk panel that states failure modes, governance gaps, or controls. Deep red is appropriate here for warnings, boundaries, and must-not-cross statements. 8. Lifecycle or process section. A process lane that shows how the architecture or practice evolves over time. Include review, validation, iteration, owner decision, or retirement points where relevant. 9. Recommended implementation path. A practical sequence for applying the architecture or pattern. Keep it sober, stepwise, and grounded in actual controls rather than hype. 10. Bottom verdict banner. A final visual banner that states the adoption stance, such as "recommended with hardening", "design-only until gate clears", or "use for prompt generation, not runtime authorization." 11. Optional good-instincts vs hardening-needs panel. Include this panel when a concept is directionally useful but needs stronger controls. Use two balanced columns: "Good instincts" and "Hardening needs." Keep both columns factual. ## Governance Callout Rules Governance callouts are part of the visual language. They should be visible, bounded, and specific. Use governance callouts to mark: - owner decision gates - source authority boundaries - validation requirements - evidence requirements - refusal or stop conditions - package authority boundaries - implementation prerequisites - known residual risks Do not use governance callouts to imply approval of tools, vendors, data classes, runtime behavior, production use, or source registry changes. ## Reusable Prompt Skeleton Use this skeleton as the default starting point for future dense technical explainer infographic prompts. ```text Create a dense but readable portrait technical architecture infographic about: [SUBJECT] Primary message: [ONE SENTENCE EXECUTIVE TAKEAWAY] Use the Mainline Dense Infographic Prompt Pattern V01 visual system: - white or near-white background - black and deep-red title/header treatment - red, gray, and black dominant palette - deep red for emphasis, warnings, arrows, highlights, governance boundaries, and numbered section markers - gray for dividers, metadata panels, scaffolding, supporting structure, and low-emphasis content - other colors only sparingly and only when functionally necessary - no teal/navy/purple primary palette - no colorful gradients - no SaaS marketing look - no cyberpunk, neon, cartoon, playful, glassmorphism, or glossy 3D styling Composition: - portrait format - dense but readable - technical architecture layout - numbered sections with red section numbers - compact labels and clear hierarchy - diagram-first body with supporting annotation - white or light gray panels, thin gray dividers, black text, deep-red emphasis Required sections: 1. Executive takeaway banner 2. Core idea flow 3. Layered architecture section 4. Concept/schema/code example section 5. Construction/workflow diagram section 6. Strengths section 7. Hardening/risk section 8. Lifecycle/process section 9. Recommended implementation path 10. Bottom verdict banner 11. Optional good-instincts vs hardening-needs panel if the topic has both promise and control gaps Architecture details to include: [LAYERS, ACTORS, INPUTS, OUTPUTS, EVIDENCE, VALIDATION, GOVERNANCE GATES] Governance boundaries to show: [BOUNDARIES, NON-GOALS, REQUIRED REVIEWS, STOP CONDITIONS] Example block to include: [SCHEMA, CODE-LIKE SHAPE, COMMAND SHAPE, PROMPT SNIPPET, OR POLICY-LIKE EXAMPLE] Risks and hardening needs: [RISKS, CONTROLS, VALIDATION, OWNER DECISIONS] Verdict: [BOTTOM VERDICT TEXT] Make it look like a serious technical architecture brief, not a marketing poster. ``` ## Prompt Generation Procedure 1. Identify the subject and the single executive takeaway. 2. Extract the architecture layers, actors, source boundaries, evidence paths, and control gates. 3. Choose the concrete example block that will make the subject inspectable. 4. Fill the skeleton with source-safe claims and explicit non-goals. 5. Preserve the red gray black visual system. 6. Add hardening and lifecycle sections before adding decorative detail. 7. End with a bottom verdict that makes the adoption posture unambiguous. ## Source And Claim Discipline The infographic prompt must not introduce public product claims, vendor claims, or internal-source claims without the repo-required validation status. When the subject contains uncertain claims, the prompt should label them as: - unverified - owner validation required - candidate only - design-only - future gated - not production approval The prompt must preserve nuance. It should not compress governance boundaries into generic "responsible AI" wording when the source material contains specific controls. ## Quality Gates A prompt conforms to this pattern when: - It explicitly names Mainline Dense Infographic Prompt Pattern V01 or uses its skeleton. - It preserves the white-background red black gray system. - It rejects teal/navy/purple primary styling for this use case. - It rejects colorful gradients and SaaS marketing presentation. - It includes numbered sections with red section numbers. - It includes executive takeaway, core idea flow, layered architecture, example block, workflow diagram, strengths, hardening/risk, lifecycle/process, implementation path, and bottom verdict. - It treats governance callouts as structural content, not decoration. - It avoids implying runtime, source, provider, Cloudflare, browser retrieval, package-authority, or production approval. ## Relationship To Older Dense Explainer Style Older generic dense explainer prompts may still be useful for informal brainstorming, but they are not the preferred repo-aligned pattern for future dense technical explainer infographic prompts. For repo-controlled prompt generation, this v01 pattern is the mainline default because it is more explicit about architecture structure, governance callouts, restrained color, and visual hierarchy. ## Forbidden Scope This artifact does not: - mutate runtime behavior - mutate source registries or source sets - use Cloudflare CLI or API - change provider or model configuration - change browser-side retrieval behavior - change package authority - add autonomous worker behavior - add webhook, scheduled, polling, or external queue behavior - reopen #269 or #271 - apply `codex-automerge` ## Validation Validation is provided by `validation/scripts/check_mainline_dense_infographic_prompt_pattern.py`.