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 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

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.

• 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.

• 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.

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.

• 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.

• 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 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.

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.

• 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.

• 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 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.

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.

• 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.

• 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 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.

• 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.

• 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.

• 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.

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

• 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.

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.