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-trust-boundary-clarity. Scroll down for Before / After examples and Evidence and remediation steps.

Purpose

Kitchen Sink landing_page, product_page, and forge-section trust bands must answer three operator questions without insider vocabulary: where data lives, where work runs, and who can stop or approve it. This AI rule judges whether those boundaries are understandable without Forge-specific knowledge—not whether the product is secure or compliant.

Deterministic checks (DET.PROSE.LENGTH, DET.LANDMARKS.REQUIRED) keep blocks readable and landmarked; they do not detect conflated “cloud + local + automated” copy, undefined control-plane jargon, or trust paragraphs that collapse data, execution, and human gates into one hand-wavy sentence. Reviewers apply this rule on heroes, trust strips, mechanism bands, and footer-adjacent policy copy.

Plan: Label every trust claim as data, execution, or human control; flag sentences that mix two or three without scope. Do: Split into three plain-language tiles or paragraphs; define jargon on first use or replace it. Check: A reader who does not know Forge can restate all three boundaries in their own words. Adjust: If the same conflation repeats (single “AI-powered secure cloud” band), propose a deterministic DET.* trust-block schema or required three-tile pattern.

Passing signals

• Hero or landing-hero-clarification states scope in plain language (what stays on your machine vs what a hosted service touches) before mechanism vocabulary.
• Trust band uses separate surfaces for data, execution, and human control—forge-card tiles with card-label headings, not one paragraph that says “secure AI.”
• Data boundary names what is stored, transmitted, or logged (handbook files, job payloads, tokens)—and what is explicitly out of scope.
• Execution boundary names where code runs (local daemon, your container host, operator-launched job plane)—without implying “everything is automatic.”
• Human-control boundary names review gates, approval points, or kill switches—who can pause, reject, or override agent output.
• Jargon (control plane, orchestrator, bearer token) appears only after a plain-language gloss or link to a definition page.
• Mechanism steps in a later forge-section reuse the same boundary words as the trust band (AI.NARRATIVE.COHERENCE).
• “AI-enabled” or “agent” language is paired with bounded delegation—not magic, autopilot, or black-box shorthand.
• Links point to maintainable trust docs (/trust#data-boundary, /trust#human-control) rather than undefined “learn more.”

Failing signals

• Single trust sentence bundles data + execution + human control (“enterprise-grade secure AI in the cloud”) with no separable claims.
• Hand-wavy AI magic: “powered by advanced AI,” “fully autonomous delivery,” “magic orchestration” without saying what runs where or who approves.
• Insider-only trust copy: control plane, tenancy, argv jobs, or hash governance named without a one-line plain-language definition for a public reader.
• Boundary flip within one band: “100% local” in the hero and “managed cloud sync” in the trust forge-card with no reconciliation.
• Execution conflated with data: “runs in your VPC” while copy also says telemetry and prompts are sent to a vendor API—without saying which is which.
• Human control omitted where the product delegates to agents: automation promised with no mention of review, approval, or operator override.
• Trust band is only badges or superlatives with no three-boundary structure (pair with AI.CREDIBILITY.NO_OVERCLAIM when claims are invented).
• Footer or hero CTA implies zero operator responsibility while docs describe human-owned delivery.

Before example

After example

Evidence and remediation

Capture: screenshot of hero and trust band; copy inventory tagged data / execution / human control; list undefined terms (control plane, orchestrator, AI-powered); note contradictions with mechanism bands or linked docs; DOM path for landing-hero-clarification and forge-card trust tiles.

Remediate (in order):

1. Split any single trust paragraph into three claims—one sentence each for data, execution, and human control.
2. Replace hand-wavy AI magic with mechanism language (API-triggered jobs, local store, token gates).
3. Define or remove insider terms on first use; link jargon to /trust or /docs anchors.
4. Align hero, trust tiles, and “How it works” bands so boundary words match (AI.NARRATIVE.COHERENCE).
5. Qualify automation scope—what is delegated vs what requires operator action.
6. Re-run AI batch with principleId: AI.TRUST.BOUNDARY_CLARITY; set deterministicCoverage and propose a DET.* three-tile trust schema if the same conflation repeats.

Related rules

• AI.GOVERNANCE.CREDIBILITY — trust, boundaries, and claims read bounded and operator-authentic.
• AI.CREDIBILITY.NO_OVERCLAIM — capabilities and proof are verifiable, not invented badges or metrics.
• AI.NARRATIVE.COHERENCE — trust copy does not contradict mechanism or hero claims mid-story.
• AI.CONTEXT.COGNITIVE_CLARITY — readers form a correct mental model before heavy jargon.
• AI.PREMIUM.ENTERPRISE_FEEL — calm trust presentation without hype stacking.
• DET.PROSE.LENGTH — readable block size (proxy for scannable trust copy).