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:

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 — two binaries on the distribution copy: «would YOU click?» and «who forwards this to a colleague, and why?»).

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.

### 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.]