How this rule is fixed

This is an AI-enabled rule. Pass/fail requires model judgment; there is no deterministic fixer in the pilot registry.

• Harness: invoke-ai-ruleset-harness.sh runs design-rules/ai/run-design-ai-rule.sh on the Before fixture and expects findings with matching principleId.
• Remediation: Cursor agent plans from forge-ux-remediation.plan.md after sitewide audit — not handbook After copy.

Detection module: docs/design/ux-audit/ai-enabled-design-principles.md#ai-narrative-coherence. Scroll down for Before / After examples and Evidence and remediation steps.

Purpose

Kitchen Sink landing_page and product_page shells stitch landing-hero, forge-section, outcome cards, mechanism steps, and final CTAs into a single arc. This AI rule judges whether the visible section order tells one story—problem → outcome → mechanism → next step—without argumentative contradictions between bands.

Deterministic checks (DET.PAGE.MODE, DET.SECTION.HEADING, DET.SECTION.SINGLE_JOB) catch page mode and heading structure; they do not judge whether the reader's mental thread holds from hero to footer. A page can pass heading order yet still open with a signup CTA before stating the problem, place trust copy that conflicts with mechanism steps, or bury the outcome under reference content.

Plan: Sketch the story in four beats on paper; walk the DOM top to bottom and note where a beat is missing, reordered, or contradicted. Do: Re-sequence forge-section bands; align hero tagline, mechanism cards, and trust copy to the same boundary claims; defer dense reference to after the arc completes. Check: A stranger can retell the page as one sentence with four clauses in order. Adjust: If the same sequencing defect repeats (CTA before outcome, trust/mechanism mismatch), propose a deterministic DET.* companion such as a landing-band order lint.

Passing signals

• Hero states the problem and intended outcome before naming implementation (product-landing-title → landing-hero-tagline; mechanism vocabulary waits for band three).
• The next major band delivers outcomes or proof (what changes for the reader)—not API tables, schemas, or maintainer indexes.
• A mechanism band (section-label "How it works" or equivalent) explains how the outcome is achieved with 4–6 ordered steps or cards—after outcomes, before the hard sell.
• Trust or boundary copy (forge-card trust tiles, landing-hero-clarification) uses the same data/execution/human-control claims as the mechanism band—no silent policy flip.
• Primary CTA appears after the reader understands problem, outcome, and mechanism; secondary links point to depth, not a competing story (btn-forge → Quickstart or #how-it-works, not three equal primaries).
• In-page progression matches scan order: no footer CTA promising "local-only" when an earlier band already described a hosted control plane.
• Section labels and headings advance the plot (Problem → Outcomes → How it works → Trust → Next step)—not five bands all titled "Overview".

Failing signals

• Hero headline is a feature list or endpoint catalog with no problem frame; reader never learns why the page exists.
• CTA or signup band appears before outcomes or mechanism—the page asks for action before earning the story.
• Contradictory claims across sections: hero says local-first / no cloud dependency; a later forge-section sells a hosted SaaS dashboard or managed tenancy without reconciliation.
• Mechanism before motivation: step cards or diagrams appear in band two while the outcome is still ambiguous.
• Trust band contradicts mechanism: "fully automated, no human gates" in one section and "human approval required" in the next without scope qualifiers.
• Reference dump interrupts the arc: schema tables or generated link walls sit between hero and outcomes, breaking narrative momentum.
• Sections repeat the same beat (two outcome grids back-to-back with no mechanism between) or argue past each other (band A says "for operators only"; band B promises "for every developer on day one").
• Final CTA copy does not match the story above (hero about methodology; footer button "Download compliance pack" with no preceding trust frame).

Before example

After example

Evidence and remediation

Capture: full-page screenshot with section labels visible; heading outline (H1–H3) annotated with story beats (P/O/M/N); a one-sentence paraphrase test ("Because … teams get … by … so next …"). Flag any claim that appears twice with different scope.

Remediate (in order):

1. Rewrite hero to problem + outcome only; strip mechanism vocabulary and premature CTAs from the first viewport.
2. Insert or reorder an outcomes forge-section before mechanism; each card states one reader benefit, not endpoint names.
3. Add How it works (4–6 steps) after outcomes; steps must explain the outcome cards above, not introduce a new product story.
4. Place trust/boundary copy after mechanism; reconcile data, execution, and human-control language with hero and steps (AI.TRUST.BOUNDARY_CLARITY).
5. Move API indexes, schemas, and generated nav to Reference after the arc; keep one primary CTA aligned with the final beat (DET.CTA.HIERARCHY).
6. Re-read top to bottom for contradictions; add scope qualifiers instead of silent policy changes.
7. If the same reordering defect repeats across pages, propose a deterministic companion (e.g. landing-band sequence lint keyed on section-label patterns).

Related rules

• DET.PAGE.MODE — page declares landing vs docs mode; narrative arc expectations differ by mode.
• DET.SECTION.SINGLE_JOB — each band advances one story beat, not mixed jobs.
• DET.SECTION.HEADING — heading ladder matches the on-page outline.
• AI.CONTEXT.COGNITIVE_CLARITY — jargon and heading substance; complements arc clarity.
• AI.TRUST.BOUNDARY_CLARITY — trust copy must not contradict mechanism claims mid-story.
• AI.VISUAL.HIERARCHY_CONFIDENCE — focal path supports hero → proof → depth read order.
• AI.CREDIBILITY.NO_OVERCLAIM — story claims stay bounded and verifiable across sections.