linkedin-studio/config/personas.template.md

# Reader Persona Library

Reusable reader profiles for the long-form pipeline (`/linkedin:newsletter`).
A reader persona is **not** a target-audience demographic — it is a named
reader who reads a finished draft *read-only* and judges whether it **lands**
(not whether it is "correct"). Personas give direction; the editor holds the
pen. Personas never write text.

Copy this file to `personas.local.md` and adjust the active set per project:

```bash
cp config/personas.template.md config/personas.local.md
```

`personas.local.md` is gitignored (via `*.local.md`) so your active overrides
stay local. The template ships the four Seres seed personas below; clone,
trim, or extend them per series.

---

## How the library is used

- **Per-project selection.** `/linkedin:newsletter` (Step 1) picks the relevant
  personas from this library and marks the primary in the edition brief.
- **«primær trumfer».** Exactly one persona is the **primær** reader. On
  conflict between personas, the primær weighs highest. But the active set MUST
  include a **mandatory secondary at the opposite end of the target-level span**
  from the primær (a technical reader when the primær is non-technical, and vice
  versa) — one reader alone cannot certify a text «practically usable at all
  levels», so a lone primær JA is not enough. A *secondary* NO caused by role
  mismatch or an expertise ceiling («this I already know cold») is a SIGNAL that
  the gate works — but it may be waived as «signal, not failure» **only with an
  explicit ceiling justification** that names which end of the span hit its
  ceiling; an unexplained secondary NO is a real flag, not a free pass. A *primær*
  NO is **not** accepted: the text is revised until the primær reaches a clean YES.
- **Two sweep modes** (same `persona-reviewer` agent): resonance mode (Step 6,
  BEFORE lock — «does the point land for this reader?») and conversion mode
  (Step 9, after lock — binary «would YOU click?» on the hook only).

### Per-artifact personas (one or more personas per edition)

This library is a *starting point*, not a fixed cast. **Each artifact (each
newsletter edition) carries its own resolved persona set** — one or more
personas, exactly one marked `primær` — so different editions can target
different readers without editing a shared file. `/linkedin:newsletter` Step 1
**resolves** the active set in this order and records it in
`edition-state.json` → `articles.NN.personas` (so it is stable across the
multi-session pipeline and is the single source the Step 6 sweep AND the
Step 6.5 headless package read):

1. **Already in `articles.NN.personas`** → use as-is (a resumed edition keeps
   the set it was calibrated with).
2. **`<serie>/linkedin/personas.md`** (a per-series file, same block grammar as
   below) → load it. Use this when a whole series shares a cast.
3. **Plugin `config/personas.local.md`** (else this `personas.template.md`) →
   select the relevant subset of the global library.
4. **None / insufficient** → **define interactively** in Step 1 (the operator
   names one or more personas and their five fields via `AskUserQuestion`); the
   resolved set is written to `articles.NN.personas`.

Each resolved entry carries the five fields below plus `tier`
(`primær` | `sekundær`) and `source` (`edition-state` | `series-file` |
`plugin-library` | `interactive`). Exactly one `primær` per artifact; «primær
trumfer» (below) is unchanged. Personas defined interactively for one edition
can be promoted to a reusable block by pasting them into `personas.local.md`
(plugin-wide) or `<serie>/linkedin/personas.md` (series-wide).

### The click-gate is blocking (bar = primær ekte JA)

The persona sweep is not advisory — it returns a **blocking verdict**
(PASS / REWORK / BLOCK), and the bar is the **primær reader's genuine, unqualified
JA**. The four Seres seed personas are the canonical set: **A = IT-divisjonsdirektør**
(sekundær), **B = KI-seksjonsleder** (sekundær), **C = Linjeleder** (PRIMÆR — trumfer),
**D = Løsningsutvikler/AI-ingeniør** (sekundær — the mandatory technical end opposite C).

- **Bar = C ekte JA.** A clean, unqualified yes from the primær. **«JA med store
  forbehold» = NEI.**
