Rule handbook metadata
- Rule
AI.CONTEXT.COGNITIVE_CLARITY· laneai- Page status
- stale
- page_version
147f28c00ed45941c1315962642216c8aa994bc2dbb23cf8c520b91f309b0a2a- generated_at
- 2026-05-19T20:15:00.000Z
- registry_fingerprint
6773fda516344e110b5a7b1435e655e1264e773825ca8bbe62194189891c42ba
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.shrunsdesign-rules/ai/run-design-ai-rule.shon the Before fixture and expects findings with matchingprincipleId. - Remediation: Cursor agent plans from
forge-ux-remediation.plan.mdafter sitewide audit — not handbook After copy.
Detection module: docs/design/ux-audit/ai-enabled-design-principles.md#ai-context-cognitive-clarity. Scroll down for Before / After examples and Evidence and remediation steps.
Purpose
Kitchen Sink landing_page and product_page shells (landing-hero, forge-section, section-label, forge-card) are built to tell a product story in layers. This AI rule judges whether a first-time reader can build the right mental model in one pass—without insider vocabulary, heading bait-and-switch, or reference dumps where an outcome should live.
Deterministic checks (DET.SECTION.HEADING, DET.CONTEXT.BURDEN, DET.PROSE.LENGTH) catch structural budgets and heading order; this rule covers judgment they miss: acronyms used before definition, section titles that do not match body substance, and technical depth placed above the fold before the reader knows what the product does.
Plan: Read the first viewport and the next section as a stranger—note undefined terms, logical jumps, and headings that promise one job but deliver another. Do: Lead with problem → outcome → mechanism; define Forge terms inline on first use; link schemas, APIs, and long indexes below the story. Check: A colleague can paraphrase the page's single promise without guessing. Adjust: If the same clarity defect repeats (undefined product names in heroes, misleading section-label text), propose a deterministic DET.* companion.
Passing signals
- Hero copy states what it is and who it is for in plain language before naming sub-products (
product-landing-title→ shortlanding-hero-tagline→ one primary CTA). - Product names (Lenses, LCDL, Fleet, ForgeSDLC) appear after a one-line plain-language gloss, or only in a dedicated ecosystem band—not unexplained in the headline.
- Each
section-labeland followingh2/h3match the section body (no "Quickstart" band that is actually a schema dump). - Progressive disclosure: API tables, prop lists, and long
forge-supportasides live in the nextforge-sectionor behind a clear "Read reference" link—not in the hero grid. - Headings follow a scannable ladder (
h1once, section jobs obvious); in-page TOC entries (DET.NAV.IN_PAGE_TOC) align with what the eye sees. - Paragraphs stay readable (
DET.PROSE.LENGTH); lists use at most three bullets per card when explaining outcomes.
Failing signals
- Headline or tagline stacks acronyms and internal codenames with no inline definition ("LCDL + Fleet + Lenses control plane" before the reader knows the problem).
section-labelor cardcard-labelpromises onboarding or outcomes but the body is endpoint lists, generated nav, or maintainer-only detail.- Heading text is generic ("Overview", "Details", "More") while the section mixes unrelated jobs—reader cannot predict what they will learn.
- Hero
landing-hero-explainerorlanding-hero-clarificationparagraphs jump from trust model to JSON shapes without a mechanism sentence in between. - First screen reads like documentation cover: dense
forge-cardtiles with implementation vocabulary and no outcome framing. - Jargon is reused in CTAs and secondary links before it was introduced anywhere on the page.
Before example
Before (failing example)
Forge Platform
LCDL, Fleet, and Lenses in one spine
POST /v1/jobs, SQLite job store, governed task operators, and workspace hash catalogs.
Outcomes
What you get on day one
Reference
Job plane endpoints
POST /v1/jobs— docker_argv payloadGET /v1/jobs/{id}— status and logs pointer
Failing KS markup: undefined product names in the hero, misleading section label, reference dump in the outcomes band.
After example
After (passing example)
Forge Platform
Governed delivery from intent to evidence
Teams delegate more work to agents but still need clear intent, review gates, and proof.
Lenses (workspace visibility), LCDL (governed LLM tasks in Python), and Fleet (bounded job execution)—linked below, not assumed.
Passing KS markup: plain-language promise first, terms defined on first use, outcomes band matches labels, reference deferred.
Evidence and remediation
Capture: first-viewport screenshot, heading outline (H1–H3), and a plain-language paraphrase test ("What is this page asking me to believe?"). Note any acronym or product name that appears before definition.
Remediate (in order):
- Rewrite hero to problem → outcome; move endpoint lists, schemas, and maintainer vocabulary to Reference or a lower
forge-section. - Align every
section-label/h2with the section's single job (DET.SECTION.SINGLE_JOB); split mixed bands. - Define Forge terms inline on first use (short parenthetical or
landing-hero-clarificationsentence)—then reuse freely. - Stage depth: outcome cards in band two; mechanism diagram or steps in band three; link walls last.
- Re-check
DET.SECTION.HEADINGorder andDET.CONTEXT.BURDENafter edits. - If the pattern repeats (e.g. undefined product names in heroes), propose a deterministic companion such as a glossary-first hero lint or heading/substance matcher.