Writing Style

Public documentation voice, wording, and readiness-label rules.

Writing Style

Start with the answer.

Write public docs as build guidance. Make every page useful to an implementation team.

Voice

Use plain words. Prefer short sentences. Use active voice.

Name the owner, state, and next required proof.

Use concrete readiness labels:

  • Go for signed-off implementation start.
  • Not yet started for product runtime signoff.
  • No for production app deployment or production app DNS signoff that has not happened.
  • blocking, later wave, and deferred for wave state.

Punctuation

Use standard punctuation.

Do not use the long dash character.

Do not use semicolon characters.

Use commas, periods, colons, parentheses, and short hyphens where they make the sentence easier to read.

Accuracy

Do not describe runtime code as built unless it exists.

Do not describe deployment as ready unless the release path, health checks, secrets, connectivity, audit spine, and rollback rules are verified.

Do not describe production app DNS as ready until records, targets, proxy mode, owner, approval path, and rollback are signed off.

If a fact is missing, state what is missing and what would confirm it.

Secret Handling

Name secret keys only when the key name is part of the contract.

Never publish raw secret values.

Never publish private connection strings.

Never move Cloudflare control-plane credentials into runtime docs as app inputs.

Structure

Each page should answer these questions when relevant:

  • What is the current decision?
  • What is fixed?
  • What is still missing?
  • What must the implementation prove?
  • Which source docs are canonical?

Tables are useful for wave order, runtime env mapping, and fixed contracts.

Bullets are useful for requirements and blocker lists.

Use paragraphs for decisions and warnings that need context.

Language To Avoid

Avoid filler, launch-copy phrasing, vague hype, and generic claims about quality.

Avoid contrast templates that make the sentence longer without adding proof.

Prefer exact wording:

  • Say “product runtime implementation has not started. Shell probe exists”.
  • Say “Bucket Lock is enabled, but runtime audit projection is not proven”.
  • Say “mutating routes must fail closed”.
  • Say “Cloudflare control-plane secrets are runtime-forbidden”.

Do not make the docs sound broader than the contract.