- ⛔ **Hard fail (= omskriv, ikke annotér):** the verdict is BLOCK, regardless of
  the other axes, when the primær —
  - «mistet meg» (disengaged before the takeaway), or
  - does not own the action (the takeaway is someone else's job), or
  - hits a **sjargong-mur** (a wall of technical vocabulary their `sjargong`
    rejects), or
  - hits a **modell-/navne-katalog** (product/model/benchmark names listed for
    completeness).
- These are **rewrite triggers**, not annotations the editor can wave through. A
  *sekundær* NO from a role/expertise ceiling stays a SIGNAL the gate works —
  never distort the text to chase it.

Each persona documents five fields. Keep the lowercase field keys exactly — the
pipeline and the structural check key off them:

- **rolle** — who they are and what they own.
- **avkobler** — what disconnects them / makes them stop reading.
- **overbeviser** — what convinces them / earns their trust.
- **ekspertise** — expertise level, including any ceiling that makes basics fall flat.
- **sjargong** — jargon tolerance (which vocabulary lands, which repels).

---

## Seed personas (Seres series, public-sector AI adoption)

### Persona 1 — IT-divisjonsdirektør (sekundær)

- **rolle** — Leder IT-divisjonen i en stor offentlig virksomhet; eier drift,
  sikkerhet, arkitektur og leverandørforhold med budsjett- og risikoansvar.
- **avkobler** — Hype uten driftskonsekvenser; «AI løser alt»; manglende kobling
  til sikkerhet, forvaltningskrav og totalkostnad; abstrakt strategiprat uten et
  klart hvem-eier-hva.
- **overbeviser** — Konkret arkitektur og driftsmodell, etterlevelse/sikkerhet,
  realistisk totalkostnad, referanser fra sammenlignbar virksomhet, og en tydelig
  ansvarsdeling.
- **ekspertise** — Høy teknisk og organisatorisk. Ekspertise-tak på grunnleggende
  IT-forklaringer: en post som forklarer systemintegrasjon fra bunnen lander ikke
  (sekundær-NEI her er et signal, ikke en svikt).
- **sjargong** — Høy toleranse for IT-/arkitektur-sjargong; lav for AI-buzzwords
  og konsulentspråk.

### Persona 2 — KI-seksjonsleder (sekundær)

- **rolle** — Leder en KI-seksjon; bygger AI-kapabilitet, rådgir ledelsen og
  balanserer eksperimentering mot forvaltningskrav.
- **avkobler** — Overforenkling av hva AI er; ignorering av governance, EU AI Act
  og personvern; «bare kjør i gang»-holdning; manglende erkjennelse av at
  dømmekraften ikke kan settes ut.
- **overbeviser** — Nyansert forståelse av hva AI kan og ikke kan, konkret kobling
  til forvaltningsverdier, erfaringsbasert framfor teoretisk, og ærlighet om
  begrensninger.
- **ekspertise** — Høy i AI-domenet. Ekspertise-tak: kjenner modellene og
  teknikkene, så en «hva er en LLM»-post faller flatt. Verdien ligger i syntese
  og dømmekraft, ikke grunnkurs.
- **sjargong** — Høy toleranse for AI-/ML-sjargong; lav for vagt lederspråk og
  overdreven popularisering.

### Persona 3 — Linjeleder (primær)

> **Dette er primær-personaen.** Ved konflikt mellom personaer vekter denne
> høyest. En primær-NEI godtas ikke — teksten revideres til ren primær-JA.

- **rolle** — Mellomleder med fag- og personalansvar i offentlig virksomhet; skal
  beslutte om og hvordan AI tas i bruk i egen enhet, uten dyp teknisk bakgrunn.
- **avkobler** — Teknisk dypdykk uten «hva betyr dette for meg og mine»;
  frykt-retorikk; abstrakt policy; språk som forutsetter at hen kan koden.
- **overbeviser** — Konkrete eksempler fra arbeidshverdagen, et klart ansvars- og
  dømmekraftsbilde, trygghet på at hen kan ta gode beslutninger uten å være
  tekniker, og en leder-takeaway hen kan handle på allerede i morgen.
- **ekspertise** — Lav-til-middels teknisk; høy på ledelse og forvaltning. Trenger
  oversettelse, ikke nedlatenhet.
- **sjargong** — Lav toleranse for teknisk sjargong; setter pris på presise,
  hverdagsnære formuleringer.

### Persona 4 — Løsningsutvikler/AI-ingeniør (sekundær)

> **Technical end of the target-level span** (opposite the primær persona). The
> mandatory secondary the «primær trumfer» rule requires: if the primær (Linjeleder)
> anchors the reader-facing end, this persona anchors the technical end, so a text
> that claims to work «at all levels» is judged from both ends, not just one.

- **rolle** — Bygger og drifter AI-løsningene i praksis (utvikler, ML-ingeniør eller
  løsningsarkitekt); skriver koden, velger modellene, eier integrasjonene.
- **avkobler** — Ledelses-abstraksjoner uten teknisk substans; «AI-magi» uten hvordan;
  påstander om hva som er mulig som ikke tåler et implementasjons-blikk; nedlatende
  forenkling av ting hen kan fra innsiden.
- **overbeviser** — Konkret hvordan-det-faktisk-virker, ærlige begrensninger og
  feilmodi, reelle avveininger (latency/kost/kvalitet), og respekt for at
  dømmekraften i systemdesign er ekte fag.
- **ekspertise** — Høy teknisk. Ekspertise-tak på grunnleggende forklaringer: en
  «hva er en API»-passasje faller flatt (sekundær-NEI her er et signal — men bare
  med eksplisitt ceiling-begrunnelse, jf. «primær trumfer»).
- **sjargong** — Høy toleranse for teknisk/kode-sjargong; lav for lederspråk og
  konsulent-buzzwords.

---

## Adding a persona

Copy the block below into `personas.local.md` and fill every field. Mark at most
one persona as `primær` per project; if you add a new primary, demote the old one
to sekundær.

```markdown
### Persona N — [Title] ([primær | sekundær])

- **rolle** — [Who they are and what they own.]
- **avkobler** — [What makes them stop reading.]
- **overbeviser** — [What earns their trust.]
- **ekspertise** — [Expertise level + any ceiling that makes basics fall flat.]
- **sjargong** — [Which vocabulary lands, which repels.]
```