Brand & Style Guide

This guide is the source of truth for how Cheetah looks and sounds, both in the product surface and in these docs. It exists so that anyone — engineer, partner, contributor — can produce work that feels like it belongs to Cheetah without guessing.

It's intentionally focused. We're an alpha-stage company; this guide will grow as our visual language settles. Don't treat it as exhaustive — treat it as a starting point and add to it.

Brand at a glance

Cheetah is an automated quality inspection platform for advanced manufacturing. Cobot, industrial 3D scanners, proprietary analysis software — integrated for dimensional, surface, weld, and electronic inspections on the factory floor, not in a metrology lab. We ship a precision instrument. The product feels engineered because it is. Everything we make — the hardware, the operator applications, the API, this documentation — should carry that same posture: confidently engineered, technically literate, and not overly self-serious.

The visual language draws from two intentional references:

• Old-school space-age instrument panels — viewfinder brackets, numbered indicators, telemetry strips, monospace HUD readouts. Apollo-era technical drawing meets modern engineering UI.
• Synth-wave neon — the cheetah-teal and cheetah-pink palette, saturated to glow against deep slate backgrounds. Energy without warmth.

The combination — Mission Control — feels uniquely Cheetah and shouldn't read as either pure retro or pure techno.

Sections

• Palette — colors, tokens, usage rules
• Typography — type system, sizes, weights
• Voice & Writing — tone, conventions, how to write docs

Core principles

These apply everywhere, not just to docs.

1. Be technically literate, not technically posturing

We write for engineers who already understand robotics, APIs, and Python. We don't explain what an HTTP request is. We don't soften the technical content with marketing prose. We don't promise that "anyone can integrate Cheetah in 5 minutes" — we explain what 5 minutes actually buys you.

2. Show the version

Every page, every API call, every UI screen should be honest about what version of Cheetah it applies to. This is especially important in alpha. The applies_to banner at the top of docs pages, the version stamp in the footer, the info.version in the OpenAPI spec — they're all part of the same commitment.

3. Restraint with neon

The cheetah-teal and cheetah-pink palette is built to go very saturated at the bright end (teal-400 = #0cffff, electric cyan). Use those neon values for specific, intentional moments: interactive elements, status indicators, the alpha banner, links. Don't wash the whole surface in neon — the contrast against deep slate is the point.

4. Treat docs as a product

The documentation isn't a deliverable, it's a product surface clients interact with. Same care as the UI: thoughtful information architecture, considered typography, real attention to the experience. If you're tempted to ship a doc with a "TODO" or "coming soon," reconsider — either commit to the page or remove it from nav.

5. Build for AI consumption

Clients will lean on AI tools (Claude, Cursor, ChatGPT) to build integrations with Cheetah. The docs are designed to be ingested by those tools: clean Markdown is the source of truth, every page is fetchable as Markdown, the AGENTS.md file provides an integration directive. When writing, optimize for being a useful AI input, not just a human read.