Ramp — Machine Version Design System

Overview

The Ramp Machine Version is a deliberately reductive, text-native rendering of the Ramp spend management platform. Stripped of all visual ornamentation — no border radius, no drop shadows, no gradient washes, no iconography — the interface relies entirely on typographic hierarchy, structural whitespace, and markdown convention to communicate information architecture. It reads like a well-formed plain-text document that happens to live in a browser window.

The color philosophy is absolute binary contrast: {colors.ink} (#000000) against {colors.canvas} (#ffffff). Brand voltage lives not in chromatic accent but in the weight differential between headings (700) and body copy (400), and in the strategic deployment of {typography.mono} for URLs, code references, and structured data fields. Where a typical SaaS landing page might use a violet CTA button to draw the eye, this system uses bold weight and spatial isolation.

The defining typographic move is the dual-family stack: {typography.body-md} renders in Times New Roman at 16px for all prose, while technical strings — URLs, parameter values, inline references — shift into {typography.mono} at 13px. This creates a visual grammar where serif denotes narrative content and monospace denotes machine-readable metadata, a distinction that maps cleanly onto the page's identity as a "Machine Version."

Shape language is aggressively rectilinear. Every {rounded} token resolves to 0px. Cards, buttons (if they existed), code blocks, and containers all present sharp corners. This is not an oversight but an ideological stance: the machine version rejects the softening gestures of contemporary UI in favor of terminal-era precision.

The single sub-system present is the promotional offer block, which uses identical tokens to the rest of the page but gains semantic structure through heading hierarchy ({component.heading-h2} → {component.heading-h3}) and list enumeration.

Key Characteristics:

• Canvas is pure {colors.canvas} (#ffffff) with zero texture or tint
• All ink is {colors.ink} (#000000) — no gray body text, no muted secondary copy in standard flows
• Primary brand token {colors.primary} is functionally identical to ink; CTAs are text-based links
• Typography splits between {typography.body-md} (Times New Roman, 16px) for prose and {typography.mono} (monospace, 13px) for technical strings
• Every {rounded} token is 0px — the system is explicitly anti-radius
• No shadow tokens exist in {extensions.shadows} — elevation is communicated through spacing only
• Section separation uses {spacing.lg} (24px) vertical padding and {component.horizontal-rule} dividers
• Links are {component.text-link} — underlined text in body color, no distinct link hue
• Motion level is "still" per {extensions.motion.level} — no transitions, no animations

Colors

Brand & Accent

• Primary ({colors.primary} — #000000): Pure black. Used as the conceptual brand anchor — functionally interchangeable with {colors.ink} in this machine context. Would map to CTA foreground or active states in a decorated version.
• Primary Active ({colors.primary-active} — #333333): Dark gray. Reserved for pressed/hover states on interactive text elements.
• Accent ({colors.accent} — #000000): Aliased to primary. The machine version does not introduce a secondary brand color; all emphasis is achieved through weight and position.

Surface

• Canvas ({colors.canvas} — #ffffff): Pure white. The universal background for {component.page-body}, all sections, and all cards.
• Surface ({colors.surface} — #ffffff): Identical to canvas. Included for token completeness; used interchangeably.
• Surface Soft ({colors.surface-soft} — #f5f5f5): Near-white gray. Applied exclusively to {component.code-block} and {component.inline-code} backgrounds to distinguish machine strings from prose without introducing color.
• Surface Strong ({colors.surface-strong} — #e0e0e0): Medium gray. Used for {component.horizontal-rule} dividers and any structural borders.
• Surface Dark ({colors.surface-dark} — #1a1a1a): Near-black. Reserved for potential inverted sections or footer backgrounds not present in current view.

Text

• Ink ({colors.ink} — #000000): Pure black. All headings, body paragraphs, list items, and default text.
• Body ({colors.body} — #000000): Identical to ink in this theme. Separated for systems where body text might differ from heading color.
• Muted ({colors.muted} — #4a4a4a): Dark gray. Used in {component.footer-note} for secondary/attribution text.
• Muted Soft ({colors.muted-soft} — #6a6a6a): Medium gray. Available for disabled states or tertiary information.
• On Primary ({colors.on-primary} — #ffffff): White. Satisfies AA contrast against {colors.primary}; would be text color on a solid-black button background.
• On Dark ({colors.on-dark} — #ffffff): White. Text color for any {colors.surface-dark} backgrounds.

Hairlines & Borders

• Hairline ({colors.hairline} — #e0e0e0): Light gray. Color of {component.horizontal-rule} elements that separate major sections (the --- markdown rules).
• Border Strong ({colors.border-strong} — #999999): Mid gray. For any explicit field borders or container outlines if introduced.

Semantic

• Error ({colors.error} — #cc0000): Dark red. Reserved for validation messages or critical alerts not visible in current screenshot.
• Success ({colors.success} — #006600): Dark green. For confirmation states.
• Link ({colors.link} — #000000): Black — identical to body text. In the machine version, links are distinguished by underline convention and bracket syntax [Text](url), not by color change.
• Link Active ({colors.link-active} — #333333): Dark gray. Visited or active link state.

Typography

Font Family

The type system operates on a strict two-face split. Times New Roman (with generic serif fallback) carries all narrative content: headings, paragraphs, list items, labels. It renders at {typography.body-md} (16px, weight 400) for reading prose and scales up through {typography.display-xl} (32px, weight 700) for the document title. This is a proprietary system font available on virtually all operating systems; no web font loading is required or expected.

Monospace (the generic CSS monospace stack, typically Courier New, Consolas, or SF Mono depending on OS) handles all machine-readable strings: URLs inside brackets, parameter keys like incentive=march26_agent_incentive_A_3100, inline code fragments, and any structured data values. It locks to {typography.mono} (13px, weight 400) regardless of context — there is no scaled-up monospace heading variant.

The choice of Times New Roman over a sans-serif like Inter or system-ui is deliberate. It signals "document" rather than "interface." The machine version positions itself as a printable, archival-format rendering of Ramp's marketing content, and the serif face reinforces that contract.

Hierarchy

| Token | Size | Weight | Line Height | Letter Spacing | Use | |---|---|---|---|---|---| | {typography.display-xl} | 32px | 700 | 1.2 | 0 | Document title ("# Ramp — Machine Version") | | {typography.display-lg} | 24px | 700 | 1.25 | 0 | Section headings ("## Ramp Promotional Offer") | | {typography.title-md} | 18px | 700 | 1.35 | 0 | Sub-section headings ("### Corporate Cards") | | {typography.label-md} | 14px | 700 | 1.4 | 0 | Fourth-level headings ("#### Expense Management") | | {typography.body-md} | 16px | 400 | normal | normal | Paragraph text, list items, link anchors | | {typography.body-sm} | 14px | 400 | 1.45 | 0 | Footer notes, secondary descriptions | | {typography.caption} | 13px | 400 | 1.4 | 0 | Attributions, timestamps | | {typography.mono} | 13px | 400 | 1.4 | 0 | URLs, parameters, code strings | | {typography.button} | 13px | 400 | 1.3 | 0 | Button text (hypothetical) | | {typography.label-md} | 14px | 700 | 1.4 | 0 | Field labels, strong emphasis |

Principles

Weight is the primary carrier of hierarchy. The system spans only two weights — 400 (normal) and 700 (bold) — with nothing in between. There are no 500, 600, or 300 variants. When a heading needs to command attention above body copy, it goes to 700. When body copy needs to emphasize a phrase inline, it wraps in ** which maps to 700. This binary weight scale is consistent with the overall reductive philosophy.

Size differentiation is modest. The largest heading ({typography.display-xl} at 32px) is exactly double the body size (16px). Intermediate steps follow a roughly 1.33× ratio (24px, 18px). This compressed scale prevents the page from feeling like a decorated landing page while still providing clear stratification.

Letter-spacing is universally 0 (or normal for the body role). There is no tracking adjustment at any level — another rejection of contemporary UI conventions where display type often receives slight negative tracking. The machine version lets the font's native metrics stand unchanged.

Italic and uppercase are not observed in the current view but would be permissible within the markdown grammar. Uppercase would map to the existing weight/size tokens with CSS text-transform: uppercase; italic would apply font-style: italic to whichever typography role is active.

Note on Font Substitutes

Times New Roman is pre-installed on macOS, Windows, iOS, Android, and Linux distributions. No Google Fonts fallback is necessary or recommended — loading a web font would violate the machine version's offline-first, minimal-dependency ethos. If a near-visual match were required for environments lacking Times New Roman (rare), Noto Serif from Google Fonts at weight 400/700 would be the closest equivalent, though it introduces a network request that the design philosophy explicitly avoids.

For monospace, the CSS generic monospace keyword is correct and sufficient. It resolves to a platform-appropriate fixed-width font automatically. Do not specify "Courier New" or "Consolas" explicitly — let the user agent decide.

Layout

Spacing System

• Base unit: 1px (the system does not enforce an 8px grid; spacing values are pragmatic).
• Tokens: {spacing.xxs} (2px) for inline-code internal padding; {spacing.xs} (4px) for tight intra-element gaps; {spacing.sm} (8px) for minor vertical rhythm; {spacing.md} (13px) for paragraph spacing and code-block internal padding — this is the dominant recurring value extracted from the DOM; {spacing.lg} (24px) for section-to-section vertical padding; {spacing.xl} (32px) for major page margins; {spacing.section} (48px) for extreme separation (not actively used in current viewport but available).
• Section padding (vertical): {spacing.lg} (24px) — applied between {component.promo-section}, {component.overview-section}, and {component.products-section} via implicit newline accumulation.
• Card internal padding: Not applicable in current view — the machine version uses flow layout without card containers. If cards were introduced, {spacing.md} (13px) would be the canonical inner padding per code-block precedent.
• Gutters: The {component.page-body} has {spacing.md} (13px) padding on all sides as the sole gutter. Content flows at full viewport width minus this margin.

Grid & Container

• Max content width: none — the machine version is fluid. Text reflows to viewport width with no max-width constraint, no centering container, no column grid. This is intentional: the format prioritizes readability on terminal windows, e-readers, and narrow viewports over desktop optimization.
• Editorial density: high. Information density approaches that of a man page or API reference. Whitespace exists for scannability, not for luxury positioning.
• Grid behaviors: None detected. The layout is a single-column <pre> or text-flow block. No multi-column layouts, no sidebar rails, no sticky elements.
• Hero column splits: N/A. The document opens with a title line, then immediately into content. No hero-image-plus-copy arrangement exists.

Whitespace Philosophy

The machine version practices functional minimalism — whitespace separates semantic units (section to section, paragraph to paragraph) but never decorates. Vertical rhythm derives from accumulated line-height and {spacing.md} (13px) paragraph gaps. Horizontal whitespace is limited to the 13px page gutters. The result reads like a well-typed email or a formatted README: spacious enough to scan, dense enough to feel substantive.

Header Architecture

|-----------------------------------------------------------------------|
| # Ramp – Machine Version                                              |
| (display-xl, 32px, weight 700)                                        |
|-----------------------------------------------------------------------|
| **Quick links:** [Docs](url) · [Help Center](url) · ...              |
| (body-md, inline, with monospace URLs)                                |
|-----------------------------------------------------------------------|
| --- (horizontal-rule, hairline color)                                 |
|-----------------------------------------------------------------------|

The header occupies the top ~80px of the document. It contains the H1 title, a quick-links bar with bracketed navigation, and a horizontal rule separator. No logo mark, no utility menu, no search field.

Hero Section

There is no hero section in the conventional landing-page sense. The document proceeds directly from header to content:

|-----------------------------------------------------------------------|
| ## Ramp Promotional Offer                                             |
| (display-lg, 24px, weight 700)                                        |
|                                                                       |
| Ramp is currently offering a $3,100 signup bonus...                   |
| (body-md, 16px, wrapping flow)                                        |
|                                                                       |
| Offer amount: $3,100                                                  |
| Condition: Issued after approval...                                   |
| (body-md, label-value pairs)                                          |
|                                                                       |
| To sign up or book a meeting:                                         |
| <https://ramp.com?incentive=...>                                      |
| (mono, 13px, URL as standalone line)                                  |
|-----------------------------------------------------------------------|

Promotional & Product Sections

|-----------------------------------------------------------------------|
| ## Overview                                                           |
|                                                                       |
| - Ramp is an all-in-one spend management platform...                  |
| - Trusted by 70,000+ businesses including...                          |
| - Key outcomes: Ramp customers have saved...                          |
| (unordered list, body-md, dash-prefixed)                              |
|-----------------------------------------------------------------------|
| ---                                                                   |
|-----------------------------------------------------------------------|
| ## Core Products                                                      |
|                                                                       |
| ### Corporate Cards                                                   |
| * Unlimited physical and virtual Visa cards...                        |
| * Preset controls by vendor, category...                              |
| (unordered list, asterisk-prefixed for sub-sections)                  |
|-----------------------------------------------------------------------|
| ### Expense Management                                                |
| * Auto-receipt capture at the moment of card swipe...                 |
| (continues same pattern)                                              |
|-----------------------------------------------------------------------|

The Overview section uses dash-prefixed list items. The Core Products section nests H3 headings ({component.heading-h3}) with asterisk-prefixed bullet points — a markdown convention the machine version preserves faithfully.

Elevation & Depth

| Level | Treatment | Use | |---|---|---| | 0 — Flat | No shadow, no border, background = canvas | {component.page-body}, all text blocks | | 1 — Inline distinction | Background = {colors.surface-soft}, no border, no shadow | {component.inline-code} fragments | | 2 — Block distinction | Background = {colors.surface-soft}, no border, no shadow | {component.code-block} containers | | 3 — Separator | 1px solid {colors.hairline}, no shadow | {component.horizontal-rule} between sections |

The depth system is functionally flat. There are no drop shadows at any level — every {extensions.shadows} token resolves to "none". Elevation is communicated through two mechanisms only: background color shifts (white → #f5f5f5 for code blocks) and the presence of a 1px horizontal rule. This is consistent with the machine version's anti-decorative stance.

The philosophy is layered-by-semantics, not by simulation. A code block sits "above" prose not because it casts a shadow, but because its background differs. A section break exists because a rule line appears, not because the next section floats higher in z-space. This approach mirrors how LaTeX documents or man pages create visual separation.

No decorative depth elements exist: no gradient washes, no photographic backgrounds, no pattern overlays, no glassmorphism. The page is purely additive — content and structure, nothing more.

Shapes

Border Radius Scale

| Token | Value | Use | |---|---|---| | {rounded.sm} | 0px | Small elements (inline code) — explicitly square | | {rounded.DEFAULT} | 0px | Default for all components — no rounding anywhere | | {rounded.md} | 0px | Medium containers — square | | {rounded.lg} | 0px | Large containers — square | | {rounded.xl} | 0px | Extra-large elements — square | | {rounded.pill} | 0px | Buttons/tags — explicitly not pill-shaped | | {rounded.full} | 0px | Avatars/circles — explicitly not circular |

Every radius token is 0px. This is not a missing-data artifact; it is a design decision. The machine version presents all rectangles as true rectangles. If a future iteration introduced rounded corners, it would represent a departure from the current design language, not an evolution within it.

Photography Geometry

Not applicable. The machine version contains no imagery — no product screenshots, no team photos, no illustrations, no icons. All visual communication is typographic. If images were added in a future extension, the shape system dictates they would have 0px corner radius and no border treatment, rendered as inline or block-level images with no special framing.

Components

No hover states documented. Hover behavior is unreliable to extract from a single screenshot. State variants live as separate entries in the components: frontmatter (e.g. {component.text-link-active}, {component.button-primary-active}); add hover styling at implementation time per your stack's conventions.

Page Structure

{component.page-body} — The root container for all content. Background {colors.canvas}, text {colors.ink}, type {typography.body-md} at 16px. Padding is {spacing.md} (13px) on all sides. This is the <pre> or text-block element that holds the entire document. No border, no shadow, no max-width. Content flows as a single continuous block.

{component.horizontal-rule} — The --- markdown separator rendered as a 1px-high element spanning full width. Background {colors.hairline} (#e0e0e0). Height 1px, width 100%. Used between the quick-links bar and the first content section, and between major sections thereafter. No rounding (irrelevant for a line).

Headings

{component.heading-h1} — The document title: "# Ramp – Machine Version". Background {colors.canvas}, text {colors.ink}, type {typography.display-xl} (32px, weight 700). Padding {spacing.sm} (8px) vertical to separate from content below. No underline, no decoration.

{component.heading-h2} — Major section headings: "## Ramp Promotional Offer", "## Overview", "## Core Products". Background {colors.canvas}, text {colors.ink}, type {typography.display-lg} (24px, weight 700). Padding {spacing.md} (13px) top, {spacing.xs} (4px) bottom to create breathing room before the section content begins. These are the primary navigational landmarks in the document.

{component.heading-h3} — Sub-section headings: "### Corporate Cards", "### Expense Management". Background {colors.canvas}, text {colors.ink}, type {typography.title-md} (18px, weight 700). Same padding pattern as H2. These nest under H2 sections and introduce product-specific content.

{component.heading-h4} — Fourth-level headings (potential use for feature lists within products). Background {colors.canvas}, text {colors.ink}, type {typography.label-md} (14px, weight 700). Tighter padding ({spacing.sm}) reflects its lower hierarchical rank. Not actively used in current viewport but defined for completeness.

Text Content

{component.paragraph} — Standard body text block. Background transparent (inherits canvas), text {colors.body} (#000000), type {typography.body-md} (Times New Roman, 16px, weight 400). Padding {spacing.xs} (4px) vertical between consecutive paragraphs. Line height is normal (browser-default, approximately 1.2 for Times New Roman at 16px). Wraps naturally at viewport edge.

{component.bold-text} — Inline bold span for **wrapped text**. Inherits parent background and type except weight becomes 700. Used for "Quick links:" label, "Offer amount:", "Condition:", "Terms & Conditions:". No padding change, no color change — weight alone carries the emphasis.

{component.list-item} — Unordered list item (dash-prefixed - or asterisk-prefixed *). Background transparent, text {colors.body}, type {typography.body-md}. Padding {spacing.xs} (4px) vertical. The prefix character (- or *) is part of the text flow, not a generated counter. Overview section uses - prefix; Core Products subsections use * prefix — a markdown nesting convention preserved visually.

{component.footer-note} — Secondary text appearing at document end or in meta positions. Background {colors.canvas}, text {colors.muted} (#4a4a4a — darker than body for subtle de-emphasis), type {typography.body-sm} (14px). Used for attribution lines like "This offer is documented publicly at:" and URL references below it. Padding {spacing.lg} (24px) top to separate from previous section, {spacing.xl} (32px) bottom as page exit margin.

Links & Interactive Text

{component.text-link} — Inline hyperlink in markdown syntax [anchor text](url). Background transparent, text {colors.link} (#000000 — identical to body text in machine version), type {typography.body-md}. Underlined per browser default or markdown convention. The URL portion renders in {typography.mono} (13px) when displayed as a standalone line (as seen in the "To sign up or book a meeting:" block). No color differentiation from surrounding text — the bracket-and-parentheses syntax and underline carry all signification.

{component.text-link-active} — Visited or active state for links. Text color shifts to {colors.link-active} (#333333). No other property changes. Implement hover/focus states per stack convention using this as the pressed/visited baseline.

Code & Monospace

{component.mono-text} — Standalone monospace line, typically a URL or parameter string displayed as its own block. Background transparent, text {colors.ink}, type {typography.mono} (monospace, 13px, weight 400). Used for the full incentive URL: <https://ramp.com?incentive=march26_agent_incentive_A_3100>. The angle brackets are part of the rendered content, not decorative wrappers. No padding — the line stands alone with natural line-height spacing.

{component.inline-code} — Short monospace fragment embedded in prose (e.g., parameter key march26_agent_incentive_A_3100 if it appeared inline). Background {colors.surface-soft} (#f5f5f5) to subtly lift it from surrounding text, text {colors.ink}, type {typography.mono}. Padding {spacing.xxs} (2px) horizontal, {spacing.xs} (4px) vertical — tight wrap. No border, no rounding (0px per system default).

{component.code-block} — Multi-line code or data block. Background {colors.surface-soft} (#f5f5f5), text {colors.ink}, type {typography.mono}. Padding {spacing.md} (13px) on all sides. Would be used for JSON snippets, API responses, or configuration examples if present. Not actively rendered in current viewport but defined for system completeness. No border, no shadow, no header bar — just a colored rectangle with monospace text.

Sections

{component.quick-links-bar} — The navigation line below the H1: "Quick links: Docs · Help Center · Integrations · Pricing · Trust Center". Background {colors.canvas}, text {colors.ink}, type {typography.body-md}. The label "Quick links:" is {component.bold-text} (weight 700). Each link is {component.text-link}. Separators are · (middle dot) characters in the text flow. Padding {spacing.md} (13px) vertical to separate from H1 above and horizontal rule below.

{component.promo-section} — The "## Ramp Promotional Offer" content block. Background {colors.canvas}, text {colors.ink}, type {typography.body-md}. Contains H2 heading, introductory paragraph, labeled offer details (Offer amount, Condition), call-to-action URL, terms reference, and documentation link. Padding {spacing.lg} (24px) vertical as implicit spacing from adjacent sections. Structurally a grouping of {component.heading-h2}, {component.paragraph}, {component.bold-text}, {component.mono-text}, and {component.text-link} children.

{component.overview-section} — The "## Overview" content block. Same token profile as {component.promo-section}. Contains three dash-prefixed {component.list-item} entries describing Ramp's value proposition, customer list, and outcomes. Bullet points use - prefix character.

{component.products-section} — The "## Core Products" content block. Contains nested H3 headings ({component.heading-h3}) for "Corporate Cards" and "Expense Management", each followed by asterisk-prefixed {component.list-item} entries describing features. The shift from - to * prefix marks the nesting level visually — a markdown convention the machine version honors.

Do's and Don'ts

Do

• Use {typography.body-md} (Times New Roman, 16px, weight 400) for all prose paragraphs — this is the reading default and should carry ~90% of the page's word count.
• Render URLs, parameter strings, and any machine-readable values in {typography.mono} (monospace, 13px) — this creates the essential visual grammar distinguishing narrative from data.
• Separate major sections with {component.horizontal-rule} (1px, {colors.hairline}) — it's the only structural divider the system permits.
• Apply {colors.surface-soft} (#f5f5f5) background to any inline code or code block — the subtle gray lift distinguishes code without introducing new hues.
• Keep all {rounded} tokens at 0px — the machine version is explicitly anti-radius; even buttons and avatars must render square.
• Use weight 700 (via {typography.display-lg}, {typography.title-md}, or {component.bold-text}) as your sole hierarchy mechanism alongside size — no italics, no uppercase, no letter-spacing tricks.
• Set {component.page-body} padding to {spacing.md} (13px) as the universal gutter — do not introduce asymmetric margins or centering containers.
• Preserve markdown punctuation in rendered output — brackets around link anchors, dashes and asterisks as bullet prefixes, hash counts as heading level indicators.
• Use {spacing.lg} (24px) as the vertical rhythm unit between sections — it provides scannability without wasting space.
• Reference {colors.muted} (#4a4a4a) for footer notes and attributions — the slight darkening signals "meta content" without leaving the grayscale family.

Don't

• Don't add any shadow to any element — {extensions.shadows.sm}, .md, and .lg are all "none" by design; depth comes from background color only.
• Don't introduce a link color different from {colors.ink} — in the machine version, links are black and distinguished by underline/syntax alone.
• Don't load web fonts — Times New Roman and monospace are system fonts; a network request violates the offline-first philosophy.
• Don't round corners on anything, even "subtly" — {rounded.pill} is 0px, not 9999px; a pill button would be a foreign object in this system.
• Don't add a max-width container — the layout is fluid and viewport-full; constraining width would break the terminal-window use case.
• Don't use weight 500 or 600 — the system recognizes only 400 (normal) and 700 (bold); intermediate weights don't exist in the type scale.
• Don't add gradient backgrounds, pattern textures, or image banners — the canvas is {colors.canvas} (#ffffff) everywhere, always.
• Don't implement dropdown menus, modals, or sticky navbars — the machine version is a linear scrollable document with no overlay surfaces.
• Don't use {colors.primary} as a background for buttons with {colors.on-primary} text — there are no filled-button components in this system; CTAs are text links.
• Don't insert icon glyphs or emoji — the icon library is {extensions.icons}: "none"; all communication is typographic.

Motion & Animation

Transition Tokens

No explicit transition properties were detected in the extracted CSS beyond a generic all declaration with no duration or easing specified. The machine version is static by design:

/* No transition tokens extracted */
/* The system is motionless — all state changes are instant */

If interaction states (focus, active) require visual feedback in implementation, the recommended approach is instant property swap with no interpolation — consistent with the "machine" aesthetic where state changes are discrete, not animated.

Keyframe Animations

None detected. No @keyframes rules, no scroll-triggered reveals, no loading spinners. The page renders as a complete static document.

Interaction Patterns

• Link navigation: Standard browser default — click navigates to URL, no preview, no smooth-scroll interception.
• Text selection: Native browser selection highlighting (typically system blue) — no custom selection color defined.
• Focus rings: Not styled in extracted CSS; browser default outline would appear on interactive elements. Recommend retaining default or applying a simple 1px {colors.ink} outline for accessibility.
• Scroll behavior: Instant (no scroll-behavior: smooth). The document is short enough that smooth scrolling adds no value.
• Hover: Per the no-hover-policy, implement {component.text-link-active} color shift (#333333) on hover as the sole interactive feedback.
• Print: The machine version is print-optimized by nature — no @media print overrides needed; the layout translates directly to paper.

Imagery Style

• Photography: None present. The machine version is a text-only rendering. No product screenshots, no team photos, no lifestyle imagery.
• Illustration: None. No diagrams, no icons, no vector art.
• 3D/Gradient/Abstract: None. No decorative graphic elements of any kind.
• Subject matter: Entirely textual — marketing copy, product descriptions, promotional terms, URL references.
• Color treatment: Grayscale only. Black text on white background, with #f5f5f5 for code backgrounds and #e0e0e0 for rule lines.
• Role of imagery: Non-existent. The design consciously rejects visual media in favor of information density and machine readability.
• Signature technique: The absence of imagery is the signature technique. In a landscape of image-heavy SaaS landing pages, the machine version's radical text-only stance is its distinguishing visual move.
• Future imagery constraints: If imagery were ever added, it would require 0px corner radius, no border, no shadow, and likely grayscale treatment to avoid breaking the austere palette.

Icon System

• Library: {extensions.icons}: "none". No icon library is loaded or used. No Lucide, Heroicons, Material Icons, or custom SVG iconography detected.
• Specific icons observed: None. The page contains no <svg>, <img>, or icon-font glyphs. Navigation is text-based ([Docs], [Help Center]). Structural markers are typographic (#, ##, -, *, **).
• Treatment: N/A. No stroke-width, no fill-color, no sizing grid to document. The system relies entirely on Unicode characters and markdown punctuation for visual annotation.
• Alignment: Text-based markers (bullets, hashes) align with the left margin of their containing block, indented per markdown nesting level. No icon-with-text baseline alignment concerns exist.
• Recommendation: Maintain zero-icon policy for any machine-version extension. If icons become unavoidable (e.g., for a status indicator), render them as Unicode symbols (✓, ✗, ⚠) in the current font, not as graphical assets.

Recommended Frontend Stack

- Framework:      Vanilla HTML or minimal static-site generator (Astro without islands, 
                  11ty, or plain .html files). No React/Vue/Angular — the page has zero 
                  interactivity that requires a client-side runtime.
- Styling:        Vanilla CSS with a single <style> block, or a tiny utility class set 
                  (~20 classes max). Tailwind is heavy overkill for a two-color, 
                  zero-radius, zero-shadow system. CSS custom properties for the tokens 
                  defined in this spec would suffice in ~60 lines.
- Fonts:          System fonts only. No @font-face, no Google Fonts import. Rely on 
                  "Times New Roman", Times, serif for body/headings and the generic 
                  "monospace" stack for code.
- Animation:      None. No Framer Motion, no GSAP, no CSS @keyframes. If a fade-in on 
                  scroll is desired for polish, use the Intersection Observer API with 
                  a 150ms opacity transition — but this is optional and non-canonical.
- Icons:          None. Unicode symbols for any needed indicators.
- Component lib:  None. No Radix, no shadcn, no Headless UI. The "components" in this 
                  system are semantic HTML elements (<h1>-<h4>, <p>, <ul>, <li>, <a>, 
                  <code>, <pre>) with token-driven class names.
- Build tool:     Optional. The page could be a hand-written HTML file. If a build step 
                  is desired for consistency, use any tool that outputs static HTML 
                  without injecting runtime JavaScript.

Responsive Behavior

Breakpoints

| Name | Width | Key Changes | |---|---|---| | Mobile | < 640px | No layout change — the fluid single-column layout is natively mobile-friendly. 13px gutters remain appropriate. Font sizes stay constant (no scaling down). | | Tablet | 640–1024px | No layout change. Text reflows naturally within the wider column. No multi-column activation. | | Desktop | 1024–1440px | No layout change. Line lengths may grow long (80–100 characters) which is acceptable for a document-style reading experience. | | Wide | > 1440px | Consider adding a max-width: 800px and margin: 0 auto to {component.page-body} if line length exceeds ~120 characters (readability threshold). This is optional and not present in the current implementation. |

Touch Targets

• {component.text-link}: Text-based link with no minimum dimension. On touch devices, the entire linked text phrase is tappable. For URLs rendered as standalone lines ({component.mono-text}), the full line width is the target. WCAG AAA's 44×44px minimum is not met for inline links, but this is acceptable for a document-format page where links are densely embedded in prose.
• {component.horizontal-rule}: Non-interactive. No touch considerations.
• General: This is not a touch-optimized UI. It is a readable document. Touch target standards for app interfaces do not apply.

Collapsing Strategy

• Navigation: The quick-links bar ({component.quick-links-bar}) is already a single inline line of text. On narrow viewports, links wrap naturally to the next line. No hamburger menu, no collapse-to-dropdown behavior needed.
• Headings: All headings ({component.heading-h1} through {component.heading-h4}) wrap text naturally. No truncation, no font-size reduction at small widths.
• Lists: {component.list-item} elements reflow as block-level items regardless of viewport width. No grid-to-stack transformation occurs because no grid exists.
• Code blocks: {component.code-block} would scroll horizontally on overflow (browser default for <pre>). For {component.inline-code}, long values wrap or overflow depending on overflow-word setting — recommend word-break: break-all for URLs to prevent horizontal scroll.
• Page gutters: {spacing.md} (13px) remains constant at all breakpoints. Some designers reduce gutters on mobile; this system does not.

Image Behavior

Not applicable — no images exist in the machine version. If images were added in a future iteration:

• Hero/product images would be <img> elements with no explicit width/height (fluid by default).
• No srcset or art direction complexity needed for a text-primary page.
• Alt text would be mandatory and rendered inline (potentially in {typography.mono} for file-name aesthetics).

Iteration Guide

1. Start with vanilla HTML. Create a single index.html file with a <pre> block or a styled <div class="page-body"> as the root container. Apply {component.page-body} tokens: background {colors.canvas}, padding {spacing.md}, font-family from {typography.body-md}.
2. Define CSS custom properties for every frontmatter token. Map {colors.primary} to --color-primary: #000000, {typography.body-md} values to --font-body: "Times New Roman"; --font-size-body: 16px; etc. Reference these variables everywhere — never hardcode a hex or pixel value that has a token.
3. Implement the heading hierarchy. Write <h1>–<h4> elements with classes mapping to {component.heading-h1} through {component.heading-h4}. Ensure the weight jumps to 700 and sizes follow the 32→24→18→14px scale. Test that ## and ### levels are visually distinct.
4. Build the dual-typeface rendering. Wrap all URLs, parameter strings, and code fragments in <code> with class mono-text or inline-code, applying {typography.mono} (13px, monospace stack). Verify that these visually "pop" from the Times New Roman prose due to family and size contrast.
5. Structure sections with horizontal rules. Insert <hr class="horizontal-rule"> between the quick-links bar and first section, and between each major ## heading block. Style with background: {colors.hairline}; height: 1px; border: none;.
6. Render lists with correct prefixes. Use <ul> with list-style: none and manually prepend - or * via ::before pseudo-elements (or include them in the text content to match the literal markdown aesthetic). Apply {component.list-item} tokens.
7. Apply the zero-radius, zero-shadow discipline. Add border-radius: 0 !important; and box-shadow: none !important; as global resets if your CSS reset or framework injects defaults. Every component must verify square corners.
8. Implement links as text-only. Style <a> elements with color: {colors.link} (black) and text-decoration: underline. For visited/active state, switch to {colors.link-active} (#333333). No background color, no padding, no border — just underlined text.
9. Test in a terminal emulator. Open the page in a text-based browser (Lynx, w3m) or print to PDF. The machine version should render nearly identically to its graphical browser appearance because it avoids all advanced CSS features.
10. Run the linter. Execute npx @google/design.md lint DESIGN.md after any token additions or component changes. Watch for broken-ref warnings (every {token.path} in prose must exist in frontmatter), orphaned-tokens (tokens defined but never referenced), and contrast-ratio flags (though all black-on-white combinations pass by definition).

Font Setup: No web fonts to configure. Ensure your CSS declares font-family: "Times New Roman", Times, serif; for the body and headings, and font-family: monospace; for code/URL elements. These map to {typography.body-md} and {typography.mono} respectively. Define them as CSS custom properties:

:root {
  --font-body: "Times New Roman", Times, serif;
  --font-mono: monospace;
  --color-canvas: #ffffff;
  --color-ink: #000000;
  /* ... remaining tokens */
}

Known Gaps

• Hover state styling: Per the no-hover-policy, hover colors, transforms, and background shifts are not documented. The frontmatter includes {component.text-link-active} as a pressed/visited baseline, but specific :hover pseudo-class styles are left to implementation discretion.
• Loading/skeleton states: Not applicable to a static document, but if this page were dynamically generated, no skeleton screen or loading spinner design exists in the current system.
• Form validation states: The page contains no forms. If a "Contact Us" or email-capture input were added, error/success/focus states beyond {component.text-input-focus} (which is defined but unrendered) would need design work.
• Authenticated/dashboard surfaces: The machine version shows only the public marketing/document view. Authenticated flows (dashboard, settings, transaction history) are entirely outside scope and likely follow a completely different (decorated) design system.
• Dark mode: Despite {extensions.mode}: "dark" in the frontmatter (carried from the source data), the visual evidence shows a light-mode page (white canvas, black ink). This may indicate the source CSS variable was mislabeled, or the "machine version" conceptually represents a "dark" (stripped-down) variant regardless of actual luminance. Implementers should treat this as a light-theme spec.
• Print stylesheet: No @media print rules were extracted. The page's simplicity suggests it prints well by default, but explicit print optimizations (remove underlines from links, ensure URLs are visible) have not been designed.
• Accessibility (a11y) specifics: No :focus-visible ring style, no prefers-reduced-motion media query response, no skip-navigation link, no ARIA landmark roles beyond implicit heading hierarchy. These are recommendations for implementation, not gaps in the visual spec per se, but they represent incomplete engineering coverage.
• Monospace font cross-platform consistency: The generic monospace keyword resolves to different physical fonts on different OS (Consolas on Windows, Menlo on macOS, Liberation Mono on Linux). Character widths vary slightly, which could affect URL/code alignment if precise tabular layout is attempted. No specific font-stack override is provided in the current spec.
• Line length readability: At wide viewports (>1200px), the fluid layout produces line lengths exceeding 100 characters — potentially straining readability. No max-width constraint exists in the current design, but one may be warranted for the "Wide" breakpoint (see Responsive Behavior table).