# Meeting Architecture

**LPM Knowledge Object | Version 1.0 | Last reviewed: 2026-06-24**

A reusable template for designing meetings as part of the operating model, not as default coordination overhead.

## Object metadata

- **Object type:** LPM Knowledge Object
- **Primary LPM layers:** Communication Architecture, Decision Architecture, Information Ecology, Governance Architecture, AI Amplification
- **Connected layers:** Ownership Map, Decision Rights Model, Decision Log, Evidence Checklist, Escalation Map, Incentive Alignment
- **Primary use:** Define which meetings should exist, what each meeting is allowed to decide, what evidence is required, and what artifact must be produced.
- **Website use:** Downloadable template, workshop guide, AI readiness resource, JSON object for Lapemo ingestion, and future guided skill.
- **Version:** 1.0
- **Owner:** LPM / Lapemo
- **Last reviewed:** 2026-06-24

## What this object does

The Meeting Architecture object defines which meetings should exist, what each meeting can decide, what evidence must be prepared, what output must be captured, where the record lives, and when the meeting should be redesigned or retired.

For AI scaling, this matters because AI will create more summaries, alerts, recommendations, and work-routing events. Without meeting architecture, the enterprise gets faster noise instead of faster coordination.

## Core principles

- **Meetings are part of the operating model:** A meeting is not a calendar event. It is a coordination mechanism with a purpose, owner, input, output, and decision boundary.
- **Every recurring meeting must earn its existence:** If it does not create a decision, resolve a dependency, surface risk, align tradeoffs, or produce an artifact, it should be redesigned or removed.
- **Meetings cannot be the source of truth:** A meeting may create or validate truth, but the durable record must live in a decision log, work system, evidence pack, owner register, or knowledge base.
- **Decision rights must be explicit:** People should know whether a meeting can inform, recommend, approve, reject, escalate, or only discuss.
- **Evidence comes before opinion:** Material meetings need pre-reads, evidence owners, freshness windows, and documented assumptions before decisions are made.
- **AI should reduce meeting load:** AI can summarize, prepare, route, and detect stale forums, but it should not create false consensus or hidden decisions.
- **Meeting architecture must be reviewed:** As the company scales, old forums accumulate. The architecture needs retirement rules, consolidation triggers, and periodic hygiene reviews.

## Required fields

| Field | Definition | Required |
|---|---|---|
| Meeting ID | Unique identifier for the meeting, forum, ritual, council, standup, review, or escalation path | Yes |
| Meeting name | Plain-language name used on calendars, documentation, and operating maps | Yes |
| Meeting type | Decision forum, operating review, dependency review, risk review, AI governance, portfolio review, incident forum, change forum, learning review, or status sync | Yes |
| Purpose statement | Why this meeting exists and what organizational problem it solves | Yes |
| Allowed outcomes | Inform, align, decide, approve, reject, escalate, unblock, govern, learn, or retire | Yes |
| Not allowed outcomes | What the meeting is not allowed to decide or substitute for | Recommended |
| Accountable owner | Person or role accountable for the health, usefulness, agenda, evidence, and outputs of the meeting | Yes |
| Decision maker | Person, role, group, council, or control function with authority to make final decisions in the meeting | Required for decision forums |
| Facilitator | Person or role responsible for agenda flow, time discipline, participation, and output capture | Yes |
| Required attendees | Roles that must attend because they hold authority, evidence, risk ownership, dependency ownership, or execution accountability | Yes |
| Optional attendees | People who may be invited for context but are not required for authority or evidence | Optional |
| Input artifacts | Pre-read, dashboard, backlog, evidence pack, decision request, owner register, risk record, customer data, or AI evaluation | Yes |
| Evidence standard | Minimum evidence quality required before a decision, escalation, or approval can occur | Yes |
| Output artifact | Decision log entry, action register, escalation record, governance exception, owner update, risk update, or meeting summary | Yes |
| System of record | Where the output lives after the meeting | Yes |
| Cadence | Event-driven, daily, weekly, biweekly, monthly, quarterly, stage-gate, incident-based, or temporary | Yes |
| Duration | Expected time box and threshold for shortening, canceling, or splitting | Yes |
| Pre-read owner and due time | Who prepares evidence and when attendees must review it | Required for material meetings |
| Async alternative | What can be handled outside the meeting through comments, workflow, AI summary, dashboard, or decision request | Recommended |
| Escalation trigger | Condition that moves the issue, decision, dependency, risk, or AI event to another forum or authority tier | Required when material |
| AI involvement | None, AI agenda, AI summary, AI action extraction, AI evidence review, AI decision support, AI routing, or AI risk detection | Yes |
| Human review rule | When AI-produced notes, actions, summaries, recommendations, or decisions require human approval | Required when AI-assisted |
| Retention rule | How long agenda, pre-reads, summaries, recordings, decisions, and actions are retained | Yes |
| Health metric | Attendance quality, decision cycle time, action closure, meeting load, duplicate forums, stale items, or escalation rate | Yes |
| Review date | Date the meeting should be reviewed, redesigned, merged, retired, or reauthorized | Yes |
| Version | Artifact version, owner, last reviewed date, and change history | Yes |

