Stakeholder-Specific Brief¶
Document — instantiates Code / Register Adaptation
Creates audience-specific versions of the same message for executives, frontline staff, customers, community members, regulators, students, or partners.
A Stakeholder-Specific Brief takes one source meaning and produces several audience-tailored versions of it — a version for executives, one for frontline staff, one for regulators, one for customers — each in the register, level of detail, and framing its audience needs. Its defining discipline is consistency across versions: because every version descends from the same locked source, none may make a different promise, quote a different deadline, or describe a different risk than the others. The hard part is not writing any single version but preventing them from drifting apart into materially different claims. It is a fan-out from one protected meaning to many audiences, not a mapping between vocabularies and not a definition list.
Example¶
A company discovers a data breach and must communicate it to four very different audiences at once. Its data-protection regulator needs a formal filing: the incident timeline, the specific data categories exposed, the legal basis, and the remediation steps, in precise regulatory language. Affected customers need a clear, calm email: what happened, whether their data is at risk, what they should do now, and how the company will help. The internal operations team needs a runbook: the containment status, the systems affected, and their action items. The executive team needs a one-page decision brief: business impact, legal exposure, and the choices in front of them.
A stakeholder-specific brief produces all four from a single locked fact base — the same incident date, the same categories of data, the same scope, the same remediation timeline. The registers differ enormously; the facts do not. What the mechanism exists to prevent is the catastrophe of drift: the regulator filing saying 40,000 records while the customer email implies far fewer, or the executive brief promising a fix date the ops runbook can't hit. The company treats the incident fact base as a single source of truth[n1] and derives every version from it, so tailoring never becomes contradiction.
How it works¶
- Lock the source first. Establish the shared, protected fact base — the claims, numbers, dates, obligations, and risks that must be identical everywhere — before writing any version.
- Model each audience. For every stakeholder, capture what they need to decide or do, their register expectations, and their stake — an executive wants implications, a regulator wants completeness, a customer wants reassurance and next steps.
- Fan out into versions. Write each version in its audience's register and detail level, foregrounding what that audience acts on while pulling every fact from the locked source.
- Cross-check for divergence. Line the versions up against the source and against each other; any place where two versions imply different promises, deadlines, or risk levels is a drift defect to fix, not a stylistic choice.
Tuning parameters¶
- Number of versions — few broad briefs vs. one per stakeholder group. More versions fit each audience better but multiply the drift surface and the upkeep.
- Source rigidity — how strictly all versions must trace to the locked fact base. High rigidity prevents contradiction but can make a version feel generic; some audience-genuine differences (a benefit that truly differs by group) are legitimate and must be distinguished from drift.
- Divergence tolerance — how much register and emphasis may vary before it counts as a substantive difference. Loose tolerance gives writers room but risks silent contradiction; tight tolerance is safe but stifling.
- Update propagation — whether a change to the source auto-flags every version for revision. Strong propagation keeps versions in sync as facts change but demands tooling and discipline.
When it helps, and when it misleads¶
Its strength is serving genuinely different audiences without lying to any of them: each stakeholder gets a message shaped for their decision, and the shared source keeps those messages mutually consistent — the reason the archetype says the mechanism "works when all versions remain consistent." It is the natural pattern whenever one event or policy must reach roles with different stakes and vocabularies at the same time.
Its signature failure mode is version drift: adaptation runs ahead of the source, and different audiences end up holding materially different claims — different deadlines, eligibility rules, risk descriptions, or commitments — the precise failure the archetype names. The classic misuse is telling regulators one thing and customers another, whether by sloppiness or design; tailoring becomes a cover for inconsistency. A subtler trap is over-reassuring one audience (softening a risk for customers that the regulator filing states plainly), which is drift dressed as tone. The guarding discipline is to keep a single locked source visible behind every version, cross-check the versions against it and each other, and treat any divergence in substantive claims as a defect rather than a permissible difference in voice.
How it implements the components¶
source_message_or_meaning— it makes the protected source explicit and load-bearing: a single locked fact base every version must trace back to, which is what keeps tailoring from becoming contradiction.audience_community— it models each stakeholder group's needs, stakes, and register expectations so every version foregrounds what that audience must decide or do.code_or_register_choice— it selects a distinct register and detail level per version (formal filing, calm customer email, terse ops runbook, executive one-pager) around the shared facts.
It builds versions of a message, not references to a vocabulary: cataloguing and defining one community's specialist terms (jargon_inventory) is Jargon Glossary's job, and mapping one group's words to another's with match-type flags (translation_mapping) belongs to Crosswalk Glossary — those twins operate on vocabularies, while this brief fans one source meaning out to many audiences.
Related¶
- Instantiates: Code / Register Adaptation — supplies the multi-audience fan-out that keeps one source meaning consistent across role-specific versions.
- Sibling mechanisms: Community Language Review · Crosswalk Glossary · Expert-to-Public Translation · Jargon Glossary · Multilingual Switching Protocol · Plain-Language Translation · Register-Shift Guideline · Teach-Back Comprehension Check
Editorial Notes¶
Form Classification¶
Form family: Communication, Facilitation & Learning
Rationale: Stakeholder-Specific Brief operates as a designed message, facilitated interaction, ritual, or learning activity that changes shared understanding because it creates audience-specific versions of the same message for executives, frontline staff, customers, community members, regulators, students, or partners.
Independent corroboration: The frozen evidence defines Stakeholder-Specific Brief as 'Creates audience-specific versions of the same message for executives, frontline staff, customers, community members, regulators, students, or partners', so its operative form is Communication, Facilitation & Learning.
Nearest alternative: Representation, Specification & Plan — Stakeholder-Specific Brief includes features of a static representation, map, specification, schema, or prospective plan that externalizes information, but its defining operation is a designed message, facilitated interaction, ritual, or learning activity that changes shared understanding.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Communication & Media Studies
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Audience-specific versions are strategic communication segmentation.
Related originating lineages:
- Organizational & Management Science — Roles determine needed detail.
- Rhetoric — Content and tone adapt to audience.
Review resolution: The blind reviewers agree that communication_media_studies is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain convergent because the combined evidence shows independent disciplinary development. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A single source of truth (SSOT) is the practice of holding one authoritative record of a fact that all downstream artifacts derive from, so copies cannot silently disagree. It is the structural safeguard against the version drift this mechanism is most exposed to. ↩