# Decision Communication Protocol

**LPM reusable knowledge object v1.0**  
**Primary layers:** Decision Architecture, Communication Architecture, Information Ecology, Governance Architecture, AI Amplification  
**Last reviewed:** 2026-06-24

## Purpose

The Decision Communication Protocol defines how a decision moves from authority to enterprise behavior. It prevents decisions from being trapped in meetings, buried in chat, distorted by summaries, or executed without a durable record.

## Core idea

A decision is not complete when it is made. It is complete when the right audience understands what changed, what action is required, where the durable record lives, and when the decision must be reviewed or superseded.

## Core principles

- **A decision is not complete until it is communicated:** A decision made in a forum, thread, hallway, dashboard review, or AI workflow does not become operational truth until the right audiences receive the right message through the right channel.
- **Communication must separate signal from noise:** Decision communication must clearly distinguish final decisions, recommendations, drafts, escalations, exceptions, reversals, and informational updates.
- **The decision record is the source of truth:** Slack, Teams, email, meeting notes, and AI summaries may distribute the decision, but the durable record must live in the decision log or approved system of record.
- **Authority must travel with the message:** Recipients should know who made the decision, what authority they had, what evidence was used, what changed, and what action is required.
- **Supersession is mandatory:** When a decision changes, expires, is reversed, or is overridden, the old decision must point to the new decision and the new message must state what changed.
- **AI can assist, not quietly decide:** AI may draft, summarize, route, translate, or detect affected groups, but human review is required for material, high-risk, external, workforce-impacting, or control-impacting decisions.
- **Communication creates accountability:** Every decision message must define action owners, expected behavior change, timing, evidence of completion, and escalation path.

## Required fields

| Field | Definition | Required |
|---|---|---|
| Decision ID | Unique identifier that connects the communication to the decision log, matrix, evidence pack, and downstream work items | Yes |
| Decision title | Plain-language decision name that people can recognize in search, dashboards, and communication channels | Yes |
| Decision status | Draft, recommendation, final, approved, rejected, escalated, exception, superseded, reversed, expired, or under review | Yes |
| Communication type | Decision announcement, change notice, supersession notice, escalation notice, exception notice, implementation notice, or learning notice | Yes |
| Decision maker / authority | Person, role, council, control body, or executive with the right to make or approve the decision | Yes |
| Communication owner | Person accountable for message clarity, routing, evidence links, confirmation tracking, and system-of-record update | Yes |
| Affected audience | Teams, functions, roles, vendors, customers, systems, AI agents, control groups, or executives affected by the decision | Yes |
| Audience obligation | Inform only, acknowledge, execute, stop, review, approve, challenge, escalate, or update system of record | Yes |
| Message summary | One-sentence explanation of what was decided and why it matters | Yes |
| What changed | Specific change in policy, priority, scope, ownership, system behavior, workflow, control, risk posture, or execution plan | Yes |
| Why now | Trigger, evidence, incident, strategic change, dependency, regulatory need, AI signal, or governance event that caused the decision | Recommended |
| Evidence link | Evidence checklist, dashboard, report, data source, model evaluation, risk record, customer signal, or meeting artifact supporting the decision | Yes |
| Action required | What recipients must do, by when, and where completion is captured | Yes |
| Effective date | Date the decision becomes active, including staged rollout or transition rules | Yes |
| Expiration / review date | Date the decision should be reviewed, renewed, superseded, or retired | Yes |
| System of record | Decision log, Jira, ServiceNow, Confluence, SharePoint, GRC, CRM, HRIS, data catalog, model registry, or Lapemo object | Yes |
| Distribution channel | Executive memo, Teams, Slack, email, meeting readout, portal, in-app alert, policy notice, vendor notice, or customer communication | Yes |
| Confirmation method | Read receipt, acknowledgement, workflow status, control attestation, owner update, implementation evidence, or exception response | Required for material decisions |
| Escalation path | Where unresolved questions, conflicts, blocked implementation, risk objections, or ownership gaps are routed | Required when material |
| AI involvement | None, AI draft, AI summary, AI routing, AI translation, AI audience detection, AI evidence summary, or AI monitoring | Yes |
| Human review rule | Required approval before AI-assisted or automated communication is released | Required when AI-assisted |
| Supersession link | Prior decision replaced by this one, or future decision that replaces this one | Required when applicable |
| Retention rule | How long the message, evidence, confirmations, and decision record are retained | Yes |
| Version | Artifact version, owner, last reviewed date, and change history | Yes |

