Skip to main content
Large People ModelHuman Operating Architecture

Template & Working Tool · LPM Knowledge Object

Decision Log

A log for recording material decisions, owners, evidence, rationale, commitments, and reversal triggers.

Logv1.0.0Decisions

Problem it solves

Slow, unclear, or reversible decisions create execution drag.

Who should use it

Governance forums, program leaders, and accountable decision owners

Estimated time

30–45 minutes for a first working session

Three-Step Quick Start

  1. 1Capture the decision and owner at the moment it is made.
  2. 2Record rationale, evidence, and expected action.
  3. 3Review aging, reversals, and unresolved commitments.
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 Log is a reusable LPM knowledge object that helps organizations reduce decision debt by making key choices traceable, reviewable, and connected to accountable follow-through. 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 traceability, evidence, and review 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

No secondary layer assigned.

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

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

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 record

Decision aging view

Reversal or escalation triggers

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

A Decision Log creates organizational memory. It records what was decided, who had the authority to decide, why the decision was made, what evidence was used, what tradeoffs were accepted, how the decision was communicated, and when it must be reviewed.

The object is reusable across three company profiles: 500+, 5,000+, and 10,000+ employees.

1. Knowledge object model

What this knowledge object contains

  1. Human guide - plain-language guidance for executives, transformation leaders, product, technology, risk, operations, data, and AI leaders.
  2. Template artifact - a downloadable decision log that teams can use during strategy, planning, governance, delivery, and AI scaling.
  3. Machine-readable schema - fields, scoring logic, validation rules, mappings, prompts, review triggers, and version metadata.
  4. Guided skill - an AI-assisted workflow that classifies decisions, detects missing accountability, creates decision summaries, and flags stale or conflicting decisions.

Why this matters for AI scaling

AI makes weak decision memory dangerous. When decisions are scattered across meetings, chats, documents, dashboards, and system tickets, AI cannot safely reason over enterprise intent. A decision log becomes the source of truth for what the organization actually chose and why.

2. Canonical fields and scoring

Required fields

FieldWhat it capturesRequired?
Decision IDUnique identifier for the decision recordYes
Decision titleShort human-readable name for the decisionYes
Company profile500+, 5,000+, or 10,000+ employee versionYes
Decision typeStrategic, operating, technical, risk, funding, product, people, data, platform, or AI decisionYes
LPM layerPrimary LPM layer affected by the decisionYes
Decision ownerOne accountable owner for the decision record and outcomeYes
DeciderRole or person with authority to make the decisionYes
RecommendersRoles or teams that shaped the recommendationYes
ConsultedRoles that must be consulted before finalizationRequired when cross-functional
InformedRoles or audiences that must be informed after decisionYes
Decision dateDate the decision was madeYes
Effective dateDate the decision becomes activeYes
StatusProposed, approved, rejected, deferred, active, superseded, retiredYes
Decision contextProblem, opportunity, or constraint that triggered the decisionYes
Options consideredAlternatives evaluated before the decisionYes
Chosen optionThe selected pathYes
RationaleWhy this option was selectedYes
Evidence inputsData, analysis, policy, customer signal, risk input, or AI output usedYes
AssumptionsKnown assumptions behind the decisionYes
TradeoffsWhat the organization knowingly gave upYes
Risks acceptedRisks explicitly accepted by the deciderRequired when risk exists
Downstream impactsTeams, workflows, systems, customers, employees, or controls affectedYes
Systems impactedPlatforms, records, tools, models, or workflows touchedRequired when systems change
AI involvementNone, assisted, recommended, drafted, routed, executed, or autonomousYes
AI decision boundaryWhat AI can and cannot do in relation to the decisionRequired when AI involved
Human review ownerOwner accountable for human review and overrideRequired when AI involved
Control ownerRisk, compliance, security, legal, privacy, model risk, or audit ownerRequired for material or regulated decisions
Communication pathHow the decision is communicated and where it is storedYes
Implementation ownerOwner accountable for executionYes
Value metricMetric that proves the decision worked or did not workYes
Review dateDate to revisit or validate the decisionYes
Revisit triggerCondition that forces review before the review dateYes
Supersedes decision IDPrior decision replaced by this decision, if applicableOptional
Source linksLinks to artifacts, meeting notes, Jira, docs, approvals, dashboards, or evidenceYes
VersionObject version and effective dateYes