## Scoring logic

| Score | Meeting architecture maturity |
|---|---|
| 0 | Meetings are informal, excessive, personality-driven, and disconnected from decisions, evidence, ownership, and systems of record. |
| 1 | Some recurring meetings have agendas, but decision rights, output artifacts, evidence standards, and retirement rules are unclear. |
| 2 | Key meetings are documented, but the architecture is not consistently linked to decision logs, owner maps, AI workflows, or governance controls. |
| 3 | Material meetings have owners, decision boundaries, evidence requirements, outputs, escalation paths, and review dates. |
| 4 | Meeting architecture is actively governed with AI-assisted prep, stale meeting detection, decision memory, output lineage, meeting load metrics, and executive visibility. |

## Meeting type taxonomy

| Meeting type | Purpose | Expected output |
|---|---|---|
| Executive operating review | Review enterprise performance, risk, dependencies, value, and decisions needing executive attention | Executive decisions, tradeoff calls, escalations, priority shifts |
| Portfolio prioritization forum | Allocate capacity, funding, sequencing, and tradeoffs across product, transformation, or AI initiatives | Priority decision, capacity decision, defer or fund decision |
| Decision forum | Make or ratify decisions that require explicit authority and documented evidence | Decision log entry and owner assignment |
| Dependency review | Resolve cross-team blockers, platform dependencies, data dependencies, vendor dependencies, or timing conflicts | Dependency owner, date, escalation, and system record update |
| Risk and control review | Review policy exceptions, audit findings, regulatory risk, security risk, model risk, or control gaps | Risk decision, exception, mitigation, or escalation |
| AI governance review | Approve or monitor AI use cases, agents, models, controls, human review rules, and drift signals | AI owner update, risk tier, launch gate, or remediation action |
| Incident / war room | Coordinate urgent operational, customer, technical, compliance, cyber, or AI incidents | Incident decision, communication plan, remediation owner, postmortem trigger |
| Change and adoption forum | Coordinate rollout, training, stakeholder impact, enablement, adoption metrics, and feedback loops | Change decision, adoption action, risk issue, or communication update |
| Team operating sync | Align near-term execution, blockers, handoffs, and commitments within a team | Action updates and work-system changes |
| Learning / postmortem review | Convert outcomes, incidents, misses, and launches into durable learning | Lessons, control updates, operating changes, and owner changes |

## Meeting architecture rules

- **No decision without decision rights:** A meeting cannot approve, reject, or reprioritize work unless the decision maker and decision tier are explicit.
- **No claim without evidence:** Material claims must be tied to an evidence source, owner, freshness window, and confidence level.
- **No output, no recurrence:** A recurring meeting without a durable output artifact should be canceled, merged, converted to async, or redesigned.
- **No hidden system of record:** Meeting notes in private notebooks, slides, or chats are not enough for enterprise memory.
- **No permanent temporary meetings:** Temporary incident, launch, or tiger-team meetings need an end date or retirement trigger.
- **No AI-only authority:** AI may prepare, summarize, recommend, route, or flag risk, but material decisions require named human accountability.
- **No attendance theater:** Required attendees must map to authority, evidence, execution, risk, or dependency ownership. Everyone else is optional or async.