## Protocol flow

| Step | Requirement |
|---|---|
| 1. Classify the decision | Determine whether the message is a draft, recommendation, final decision, exception, escalation, change, reversal, or supersession. |
| 2. Verify authority | Confirm the decision maker has the right to decide under the decision rights model and escalation map. |
| 3. Validate evidence | Attach the minimum evidence needed to support the decision and flag stale, missing, or low-confidence sources. |
| 4. Identify affected audiences | Map who must know, who must act, who must approve, who may challenge, and which systems or AI agents are affected. |
| 5. Draft the message | State what was decided, why, what changed, what action is required, when it takes effect, and where the record lives. |
| 6. Review for risk | Apply human review for material decisions, workforce impact, customer impact, compliance impact, AI output, or external communication. |
| 7. Publish through approved channel | Send through the correct channel based on audience, severity, authority, and retention needs. |
| 8. Confirm receipt or action | Capture acknowledgement, owner update, workflow status, control attestation, or implementation evidence. |
| 9. Store the durable record | Update the decision log and link evidence, owner, action items, escalation path, and supersession rules. |
| 10. Monitor and supersede | Track questions, exceptions, implementation drift, new evidence, AI impact, and replacement decisions. |

## Communication types

| Type | Use when | Minimum message content |
|---|---|---|
| Decision announcement | Final decision that changes direction, ownership, scope, priority, policy, process, system behavior, or AI use | Decision ID, authority, evidence, action required, effective date, system of record |
| Decision recommendation | Proposed direction not yet approved by the final decision maker | Status label, recommendation owner, evidence, open questions, decision deadline |
| Change notice | Approved change to a previously communicated decision | What changed, why, affected groups, implementation date, prior decision link |
| Supersession notice | New decision replaces, reverses, or expires an old decision | Old decision ID, new decision ID, reason, transition instructions, owner |
| Escalation notice | Decision cannot be resolved at current authority tier | Issue, options, evidence, blocked owner, required decision maker, deadline |
| Exception notice | Approved deviation from policy, standard, decision, control, or operating rule | Exception owner, risk tier, control owner, expiration date, review trigger |
| Implementation notice | Decision is moving into execution and requires action by teams or systems | Action owner, due date, work item links, change window, support path |
| Learning notice | Post-decision lesson, postmortem, control update, or operating model adjustment | Finding, implication, artifact update, owner, review date |

## Three company versions

| Scale | Profile | Primary job | Recommended model | Common failure pattern | Minimum implementation |
|---|---|---|---|---|---|
| 500+ employees | Scaling company | Prevent founder-led, hallway, Slack, or meeting-only decisions from becoming operating confusion. | Create a simple decision announcement standard, one decision log, named communication owner, and required effective-date/action-owner fields. | Decisions announced in meetings but not documented; teams receive different versions; chat becomes source of truth; executives override without supersession. | Decision ID, decision maker, affected teams, action owner, effective date, decision log link, Teams/Slack/email announcement, review date. |
| 5,000+ employees | Scaled enterprise | Coordinate decisions across functions, platforms, governance groups, vendors, and transformation programs. | Use defined communication types, audience obligations, approval rules, escalation paths, and system-of-record mappings for material decisions. | Functions interpret decisions differently; governance decisions do not reach delivery teams; system changes are communicated separately from business decisions. | Authority tier, communication type, risk tier, evidence pack, affected functions, official channels, acknowledgement method, supersession link, control owner review. |
| 10,000+ employees | Enterprise ecosystem | Control decision communication across geographies, business units, regulatory domains, AI systems, external partners, and agents. | Operate decision communication as an enterprise control with role-based routing, human-reviewed AI assistance, audit retention, impact analysis, and decision lineage. | Regional/local variants conflict; external/vendor communication diverges from internal direction; AI summaries spread unapproved interpretations; old decisions remain discoverable. | Enterprise decision bulletin, policy/control mapping, legal/regulatory review, external communication routing, role-based distribution, AI review rule, audit trail, multilingual/localization controls. |

