<!--
  Template: voice-guide.md
  Owner: operator (adopt, populate, then remove this HTML comment)
  Purpose: structural skeleton for an operator's voice-guide doc.
  Source: @stravica-ai/digital-operator-pa templates. See packages/engineering-pa/README.md.

  This template ships the SHAPE. Every `<!-- OPERATOR: … -->` marker is a
  spot where you replace the guidance with your own content. Do not
  invent extra sections without a reason — the shape is what makes voice
  guides mutually intelligible across operators.
-->

# Voice guide

**Status:** draft | in-review | live
**Last reviewed:** YYYY-MM-DD
**Owner:** operator name

## Who this voice belongs to

<!-- OPERATOR: replace with a one-line operator identity — the person or
brand whose voice this doc describes. Not the writer role's identity;
the human whose voice the writer reproduces. -->

## Voice principles

<!-- OPERATOR: replace with 4-8 positive-shape principles. Each principle
describes what the voice SOUNDS LIKE, not what it avoids. Bans belong in
banned-ai-tells.md. Examples of positive shape: "concrete before
abstract", "load-bearing verbs, plain nouns", "one clause of praise, then
the substance". Each principle carries an example that a writer can hold
in their head while drafting. -->

## Voice tests

<!-- OPERATOR: replace with a short checklist an author runs against a
draft before shipping. This is the runtime discipline — principles are
the aim, tests are the enforcement. Keep the list to items an author can
actually check in ~2 minutes. Examples: "read the opening aloud — does
it sound like something you would say?", "count the em-dashes — >3 per
paragraph means restructure", "any banned tell present? consult
banned-ai-tells.md". -->

## Structural rules

<!-- OPERATOR: replace with structural conventions specific to your voice.
Character counts, paragraph shape, section shape. Keep these soft — hard
bans are in banned-ai-tells.md. Examples: "LinkedIn posts land at 900-1200
chars", "articles open with a specific concrete situation, not a
generalised framing", "no headings above H2 inside articles". Anything
that's testable by a linter goes in the lint corpus, not here — this doc
is for the human. -->

## Register calibration

<!-- OPERATOR: replace with the judgment factors that shape register
across contexts. Peer vs cold, warm vs formal, replying vs originating.
Not prescriptive patterns — the factors a writer weighs and the
directions those factors push. Example: "replying to a peer you've
spoken to before: assume mutual context, drop the setup; replying to a
cold post from someone outside your industry: one line of context first".
This section teaches judgment, not rules. -->

## Reference material

<!-- OPERATOR: replace with links to the two companion docs and any
in-scope evidence. The voice guide is the METHOD; the reference docs are
the material.

- `banned-ai-tells.md` — hard bans and the taxonomy of AI-tells to
  avoid. This is the negative-shape complement to this doc's principles.
- `purpose.md` — the content-publishing mission. Every voice decision
  ultimately serves the mission; that's the doc a writer reads when a
  register decision doesn't have an obvious answer.

Add operator-specific evidence links if useful — past shipped posts, a
tell-evolution log, competitive references. -->

## How to update this doc

<!-- OPERATOR: replace with the operator's own synthesis discipline. The
default methodology, unchanged from the template, is:

**Synthesis, not append.** A new finding does NOT get bulleted at the
bottom of a section. Read the whole affected section, understand where
the finding fits into its argument, restructure the section so the new
finding is baked in rather than tacked on. If restructuring materially
changes the section's argument shape, flag for operator review — do not
silently rewrite the operator's voice.

**Sourcing.** Every restructure should reference the observation(s) that
prompted it in the commit message, so `git log -p voice-guide.md` remains
readable as a document evolution.

**Cadence.** This doc is reviewed on every distillation sweep. The
librarian is the maintainer; the operator is the final arbiter of voice.

Change this section only if the operator's synthesis process differs. -->