## Meeting inventory template

| Meeting ID | Name | Type | Owner | Decision maker | Cadence | Output | Retire / redesign trigger |
|---|---|---|---|---|---|---|---|
| [Meeting ID] | [Meeting name] | [Type] | [Owner] | [Decision maker] | [Cadence] | [Output artifact] | [Retire / redesign trigger] |
| M-001 | Executive AI Operating Review | AI governance / operating review | AI transformation owner | Executive sponsor / AI council | Monthly | Decision log + AI owner register update | No decisions or risks for 2 cycles |
| M-002 | Cross-functional Dependency Review | Dependency review | Portfolio ops owner | Product / platform leads | Weekly | Dependency register update | Convert to async when blockers fall below threshold |
| M-003 | Risk Exception Review | Risk and control review | Control owner | Governance chair | Event-driven | Exception record + mitigation owner | Merge with governance review if volume is low |

## Company version: 500+ employees

**Profile:** Scaling company with founder-led or executive-led coordination beginning to break. Meetings are often the operating system because ownership, decision rights, and source systems are still maturing.

**Design Goal:** Create a minimum viable meeting architecture that reduces tribal coordination and makes decisions visible without adding bureaucracy.

### Must Have
- Executive operating review for priorities, risks, tradeoffs, and AI initiatives.
- Decision forum for material cross-functional decisions.
- Dependency review for blocked work across product, operations, technology, data, and support.
- AI initiative review for every material AI pilot, automation, vendor, model, or agent.
- Meeting kill list that removes recurring meetings without decisions, risk movement, or durable outputs.

### Anti Patterns
- Every decision still routes through founders or senior operators.
- Meetings exist because the work system is not trusted.
- Slack, Teams, and meetings become the source of truth.
- AI pilots are discussed in demos but not governed through owner, risk, and value records.

### Ai Rules
- AI may draft agendas and summaries, but human owners approve meeting outputs.
- Every AI-related meeting must update the AI Initiative Owner Register or Decision Log.
- Do not let AI-generated summaries become the official decision record without review.

## Company version: 5,000+ employees

**Profile:** Scaled enterprise with functional maturity but cross-functional drag. Meetings multiply across departments, portfolios, regions, and control groups.

**Design Goal:** Create a federated meeting architecture that separates status, decision, governance, escalation, and learning forums.

### Must Have
- Portfolio prioritization forums with explicit decision rights and capacity ownership.
- Cross-functional dependency forums linked to Jira, ServiceNow, product roadmaps, and enterprise platforms.
- Risk, control, and AI governance forums with evidence standards and audit-ready outputs.
- Meeting taxonomy that defines which forum owns which class of decision, issue, or escalation.
- Quarterly meeting hygiene review to consolidate duplicate forums and retire stale rituals.

### Anti Patterns
- Multiple councils debate the same decision without one accountable authority.
- Status meetings are mistaken for decision forums.
- Teams create shadow meetings to bypass slow governance.
- AI decisions move faster than risk, data, legal, compliance, and platform owners can respond.

### Ai Rules
- AI can classify meeting type, extract actions, compare decisions against policy, and detect duplicate forums.
- Material AI outputs must link to evidence, owner, decision, control, and review records.
- AI-generated meeting insights should flag stale decisions, unresolved actions, and missing owners.

## Company version: 10,000+ employees

**Profile:** Complex enterprise with regions, business units, shared services, regulated controls, platform ecosystems, and many AI use cases. Meeting architecture becomes a control layer issue.

**Design Goal:** Govern meetings as an enterprise coordination system with clear tiering, authority, auditability, and AI-assisted operating intelligence.

### Must Have
- Enterprise forum catalog with meeting tiers, decision rights, evidence standards, and ownership.
- Regional and business-unit forums that map to enterprise decision and escalation paths.
- AI control forums for agent activity, model risk, data lineage, value realization, drift, and human review exceptions.
- Meeting telemetry across time spent, decision cycle time, action closure, duplication, escalation rate, and forum effectiveness.
- Automated stale meeting detection and reauthorization for material recurring forums.

