# AutoQA site copy standard

## Audience

Write for a cross-functional working team that includes:

- an upper-level manager;
- a product manager;
- software engineers;
- program and project managers;
- consultants and contractors;
- readers with different levels of AI-evaluation knowledge.

Assume the reader is capable but busy. Do not assume familiarity with the project’s internal vocabulary.

## Voice

Use direct, neutral business and engineering language.

The site should sound like a team explaining a proposal, not an author performing certainty, skepticism, or rigor.

### Prefer

- “This page lists the sources used in the proposal.”
- “The pilot may recommend stopping if the results do not support further investment.”
- “Evaluate each review claim separately.”
- “This is the main success criterion.”
- “The evidence does not yet establish this capability.”

### Avoid

- “the shortest honest version”
- “the receipts page”
- “claims, not vibes”
- “nothing here asks to be taken on trust”
- “the truth was learned cheaply”
- “the whole premise rests on”
- “convenient truth”
- “the moat”
- “each experiment kills or funds a component”
- “one fact frames all of it”
- “by construction” unless it names a specific enforced property
- “provably” unless a cited proof establishes the exact claim

Do not label the writing as honest, rigorous, exact, transparent, or evidence-based. Show those qualities through sources, caveats, definitions, and decision records.

## Page structure

Each main page should answer five questions in this order:

1. What is this page about?
2. Why does it matter?
3. What does the team need to know or decide?
4. What is known, unknown, and out of scope?
5. Where is the supporting detail?

Put the answer before the background.

## Layering

Use three layers of detail.

### Layer 1: Decision summary

Keep this visible by default. Use plain language, short paragraphs, and only the terms needed to make the decision.

### Layer 2: Working detail

Explain the process, tradeoffs, and ownership needed by PMs, engineers, and program leads.

### Layer 3: Reference material

Place research methods, claim IDs, schemas, statistical detail, legal analysis, and implementation specifications in linked documents or expandable sections.

Do not compress all three layers into one paragraph.

## Sentence and paragraph rules

- Prefer sentences under 25 words.
- Use one main idea per sentence.
- Keep paragraphs to two or three sentences.
- Avoid semicolon chains and nested parentheses.
- Replace em-dash chains with separate sentences or bullets.
- Define a specialist term the first time it appears.
- Do not introduce more than one new term in a sentence.
- Use a table only when the reader needs to compare items across the same dimensions.

## Headings and metadata

Use descriptive headings.

### Use

- “Summary”
- “What the pilot measures”
- “How a review is evaluated”
- “Known limitations”
- “Supporting evidence”

### Avoid

- “The whole case”
- “The honest unknown”
- “The position”
- “Bottom line” when a more specific heading is available
- slogan-style principle headings

Place dates, status, and version in a small metadata block. Do not append them to editorial subtitles.

Example:

> **Status:** Draft for pilot review  
> **Updated:** July 18, 2026

## Evidence language

State the claim first. Attach the evidence without interrupting the main sentence.

### Main page

> Published studies do not directly measure this task on the models proposed for deployment. The pilot therefore includes held-out in-house testing. [Evidence: GAP-01]

### Evidence page

Include the full source, retrieved passage, caveat, verification status, and decision weight.

Do not reproduce evidence-ledger detail in the main narrative.

## Uncertainty language

Use standard labels consistently:

- **Known:** supported by current evidence or direct measurement.
- **Working assumption:** reasonable but not yet measured in this setting.
- **Open question:** requires a decision or experiment.
- **Limitation:** reduces what can be concluded.
- **Out of scope:** deliberately excluded from the current decision.

Avoid dramatic labels such as “the honest unknown” or “the bet everything rests on.”

## Technical terminology

Use the plain term first, followed by the specialist term only where useful.

Examples:

- “agreement adjusted for chance (Cohen’s kappa)”
- “a held-out expert-labeled test set (gold set)”
- “send uncertain cases to a human (selective escalation)”
- “how error changes as the system handles more cases automatically (risk-coverage curve)”

After defining the term, use the shorter form consistently.

## Rewrite examples

### Summary subtitle

Before:

> The whole case, shortest honest version - 2026-07-15

After:

> **Status:** Draft  
> **Updated:** July 15, 2026

### Evidence introduction

Before:

> This is the receipts page. It exists so that no sentence anywhere on this site has to be taken on trust.

After:

> This page lists the sources used in the proposal, what was verified, and the limits on each source’s use.

### Pilot outcome

Before:

> A credible stop is a success of the process. It would mean we learned the truth cheaply.

After:

> The pilot may recommend stopping if the results do not support further investment. That is an acceptable outcome.

### Principle heading

Before:

> Claims, not vibes.

After:

> Evaluate individual claims.

### Experiment language

Before:

> First experiments, ordered; each kills or funds a component.

After:

> Initial experiments and the decisions they inform.

### Capability gap

Before:

> This is the moat and the first in-house measurement.

After:

> This capability is important to the product and has not yet been measured in this setting.

## Review checklist

Before publishing a page, confirm that:

- the first screen states the page’s purpose;
- the requested action is clear;
- each paragraph has one main point;
- specialist terms are defined or moved to supporting detail;
- rhetorical claims about honesty or rigor are removed;
- known facts, assumptions, open questions, and limitations are distinguished;
- evidence links support the exact sentence they follow;
- the main narrative can be understood without opening the evidence ledger;
- a reader can find deeper technical detail without it blocking the main path;
- the page ends with one next action.