Decision log scoring logic

Score each decision record from 0 to 4.

ScoreMeaning
0Decision is not logged, owner is missing, or rationale is unavailable
1Decision is captured, but owner, rationale, evidence, or communication path is incomplete
2Decision has owner, rationale, and date, but options, evidence, impact, or review rules are weak
3Decision has clear authority, evidence, rationale, impacts, implementation owner, and review date
4Decision is versioned, linked to evidence, monitored, communicated, supersession-ready, and AI-safe

Decision memory score: average of ownership clarity, decision authority, evidence quality, rationale quality, impact mapping, communication completeness, review discipline, and AI boundary clarity.

High-risk flag: any material decision with a score below 3, AI involvement above Level 1, or missing control owner when risk is medium, high, regulated, or critical.

3. Role model

RoleAccountabilityApproval responsibility
Decision ownerOwns the decision record, outcome traceability, and review disciplineYes
DeciderHas the authority to make or approve the decisionYes
RecommenderCreates the recommendation, options, evidence, and tradeoff analysisNo
Consulted roleProvides input that must be considered before the decisionNo
Informed roleReceives the decision after approvalNo
Implementation ownerTurns the decision into execution, system change, workflow change, or policy changeYes
Control ownerConfirms risk, legal, compliance, security, privacy, model risk, or audit implicationsRequired for material decisions
Human review ownerOwns review, override, escalation, and exception handling when AI is involvedRequired when AI is involved
Value ownerTracks whether the decision delivered the intended outcomeRecommended

Owner rule

Every material decision needs one accountable decision owner. Committees can advise, review, or approve. They cannot replace accountable ownership.

4. Version A - 500+ employee company

A 500+ employee company usually moves fast, but decision memory often lives in leaders, Slack, Teams, and recurring meetings. The log should be lightweight enough to use, but strong enough to prevent ambiguity.

Design area500+ versionMinimum standard
Decision scopeTeam, product, function, or leadership decisionKeep the log simple and visible
Owner modelOne accountable decision owner and one implementation ownerNo decision without a named owner
EvidenceCustomer signal, operator judgment, financial data, delivery impact, risk note, or leadership inputDo not require heavy bureaucracy for low-risk calls
CommunicationPost decision in one visible location and inform affected teamsReduce Slack and meeting memory dependence
AI involvementCapture whether AI drafted, summarized, recommended, or automated part of the decisionAny AI-assisted decision needs human owner
Review cadenceMonthly or quarterly for active decisionsPrevent stale decisions from becoming tribal rules

500+ design principle: keep the decision log simple, visible, and owner-led. The goal is not bureaucracy. The goal is to stop decisions from disappearing into tribal memory.

5. 500+ implementation notes

Recommended operating pattern

  • Use one shared decision log for leadership, product, operations, technology, and AI initiatives.
  • Require a decision owner, rationale, communication path, and review date for any material decision.
  • Log AI-assisted decisions even when AI only drafted, summarized, or recommended.
  • Review active decisions monthly during operating reviews.
  • Mark superseded decisions clearly instead of deleting history.

Common failure modes

Failure modeSignalFix
Decision lives in a meetingTeams ask the same question repeatedlyCreate a short decision record with owner, rationale, and source links
Founder or executive memory becomes the systemPeople wait for verbal clarificationMove decisions into a visible log
AI recommendations become undocumented influenceTeams cannot explain why a path was chosenCapture AI involvement and human decision owner
No review dateOld decisions keep driving work after assumptions changedAdd revisit trigger and review cadence

6. Version B - 5,000+ employee company

A 5,000+ employee company needs decision memory across functions. The log should connect business direction, technology execution, risk input, data evidence, funding, product priorities, and platform dependencies.

Design area5,000+ versionMinimum standard
Decision scopeCross-functional, product, technology, risk, data, funding, operating, or platform decisionUse one shared log across major initiatives
Owner modelDecider, decision owner, implementation owner, control owner where neededSeparate decision authority from execution ownership
EvidenceRoadmap, business case, customer data, risk analysis, architecture input, data quality, or policy sourceRequire evidence for material decisions
CommunicationDecision summary linked to Jira, Confluence, governance notes, and leadership forumsMake decisions searchable and reusable
AI involvementClassify AI use and decision boundaryAI recommendations require human decision owner and evidence trail
Review cadenceQuarterly portfolio review plus event-driven reviewReview when assumptions, systems, risk, or incentives change