### Anti Patterns
- Enterprise governance creates more meetings than decisions.
- Global and regional forums conflict on decision rights.
- AI agents act across systems faster than meeting-based governance can see or correct.
- Executives receive meeting summaries without lineage to decisions, evidence, risks, and owners.

### Ai Rules
- AI may monitor meeting architecture health, summarize patterns, detect drift, and recommend consolidation.
- High-risk AI or regulated decisions require human-controlled forum outputs and audit-ready retention.
- Meeting architecture should feed an executive control plane showing where decisions, risks, and actions are stuck.

## AI prompts

- **Classify meeting:** Given a meeting name, agenda, attendees, cadence, and output, classify the meeting type and determine whether it is status, decision, risk, dependency, governance, incident, AI, change, or learning.
- **Detect weak architecture:** Review this meeting inventory and identify meetings with unclear purpose, missing owner, missing decision rights, no output artifact, duplicate scope, or no retirement trigger.
- **Recommend redesign:** For each low-value recurring meeting, recommend whether to keep, merge, split, convert to async, move to a decision forum, or retire.
- **Validate decision meeting:** Determine whether this meeting has the required authority, evidence, decision maker, source of truth, and logging path to make a material decision.
- **Generate agenda:** Create a decision-ready agenda using the meeting purpose, decision rights, evidence checklist, known risks, blockers, and required outputs.
- **Extract outputs:** From meeting notes or transcript, extract decisions, actions, owners, deadlines, evidence gaps, escalations, AI involvement, and records that need updates.
- **AI governance check:** Identify whether AI was used to prepare, summarize, recommend, decide, route, or execute work, then apply the correct human review rule.

## Validation rules

- **Meeting purpose required:** Every meeting must have a purpose statement that explains why it exists.
- **Owner required:** Every meeting must have one accountable owner for agenda quality, decision discipline, outputs, and review.
- **Decision boundary required:** If a meeting can make or recommend decisions, its decision rights and decision maker must be named.
- **Evidence required for material decisions:** A material decision cannot be logged without evidence source, owner, freshness, and confidence level.
- **Output required:** Every recurring meeting must produce or update at least one durable artifact.
- **System of record required:** Meeting outputs must be stored in an approved system of record, not only in chat, slides, or personal notes.
- **AI review rule required:** Any AI-generated agenda, summary, action, recommendation, or decision support must have a named human review rule.
- **Retirement trigger required:** Recurring meetings must define when they should be canceled, merged, converted to async, or reauthorized.
- **Review date required:** Meeting architecture records must have a review date and version owner.

## Mapping rules

- **Ownership Map:** Meeting owners, decision makers, evidence owners, action owners, and escalation owners must map to named roles.
- **Decision Rights Model:** Meeting authority must align to the approved decision tier and escalation path.
- **Decision Log:** Material decisions made or ratified in meetings must create or update decision records.
- **Evidence Checklist:** Meeting inputs for material decisions must meet the required evidence standard.
- **Escalation Map:** Blocked, high-risk, high-impact, or unresolved items must route to the correct escalation path.
- **Communication Map:** Meeting outputs must trigger the right communication path, not rely on attendees to spread the message.
- **AI Initiative Owner Register:** AI-related meetings must update AI owners, use cases, risk tiers, controls, evidence, and value metrics.
- **Platform Structure:** Meeting outputs must update the systems where work, risk, data, or decisions are managed.

## Website artifact copy

**Title:** Meeting Architecture

**Summary:** A reusable template for designing meetings as part of the operating model, not as default coordination overhead.

**CTA:** Download the Meeting Architecture template

### Usage
- Audit current recurring meetings.
- Separate status, decision, risk, governance, incident, dependency, and AI forums.
- Define owners, decision rights, evidence standards, outputs, and systems of record.
- Retire meetings that do not create decisions, unblock work, surface risk, or produce durable artifacts.
- Connect meeting outputs to Lapemo onboarding, decision logs, owner maps, and AI governance workflows.

## Reusable skill behavior

This knowledge object can be used as a guided skill that ingests a meeting inventory, classifies each meeting, scores architecture maturity, detects duplicate forums, identifies missing decision rights, recommends async replacements, and maps outputs to related LPM objects.