## Channel rules

| Channel | Best use | Rule |
|---|---|---|
| Chat / Teams / Slack | Fast coordination, quick awareness, clarifying questions, implementation nudges | Not the final source of truth for material decisions; link to the decision record. |
| Email / memo | Formal announcement, executive direction, broad cross-functional communication | Must include decision ID, effective date, action required, and link to durable record. |
| Meeting readout | Communicating what was decided in a forum or council | Must be converted into a decision log entry; meeting notes alone are not enough. |
| Work system | Execution changes, backlog sequencing, task ownership, status updates | Decision rationale should link back to the decision record and evidence. |
| Knowledge base / portal | Durable policy, process, operating model, standards, and onboarding content | Must show version, owner, last reviewed date, and supersession link. |
| GRC / control system | Risk decisions, policy exceptions, audit findings, regulatory obligations, controls | Must include control owner, retention, evidence, and review/expiration trigger. |
| In-app / workflow notification | Actionable operational updates where users must act in a system | Must avoid summarizing more authority than approved; link to official decision. |
| External communication | Customer, vendor, partner, regulator, or public communication | Requires approved external communication owner and applicable legal/compliance review. |

## Required message spine

- **Decision:** What was decided?
- **Authority:** Who had the right to decide?
- **Evidence:** What facts, signals, risks, or constraints supported it?
- **Change:** What changes for the affected audience?
- **Action:** What must happen now, by whom, and by when?
- **Record:** Where does the durable decision live?
- **Review:** When will this decision be reviewed, expired, or superseded?

## Scoring logic

| Score | Maturity description |
|---|---|
| 0 | Decisions are communicated informally through meetings, chat, or executive side channels with no durable record or clear audience obligation. |
| 1 | Some decisions are announced, but messages lack authority, evidence, action owners, effective dates, or supersession rules. |
| 2 | Major decisions are communicated through standard channels, but routing, confirmation, AI use, and system-of-record linkage are inconsistent. |
| 3 | Material decisions have defined communication types, audience obligations, evidence links, confirmation methods, decision log updates, and escalation paths. |
| 4 | Decision communication is governed as an enterprise capability with AI-assisted routing, human review controls, supersession lineage, action confirmation, and executive visibility. |

## Validation rules

- Decision communication cannot be marked final unless a decision ID, decision maker, authority tier, evidence link, effective date, and system of record are present.
- Any message using AI assistance must include an AI involvement value and human review rule before publication.
- A material decision must define affected audience, audience obligation, action required, and confirmation method.
- A superseded, reversed, expired, or changed decision must link to the prior decision and the replacement decision.
- External, customer-impacting, workforce-impacting, compliance-impacting, or high-risk AI decisions must require human approval before distribution.
- Chat, email, and meeting notes are valid distribution channels but not sufficient systems of record for material decisions.
- Every decision message must include an escalation path for questions, blocked implementation, ownership gaps, or risk objections.
- Status labels must be visible. Draft, recommendation, final, exception, and superseded messages cannot look the same.

## AI prompts for reusable skill