5,000+ design principle: make the decision log the shared memory layer between business strategy, product delivery, technology, data, risk, and governance.

7. 5,000+ implementation notes

Recommended operating pattern

  • Connect major decision records to roadmap epics, governance forums, architecture decisions, risk reviews, and operating metrics.
  • Require options, rationale, evidence, decision owner, implementation owner, and affected systems for material decisions.
  • Use the decision log in quarterly business reviews and portfolio reviews.
  • Require AI decision boundary classification for AI-assisted or AI-enabled decisions.
  • Use supersession history to reduce conflicting direction across departments.

Common failure modes

Failure modeSignalFix
Departments make conflicting decisionsTeams execute against different assumptionsCreate one shared decision ID and supersession model
Evidence is disconnected from decisionLeaders debate the same facts repeatedlyLink evidence, assumptions, and rationale directly to the record
Risk is consulted too lateControls appear after delivery has momentumAdd control owner and risk review before active status
Decision and execution splitNobody owns follow-throughAdd implementation owner and value metric

8. Version C - 10,000+ employee company

A 10,000+ employee company needs an enterprise decision ledger. Local teams need speed, but the enterprise needs auditability, legal and regional awareness, risk traceability, AI boundary control, and decision lineage.

Design area10,000+ versionMinimum standard
Decision scopeEnterprise, BU, region, legal entity, platform, risk, data, AI, or customer-impacting decisionFederate local decisions into an enterprise ledger
Owner modelDecider, accountable decision owner, implementation owner, control owner, value owner, and jurisdiction owner where neededAuthority must be auditable by role and level
EvidenceFormal evidence pack, control evidence, audit trail, data lineage, model or agent trace, and approval historyMaterial decisions need replayable evidence
CommunicationDecision ledger connected to governance, architecture, risk, roadmap, model registry, data catalog, and operating updatesNo material decision should live only in a meeting deck
AI involvementDocument decision boundary, human review, model or agent owner, monitoring owner, and prohibited actionsAutonomous or regulated AI requires formal approval
Review cadenceTiered review by risk, region, system, model, and decision boundarySupersede or retire stale decisions explicitly

10,000+ design principle: federate decision-making, but centralize decision memory, evidence standards, AI boundaries, and supersession history.

9. 10,000+ implementation notes

Recommended operating pattern

  • Maintain a federated decision ledger by business unit, function, region, legal entity, platform, initiative, and risk tier.
  • Connect decision records to policy, controls, model registry, architecture repository, data catalog, roadmap, and audit evidence.
  • Require formal evidence packs for high-impact, regulated, customer-facing, employee-impacting, financial, or AI-autonomous decisions.
  • Create decision conflict detection across related initiatives and platforms.
  • Use explicit supersession and retirement rules so old decisions do not remain operationally active.

Common failure modes

Failure modeSignalFix
Local decisions become enterprise conflictsRegions or BUs implement incompatible directionUse federated ledger with global decision IDs and local context
Audit cannot reconstruct why a decision happenedEvidence sits across decks, emails, chats, and ticketsCreate evidence pack and version history
AI agents act on stale decisionsAutomation follows old policy or outdated assumptionsRequire current active decision source and review trigger
Old decisions never retireTeams cite outdated approvalsUse superseded and retired statuses with lineage

10. Decision log template

FieldExample valueInstruction
Decision IDDL-0001Unique and stable ID
Decision titleShort title
Decision typeStrategic, operating, technical, risk, funding, product, people, data, platform, AI
Decision ownerOne accountable owner
DeciderPerson or role with authority
StatusProposed, approved, active, superseded, retired
Decision dateYYYY-MM-DD
Effective dateYYYY-MM-DD
ContextWhy this decision is needed
Options consideredAt least two options for material decisions
Chosen optionSelected path
RationaleWhy this path won
Evidence inputsLinks or references
TradeoffsWhat was sacrificed
Risks acceptedExplicit risk acceptance
Downstream impactsTeams, workflows, systems, controls, customers, employees
AI involvementNone, assisted, recommended, routed, executed, autonomous
AI decision boundaryWhat AI can and cannot do
Communication pathWhere the decision is stored and announced
Implementation ownerWho makes it real
Value metricHow success will be judged
Review dateWhen it must be revisited
Revisit triggerCondition that forces review

