Verified Infographic Generator

Verified Infographic Generator

Version: 1.0

Overview

This skill produces high-quality infographic posters where fact-verification is done by Claude in text and the text-to-image engine is invoked only in the final rendering step, after all content has been locked and approved.

It exists because one-shot text-to-image generation of fact-based infographics has a very high fabrication rate. In one observed session generating a poster about biophilic design, 8 of 10 numeric claims (80%) were unsupported by the cited sources, and 2 of 5 citations were fictional or misattributed. Once incorrect text is baked into pixels, it cannot be corrected without regenerating, and readers have no way to audit where the numbers came from.

Core Principles

1. Separate facts from pixels. Never let the image model choose which numbers to display.
2. Evidence before composition. No visual layout work begins until every claim has a verified source.
3. Bake nothing unverified. Any unverified claim blocks the pipeline, is downgraded to qualitative language, or is replaced.
4. Preserve an audit trail. Every number and citation in the final image must be traceable to a specific source URL and quoted passage in a sidecar file.
5. Break symmetry bias. Two-column "versus" layouts must explicitly allow asymmetric content — missing data on one side is a first-class output, not something to fabricate around.

When to Use

Use this skill when the user asks for:

• A poster, infographic, or data visualization containing numeric claims
• A comparison ("X vs. Y") graphic where percentages or study results appear
• An evidence-based summary poster citing research, studies, or data
• An Earth Day / science communication / educational poster with statistics

Do NOT use this skill for:

• Purely decorative images with no factual claims
• Diagrams where the user supplies pre-verified data and just needs a layout rendered
• Artistic posters, logos, or illustrations without numeric content
• Static diagrams of known objects (use interactive-infographic-overlay for annotated scientific illustrations)

Prerequisites

• Web search access (for Phase 2 source discovery)
• A text-to-image model available in the final step (OpenAI Images 2.0, Gemini, DALL·E, etc.)
• A project output directory (default: docs/posters/) where the poster, verification report, and sidecar source file will be saved together

Workflow

The skill runs in 8 phases. Phases 1–6 are executed by Claude. Phase 7 is the one image-model call. Phase 8 is a Claude audit of the final render.

Phase 1: Intake & Claim Planning

Gather from the user:

• Topic of the poster
• Intended audience (grade 9-12, general public, policy maker, etc.)
• Format (landscape/portrait, dimensions, style preference)
• Comparison structure if any (A vs. B, single-subject, timeline, etc.)
• Known references the user wants to incorporate

Produce a Claim Plan — a structured list of 5–10 factual claims the poster must make. For each claim, record:

