Overview

This page holds the Forge enterprise AI website standard: how public Forge sites should read, scan, and earn trust. The canonical text lives in the repo at docs/design/forge-enterprise-ai-website-standard.md — version it like any other design artifact.

Core principle

Lead with the human outcome, show the governed agentic system, and reveal technical depth only when the visitor asks for it.

Standard summary

Every major page should answer, near the top: what is this; who is it for; what problem it solves; why it is trustworthy; what to do next.

  • Hero bands: headline 4–9 words; subhead 18–36 words; one primary and one secondary CTA; one visual.
  • IA: curated product layer (Overview, How it works, Trust, Quickstart, Docs) vs. technical depth behind those doors — not an exhaustive generated tree in the header.
  • Copy: outcome language before mechanism; avoid generic “AI-powered” without control points.
  • Visuals: spacious, high-contrast hierarchy; subtle flows and boundaries — not decorative gimmicks.

Visual tokens for components stay in docs/design/forge-enterprise-ui.md.

Exemplar landing

The block below is a fictional product using the same HTML primitives as live Forge sites (forgesdlc-theme.css + render_product_landing_hero). It follows headline/subhead bands and section anatomy from the standard — not real product claims.

Exemplary landing — fictitious product for this showcase

Ship trustworthy docs without the generated wall

Your visitors see what the product is, who it is for, and what to do next before they hit dense reference. Keep mechanics in guides—not in the hero.

What visitors gain

Three outcome-led cards (mechanisms stay out of the titles).

Clarity in ten seconds

New visitors can restate the product and the next step without reading docs.

Trust before depth

Boundaries, approvals, and evidence appear before API lists or repo maps.

Technical depth on demand

Quickstart and reference stay linked, not dumped into the hero column.

How it works

Five steps — narrative flow without implementation noise.

  1. Capture the visitor job and role in plain language.
  2. Show the governed path from intent to evidence in one diagram or list.
  3. Separate product story from technical reference with two clear nav layers.
  4. Publish trust: boundaries, human checkpoints, and audit trails.
  5. Point newcomers to one onboarding action; experts to one deep dive.

Designed for governed adoption

Data boundary Show visitors where content is rendered vs. where it is stored.
Execution boundary Static site preview here; your deploy target stays explicit in real products.
Human control Editors approve copy; pipelines cannot silently rewrite marketing pages.
Evidence Publish records, review links, or CI badges — whatever proves the claim.
Admin control Feature flags and kill switches for risky experiments.
Out of scope This demo does not ship auth, billing, or telemetry — placeholders only.

Where it sits in the Forge design system

Demo links to sibling Kitchen Sink pages (not live product URLs).

Tokens Layouts Enterprise marketing Navigation

Try the standard on your site

New visitors: read the standard summary above. Technical owners: cross-check the acceptance list.

Review the summary Run the checklist

Acceptance checklist

Use this list before you publish or hand off a page refresh.

  • A new visitor can explain the product in one sentence after ten seconds.
  • One dominant promise on the homepage; technical detail is linked, not poured into the hero.
  • Trust model (boundaries, human checkpoints, evidence) is visible without reading reference.
  • Ecosystem placement is clear; no generated link walls above the fold.
  • CTAs are legible, ordered, and appropriate to role; focus states and contrast hold up.