11. AI decision boundary levels

LevelAI roleRequired controlHuman accountability
Level 0No AI usedNormal decision log onlyNone
Level 1AI summarizes or drafts contextDecision owner validates accuracyHuman accountable for final wording
Level 2AI recommends optionsEvidence and assumptions must be visibleHuman decider chooses and records rationale
Level 3AI routes or triggers workflow stepsProcess owner and control owner approve flowExceptions and override path required
Level 4AI executes with human approvalControl evidence and monitoring requiredHuman approval required before action
Level 5AI acts autonomouslyFormal governance approval requiredAutonomy, monitoring, incident path, and stop control required

12. Validation rules

Validation conditionSystem responseReason
Missing decision ownerBlock approvalEvery material decision needs one accountable owner
Missing rationaleBlock active statusA decision without rationale becomes politics or memory
AI involved but no boundaryBlock production or executionAI scope must be explicit
Material risk but no control ownerEscalateRisk acceptance must have accountable control owner
No review dateFlag stale riskDecisions age and assumptions drift
Superseded decision still activeRequire cleanupOld decisions must not compete with new decisions
No communication pathFlag adoption riskA decision is not real until affected teams can find it

13. Mapping rules

Connected LPM objectDecision log mapping
Ownership MapDecision owner, decider, implementation owner, control owner
Decision Rights MatrixDecision type, authority level, consulted roles, informed roles
Incentive Alignment ChecklistValue metric, behavior change, tradeoffs, risk acceptance
AI Initiative Owner RegisterAI involvement, AI boundary, owner, risk tier, human review owner
Governance ArchitectureApproval status, control owner, evidence, review date, escalation path
Information EcologyEvidence inputs, source links, assumptions, decision memory
Platform StructureSystems impacted, workflow changes, data sources, implementation dependency
Communication ArchitectureCommunication path, informed audiences, decision summary

14. AI prompts for the guided skill

  • Classify this decision by type, LPM layer, risk level, and company profile.
  • Identify the decider, decision owner, implementation owner, consulted roles, informed roles, and control owner if needed.
  • Summarize the context, options considered, chosen option, rationale, evidence, assumptions, and tradeoffs in plain language.
  • Detect whether AI influenced the decision and classify the AI decision boundary from Level 0 to Level 5.
  • Find missing fields that would prevent this decision from being approved, implemented, or audited.
  • Generate an executive decision summary, a team communication note, and a governance-ready record from the same object.
  • Detect stale, superseded, conflicting, or duplicated decisions across an initiative, function, or enterprise portfolio.

15. Render outputs

OutputUse
Word documentWorkshops, consulting, internal enablement, website download
PDF guideExecutive briefing, education, static reference
Website pagePublic resource hub and SEO content
Interactive formGuided decision capture and validation
JSON objectLapemo ingestion and versioned knowledge object storage
CSV or table viewBulk import into decision ledger, Jira, Airtable, Notion, or governance tools
In-app workflowLive decision memory, stale decision alerts, conflict detection, AI boundary governance

16. Review and update triggers

  • Decision reaches review date.
  • Decision owner changes role or leaves the organization.
  • AI begins influencing, recommending, routing, or executing work related to the decision.
  • A downstream system, data source, policy, workflow, model, agent, or vendor changes.
  • A risk, control, legal, compliance, privacy, or security issue appears.
  • A newer decision supersedes the existing decision.
  • Measured outcomes show the decision is not producing intended value.

17. Website positioning copy

Decision Log

A reusable LPM template for turning decisions into durable organizational memory. Use it to capture ownership, authority, rationale, evidence, tradeoffs, downstream impact, AI involvement, and review triggers before decisions become scattered across meetings, chats, decks, and systems.

18. Practical guidance

A decision log is not meeting minutes. It is an operating control. It should be short enough that teams actually use it and structured enough that the organization can later understand, audit, automate, and improve decisions.

Future Lapemo Use

The JSON schema turns decision log 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.

Version Metadata

Version metadata

Version

1.0.0

Last updated

2026-06-23

Review cadence

Weekly or biweekly for active initiatives

Decision Log

Make it part of the operating model.

Use this object as a working record now, then connect it to metrics, evidence, and Lapemo workflows as the operating system matures.