| Prompt | Instruction |
|---|---|
| Classify communication | Classify this decision message as draft, recommendation, final, change notice, supersession notice, escalation notice, exception notice, implementation notice, or learning notice. Explain why. |
| Find missing fields | Review this decision communication and identify missing authority, evidence, audience, action, effective date, system-of-record, confirmation, escalation, AI-review, or supersession fields. |
| Rewrite for clarity | Rewrite this decision communication so recipients clearly understand what was decided, who decided, why, what changed, what action is required, where the record lives, and when it will be reviewed. |
| Detect risk | Identify communication risks in this decision message, including unclear authority, weak evidence, ambiguous audience, hidden AI involvement, missing human review, or poor supersession linkage. |
| Create announcement | Create a decision announcement from the decision log, evidence checklist, owner map, and escalation map. Use the correct channel and audience obligation. |
| Supersession check | Determine whether this decision replaces, reverses, or modifies an earlier decision. If so, create the supersession notice and update required links. |

## Mapping rules

| Connected object | Mapping rule |
|---|---|
| Decision Rights Model | Validate authority, decision tier, role separation, and whether the communication can say final, recommendation, or escalation. |
| Decision Rights Matrix | Identify the accountable decision maker, consulted roles, approval roles, and impacted functions. |
| Decision Log | Store the durable record and link communication history, evidence, actions, supersession, and review dates. |
| Evidence Checklist | Attach evidence sources, freshness, confidence, and human review status to the decision message. |
| Escalation Map | Route unresolved objections, blocked implementation, ownership gaps, or risk events to the right authority tier. |
| Ownership Map | Identify business owner, execution owner, control owner, data owner, platform owner, and communication owner. |
| Meeting Architecture | Convert meeting outcomes into official decision communication and prevent meeting notes from becoming hidden truth. |
| AI Initiative Owner Register | Apply to AI initiative decisions, owner changes, model risk, human review requirements, and launch gates. |

## Implementation controls

| Control | How it should work |
|---|---|
| Audience routing | Route by role, function, geography, system, risk tier, ownership, and action obligation instead of blasting all employees. |
| Human approval | Require accountable human review for material, high-risk, AI-assisted, external, compliance, workforce, or customer-impacting messages. |
| Decision lineage | Maintain links between the original decision, message, evidence, implementation actions, exceptions, escalations, and superseding decisions. |
| Searchability | Use decision IDs, titles, tags, owners, dates, and status labels so people and AI can retrieve the correct current decision. |
| Stale communication detection | Flag old decisions, outdated wiki pages, duplicated announcements, and unlinked summaries that conflict with the current decision record. |
| Confirmation tracking | Track acknowledgement, implementation status, exception response, control attestation, and unresolved objections. |
| AI-safe summaries | AI summaries must cite the decision record and cannot introduce new obligations, owners, dates, or interpretations without approval. |

## Decision announcement template

- Decision: [what was decided]
- Status: [final / recommendation / escalation / exception / superseded]
- Authority: [decision maker, role, council, or control body]
- Why: [evidence, trigger, risk, dependency, or strategic reason]
- What changes: [scope, ownership, process, system, policy, control, priority, or AI behavior]
- Action required: [who must do what by when]
- Effective date: [date and transition rule]
- System of record: [link to decision log]
- Questions or escalation: [owner, forum, SLA, channel]
- Review or expiration: [date and owner]

## Supersession notice template

- This decision supersedes: [prior decision ID and title]
- New decision: [new decision ID and title]
- Reason for change: [new evidence, changed constraint, incident, control issue, strategy change, or AI signal]
- What remains true: [unchanged guidance]
- What is no longer true: [retired guidance]
- Required action: [update, stop, continue, reverse, communicate, or archive]
- Owner and review date: [accountable owner and next review]

## Website and Lapemo ingestion notes

- Website artifact: publish as a downloadable PDF, editable DOCX, and web page summary with a short intake form.
- Knowledge object: maintain a canonical JSON object with fields, validation rules, scoring, prompts, mappings, version, owner, and last reviewed date.
- Lapemo onboarding: use the object to ingest decisions, classify communication patterns, detect missing authority/evidence, and recommend decision-log updates.
- AI scaling: AI should draft and route decision communication only from approved decision records and must preserve source links, status labels, and human review requirements.
- Governance: updates should be suggested automatically when decisions conflict, age out, lose owners, or are superseded, but human approval should publish the new version.