Large People ModelHuman Operating Architecture

Template & Working Tool · LPM Knowledge Object

Decision Communication Protocol

A protocol for communicating decisions with context, owner, evidence, commitment, and follow-up path.

Protocolv1.0.0DecisionsCommunication

Problem it solves

Slow, unclear, or reversible decisions create execution drag.

Who should use it

Decision owners, chiefs of staff, and cross-functional teams

Estimated time

30–45 minutes for a first working session

Three-Step Quick Start

1Define what counts as a decision.
2Use the protocol for material tradeoffs and commitments.
3Publish decisions where affected teams can find and act on them.

Open the public PDF

The PDF action is direct and public. All available packaged formats are also public and require no registration.

Object Overview

What this object is

Decision Communication Protocol is a reusable LPM knowledge object that helps organizations ensure decisions become traceable commitments rather than scattered updates or meeting memories. It gives teams a structured way to make decisions visible, owned, and reviewable.

Why it matters

As companies scale AI, weak operating-model structures become amplified. This object helps prevent ai creates recommendations faster than the organization can responsibly decide. by defining communication, escalation, and decision boundaries.

Layer Alignment

Where it fits in LPM

Primary LPM layer

Decision Architecture

Defines how decisions are made, who makes them, what information supports them, and how decisions create traceable commitments.

Supporting layers

Communication

Why it belongs here

This object sits in Decisions because it turns decisions into a concrete artifact with owners, evidence, review cadence, and action paths.

Weakness it exposes

AI creates recommendations faster than the organization can responsibly decide.

Usage

How to use it

1Select the business area, workflow, platform, or AI initiative being assessed.
2Identify the accountable owner and required participants.
3Complete the working DOCX version with the team.
4Use the PDF as the reference guide.
5Capture decisions, gaps, risks, and owners.
6Convert outputs into backlog items, governance actions, or Lapemo onboarding inputs.
7Review on the recommended cadence: Monthly in decision forums.

File Formats

Which file should you use?

PDF

Executive/reference version

Best for education, pre-read, sharing, and workshops.

DOCX

Editable working artifact

Best for facilitation, implementation, and client or internal completion.

Markdown

Website/source version

Best for publishing, documentation, and content reuse.

JSON

Structured knowledge object schema

Best for future Lapemo ingestion, scoring, validation, prompts, and workflows.

Outputs

What the organization should expect

Clearer ownership

Better decision traceability

Reduced ambiguity

Evidence-backed conversations

Better AI readiness

Better handoff into Lapemo later

Decision communication protocol

Commitment record

Follow-up responsibilities

Advanced specification, company-size variants, and future product notes

Company Scale

How this changes by company size

500+ employees

Use this to create baseline clarity.

Focus on named owners, simple governance, and reducing informal workarounds.

Included in this object.

5,000+ employees

Use this to standardize across functions and platforms.

Focus on cross-functional ownership, decision rights, evidence, and repeatability.

Included in this object.

10,000+ employees

Use this to create enterprise control and reviewability.

Focus on federation, risk tiers, governance bodies, AI boundaries, and auditability.

Included in this object.

Artifact Content

Source artifact

The full artifact content below is rendered from the Markdown source packaged with 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.

Future Lapemo Use

The JSON schema turns decision communication protocol into software.

Lapemo can use this knowledge object as a guided workflow, scoring model, evidence record, governance input, and operating intelligence object. The schema is public for inspection and evaluation; production ingestion and governed execution remain separate product capabilities.