Content Contract

This page governs every docs page on this site. It is not a style suggestion — it is the contract each guide has to satisfy before it ships. It mirrors the honesty and data rules in AGENTS.md and CLAUDE.md; where this page and those files disagree, those files win.

If you are writing or reviewing a docs page, check it against all four sections below.

1. Honesty rules

Obsidian Jet is a compliance platform, so the words we use about compliance are load-bearing. Get them wrong and we imply a regulatory guarantee we do not make.

• Never write "compliant" or "FAA approved" about a trip, aircraft, crew member, or operator. The platform does not certify regulatory compliance.
• A compliance verdict is PENDING_VERIFICATION until authoritative data is verified. From seeded, modeled, or demo inputs the verdict is always PENDING_VERIFICATION — say exactly that. A suppressed gate always blocks; never describe it as passing.
• A certificate is a private attestation, not an approval. Describe certs as an immutable, append-only private attestation of what was checked and when — minted new on every change. Do not call a cert a "compliance approval", "clearance", or "FAA document".
• Do not promise outcomes ("guarantees a legal trip", "ensures compliance"). Describe what a surface checks and records, not what it certifies.

2. Fictional data only

No page may contain real operator data.

• No real operator names, customer names, or company data. Use invented operators and people.
• Tail numbers must be N0-series only — an N followed immediately by a zero, e.g. N0427X, N0710J. The FAA never issues a registration whose first digit is 0, so an N0-series tail can never collide with a real aircraft. Any tail you put in a page or a screenshot must be N0-series.
• Use the demo tenant for every example. Its fleet, trips, and people are fictional by construction, so anything you capture from it is safe to publish.

3. Screenshot standard

• Capture from the demo tenant only — never a real operator's console.
• Use the Geist theme (the shipped default look) so screenshots stay consistent across the site and do not go stale on a re-theme.
• Show N0-series tails and fictional names only — the demo tenant already satisfies this; do not paste real data into a demo screen before capturing.
• Crop to the surface being described. One screenshot should show one thing: the view, panel, or control the step refers to.

4. Page format

Every how-to page is one job, written as a task.

• One job per page. If a page is trying to teach two jobs, split it.
• Task-titled. The title is the job the reader wants to do, phrased as a task ("Build and send a quote", "Assign crew to a leg") — not a feature name.
• Numbered steps. The body is an ordered list of steps the reader follows in the product, in the order they happen.
• Cite the surface. Ground the page in the real shipped surface it documents; in landing pages, note the OS view key or product surface in an MDX comment ({/* view: ... */}) so the mapping stays traceable to the views registry.
• Link the record chain. When a step moves between records (RFQ → quote → trip → leg), show the in-product link, never "type in an id".