• Subject (what it's about)
• Metric type (percentage, count, range, qualitative descriptor)
• Polarity (positive outcome, negative outcome, neutral)
• Desired prominence (hero number, supporting stat, footnote)

Flag any planned comparison that invites symmetry bias. Tell the user explicitly: "The 'versus' side may end up with less data than the main side. We will not invent numbers to balance it."

Save the claim plan to docs/posters/<slug>/01-claim-plan.yaml using the template in references/claim-plan-template.yaml.

Phase 2: Source Discovery

For each claim in the plan:

1. Run at least two independent web searches with different query phrasings.
2. Collect candidate sources. For each, record: title, authors, year, publisher or journal, URL, and a quoted sentence that directly supports the claim.
3. Prefer, in order:
   • Peer-reviewed journal articles
   • Systematic reviews and meta-analyses
   • Government reports (EPA, NOAA, USGS, UK GBC, WHO, etc.)
   • Named institutional studies with authors
4. Reject:
   • Blog posts citing unnamed "studies"
   • Marketing pages and vendor whitepapers
   • Wikipedia as a sole source (can be a pointer to primary sources)
   • Statistics without a traceable primary paper
   • Social media posts as primary sources

Phase 3: Verification & Classification

Classify each claim into one of four buckets:

For every VERIFIED and DIRECTIONAL claim, store a citation record:

yamlCopy code
- claim_id: wellbeing_increase
  value: "+15%"
  source: "Human Spaces / Interface (2015)"
  authors: "Cooper, C. et al."
  year: 2015
  url: "https://..."
  quote: "employees who work in environments with natural elements report a 15% higher level of well-being"
  classification: VERIFIED

Save the full Verification Report to docs/posters/<slug>/02-verification-report.md using the template in references/verification-report-template.md.

Abort condition: If more than 20% of planned claims are REJECTED, stop the pipeline and tell the user the topic may not support the original framing. Offer to reshape the poster around the VERIFIED claims that remain.

Phase 4: User Checkpoint (MANDATORY)

Present the Verification Report to the user. Show:

• Every original claim and its verdict
• Which claims survived with exact numbers
• Which were softened to qualitative language
• Which were dropped entirely
• Any fabrication risks detected (e.g., a "vs." side with thin evidence)

Wait for explicit user approval before proceeding. The user may:

• Approve the final claim set as-is
• Request additional sources for a specific claim
• Reshape the poster (remove comparison, change topic, widen scope)
• Accept qualitative language in place of a missing percentage

Do not proceed to layout or rendering without this approval. This is the single most important safety checkpoint in the pipeline.

Phase 5: Layout Specification

Draft a structured layout spec in YAML (use references/layout-spec-template.yaml). Every text element must reference a source_id from the verification report, or be marked as a non-factual design element (title, decorative label, caption).

Key layout constraints:

• Asymmetric layouts are allowed. If the comparison side has only 3 verified claims to the main side's 5, render 3 vs. 5 — do not invent filler.
• Mark qualitative claims clearly. Use descriptor words instead of fake percentages ("Elevated," "Reduced," "Significant").
• Cite in-place where possible. Small parenthetical "(Author, Year)" under each statistic, with a full source list at the bottom.
• One source per statistic minimum. If a claim has no source_id, it cannot appear in the layout.

Save to docs/posters/<slug>/03-layout-spec.yaml.

Phase 6: Image Prompt Assembly

Programmatically compose the text-to-image prompt from the approved layout spec. Never re-author numbers at this stage — copy them verbatim from the spec.

The assembled prompt must include these explicit instructions to the image model:

Copy code
Render the following exact text verbatim. Do not substitute any numbers,
paraphrase any labels, or invent additional statistics, rows, or citations.
All percentages, author names, years, and institution names must appear
exactly as written below. If you cannot render any text element legibly
at the requested size, leave it out rather than approximating.

Use the prompt template in references/image-prompt-template.md.

Save to docs/posters/<slug>/04-image-prompt.md.

Dry-run check: show the assembled prompt to the user one last time before sending to the image model. Ask: "Ready to render?"

Phase 7: Final Rendering

Send the locked prompt to the configured text-to-image model. Save the rendered PNG to:

Copy code
docs/posters/<slug>/poster.png

Phase 8: Post-Render Audit

Claude reads the rendered image (multimodally) and confirms:

1. Every number in the layout spec appears correctly in the pixels.
2. Every citation (author, year, institution) is spelled correctly and matches the source list.
3. No unexpected rows, legend entries, or statistics have been hallucinated.
4. No approved rows are missing.

If drift is detected, log the specific mismatch, regenerate the image (Phase 7), and audit again. Cap at 3 regeneration attempts; beyond that, escalate to the user.

Produce the final sidecar source file at docs/posters/<slug>/sources.md — a reader-facing document listing every claim, number, and full citation with URL, so the poster is independently fact-checkable.

Output Files

For a poster with slug <slug>, the skill produces:

Copy code
docs/posters/<slug>/
├── poster.png                    # Final rendered image
├── sources.md                    # Reader-facing citation list
├── 01-claim-plan.yaml            # Phase 1
├── 02-verification-report.md     # Phase 3
├── 03-layout-spec.yaml           # Phase 5
└── 04-image-prompt.md            # Phase 6

The numbered intermediate files are the audit trail. poster.png and sources.md are the published artifacts.

Success Criteria

• 100% of numeric claims in the final image trace to a specific URL and quoted passage.
• 0 citations to non-existent, misattributed, or fictional sources.
• <5% post-render drift (percentage of claims that render incorrectly in pixels vs. the layout spec).
• Generation time is higher than one-shot (expect 5–15 minutes vs. seconds) but produces an artifact defensible for publication.

Anti-Patterns to Avoid

Flag these as footgun patterns if you notice the pipeline drifting toward them:

• Symmetry fabrication — inventing mirror-statistics for the weaker side of a versus comparison.
• Meta-source citation — citing a review paper (like Browning et al. 2014) as if it were the original empirical source for a specific percentage.
• Round-trip marketing stats — numbers that appear in many marketing pages with no traceable primary paper (e.g., "-23% cortisol in biophilic offices").
• Geographic misattribution — labeling research by the wrong country (e.g., calling Japanese Shinrin-yoku research "Finnish studies").
• Image-model number drift — image models silently change "+12%" to "+21%" or misspell author names; Phase 8 audit exists to catch this.

Example Session

See references/biophilic-design-case-study.md for a worked example showing how this skill would have prevented the 10 errors found in a real one-shot-generated poster on biophilic vs. brutalist spaces.

References

All templates and examples live in the references/ subdirectory:

• claim-plan-template.yaml — Phase 1 output
• verification-report-template.md — Phase 3 output
• layout-spec-template.yaml — Phase 5 output
• image-prompt-template.md — Phase 6 output
• biophilic-design-case-study.md — worked example