Large People ModelHuman Operating Architecture

Template & Working Tool · LPM Knowledge Object

Ownership Map

A living control artifact that connects outcomes, decisions, execution, information, platforms, governance, and AI ownership.

Mapv1.0.0OwnershipDecisionsInformation

Problem it solves

Accountability gaps and misaligned incentives prevent execution from scaling.

Who should use it

Outcome owners, transformation leads, and cross-functional teams

Estimated time

30–45 minutes for a first working session

Three-Step Quick Start

1Select a workflow, capability, product area, or enterprise system.
2Name owners across outcome, decision, execution, information, platform, governance, and AI.
3Score clarity and assign actions for gaps.

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

Ownership Map is a reusable LPM knowledge object that helps organizations companies scaling AI define and maintain accountable ownership across the full operating model. It gives teams a structured way to make ownership visible, owned, and reviewable.

Why it matters

As companies scale AI, weak operating-model structures become amplified. This object helps prevent ai scales activity without accountability. by defining ownership, flow, and handoff boundaries.

Layer Alignment

Where it fits in LPM

Primary LPM layer

Identity & Incentives

Clarifies who owns outcomes, how accountability is assigned, and whether incentives reinforce the behavior the enterprise needs.

Supporting layers

DecisionsInformationPlatformsGovernanceAI Amplification

Why it belongs here

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

Weakness it exposes

AI scales activity without accountability.

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: Quarterly or event-driven.

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

Ownership map

Ownership gap report

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 Ownership Map.

Core principle

AI does not remove ownership. It exposes whether ownership was ever defined clearly enough to scale.

The Ownership Map is not an org chart. It is a living control artifact that connects outcomes, decision rights, execution, information, systems, governance, and AI amplification.

Make this more than a download

Use the artifact in four forms:

Reference document - explains the model and the fields.
Template - gives teams a fillable map by company size.
Skill - guides a team through questions, scoring, gaps, and actions.
Knowledge object - stores the current, approved ownership model with version history, evidence, and update triggers.

Universal fields

Field	Meaning	Guidance
Work / capability domain	The workflow, capability, product area, or enterprise system being mapped.	Example: customer onboarding, product intake, finance close, AI support agents.
Outcome owner	The accountable leader for business results.	One name or role. Do not allow shared ambiguity.
Decision owner	The role with authority to make tradeoff decisions.	Defines what can be decided locally vs escalated.
Execution owner	The role that runs the process and coordinates delivery.	Usually product, operations, transformation, or process lead.
Information owner	The person accountable for data, knowledge, documentation, and context quality.	Critical for AI because poor context creates poor automation.
Platform owner	The person accountable for the system of record or workflow platform.	Example: Jira, ServiceNow, Salesforce, Workday, Teams, Confluence.
Governance owner	The person accountable for policy, risk, control, compliance, and review.	Must include control evidence, not just opinion.
AI / automation owner	The person accountable for AI use cases, agent behavior, model/tool access, and human review.	AI owner is not always the technical owner.
Evidence source	Where proof of ownership and decisions lives.	Charter, Jira project, RACI, policy, Confluence page, intake board, audit log.
Escalation trigger	What causes an ownership issue to be escalated.	No owner, conflicting owners, stale evidence, agent acting outside bounds.

Scoring rubric

Score	Definition
0 - Missing	No clear owner, no decision path, or ownership exists only through tribal knowledge.
1 - Named but weak	Owner exists, but authority, evidence, or decision rights are unclear.
2 - Defined	Owner, authority, evidence, and escalation are documented and usable.
3 - Governed and current	Ownership is actively reviewed, linked to systems of record, and safe for AI-assisted work.

Version 1: 500+ employees - The scaling company

Operating-model problem: The company has outgrown tribal coordination. Work still moves through relationships, meetings, Slack or Teams, and a handful of strong operators. AI pilots can spread quickly, but ownership does not scale at the same pace.

Recommended model: One accountable owner per domain, one decision owner for tradeoffs, lightweight governance, and a named human owner for every AI-enabled workflow.

Domain	Outcome owner	Decision rights	Execution owner	Info / data owner	Platform owner	AI owner	Evidence + escalation
Customer experience	[Role / name]	Customer-impacting process changes	[CX / Ops lead]	[Customer data steward]	[CRM / support platform owner]	[AI assist owner]	Evidence: CX charter, CRM workflow, support playbook. Trigger: no owner for AI-generated response quality.
Product delivery	[Role / name]	Roadmap tradeoffs, delivery priority	[Product lead]	[Product docs owner]	[Jira / roadmap owner]	[AI product workflow owner]	Evidence: roadmap, Jira board, release notes. Trigger: duplicate priorities or unclear DRI.
Internal knowledge	[Role / name]	Source-of-truth rules	[Ops / enablement lead]	[Knowledge owner]	[Confluence / Teams owner]	[AI knowledge retrieval owner]	Evidence: knowledge standards, page owners. Trigger: AI answers from stale or ownerless content.
People operations	[Role / name]	Employee lifecycle changes	[HR ops lead]	[People data owner]	[HRIS owner]	[HR automation owner]	Evidence: HR process map, HRIS ownership. Trigger: manager self-service or AI HR answers lack review.
Finance / planning	[Role / name]	Forecast assumptions and approval	[FP&A lead]	[Finance data owner]	[Planning system owner]	[Finance AI analysis owner]	Evidence: forecast calendar, assumptions log. Trigger: conflicting numbers across reports.
Governance / risk	[Role / name]	Acceptable risk and review path	[Risk / legal lead]	[Policy owner]	[GRC / document system owner]	[AI risk owner]	Evidence: risk register, policy review log. Trigger: AI use case lacks approval path.

Version 2: 5,000+ employees - The scaled enterprise

Operating-model problem: Functional maturity exists, but ownership breaks across handoffs. AI increases the speed of work while exposing unclear decision rights and fragmented context.

Recommended model: Separate outcome accountability from process execution, system ownership, control ownership, and AI workflow ownership.

Enterprise domain	Executive sponsor	Business owner	Decision authority	Process owner	Data / knowledge owner	System owner	Control owner	AI workflow owner	Evidence + health
Customer onboarding	[Exec sponsor]	[BU owner]	Onboarding policy, exceptions, SLA	[Process owner]	[Customer data steward]	[CRM / workflow owner]	[Risk/control owner]	[AI workflow owner]	Evidence: journey map, SLA, CRM config. Health: [0-3].
Revenue operations	[Exec sponsor]	[Sales ops owner]	Lead routing, pipeline definitions	[RevOps lead]	[Revenue data owner]	[CRM / BI owner]	[SOX / policy owner]	[AI sales assist owner]	Evidence: pipeline policy, data dictionary. Health: [0-3].
Product portfolio intake	[Exec sponsor]	[Portfolio owner]	Priority, funding, sequencing	[Portfolio ops owner]	[Roadmap data owner]	[Jira / Aha owner]	[Governance owner]	[AI planning owner]	Evidence: intake board, scoring model. Health: [0-3].
Employee service	[Exec sponsor]	[HR service owner]	Service tiers, policy exceptions	[HR ops lead]	[People knowledge owner]	[HRIS / service platform owner]	[Policy owner]	[HR AI support owner]	Evidence: service catalog, policy pages. Health: [0-3].
Data and BI	[Exec sponsor]	[Analytics owner]	Metric definitions, certified sources	[BI operations owner]	[Data product owner]	[Warehouse / BI owner]	[Data governance owner]	[AI analytics owner]	Evidence: semantic layer, metric catalog. Health: [0-3].
AI pilot intake	[Exec sponsor]	[Business use-case owner]	Pilot approval, risk acceptance	[Transformation / product owner]	[Input data owner]	[AI platform owner]	[AI governance owner]	[Human-in-loop owner]	Evidence: intake record, model card, controls. Health: [0-3].

Version 3: 10,000+ employees - The federated enterprise

Operating-model problem: Governance exists, but it is fragmented across regions, legal entities, shared services, and platforms. AI creates new control paths that require named owners across policy, data, systems, agent behavior, and audit evidence.

Recommended model: Global accountable owner, regional/local owner, process owner, system owner, data owner, control owner, and AI/model owner are defined separately.

Global domain	Global accountable owner	Regional / BU owner	Decision rights	Process / service owner	Data / knowledge owner	Platform owner	Control / policy owner	AI / model owner	Audit evidence + trigger
Global customer operations	[Global owner]	[Region / BU owner]	Global standards vs local exceptions	[Service owner]	[Customer data owner]	[CRM / service owner]	[Control owner]	[AI service agent owner]	Evidence: global standard, regional exception log. Trigger: local variation lacks approved owner.
Enterprise data foundation	[Global owner]	[Data domain owner]	Certified source, metric definition, access	[Data product owner]	[Data steward]	[Warehouse / lakehouse owner]	[Data governance owner]	[AI data usage owner]	Evidence: data catalog, lineage, access reviews. Trigger: AI uses uncertified or stale data.
Workforce operations	[Global owner]	[Region / legal entity owner]	Policy, employee data use, local labor rules	[HR service owner]	[People knowledge owner]	[HRIS owner]	[Legal / compliance owner]	[AI HR agent owner]	Evidence: policy inventory, country addenda. Trigger: AI output crosses policy or regional boundary.
Technology portfolio	[Global owner]	[Platform / domain owner]	Investment, rationalization, architecture	[Portfolio ops owner]	[App/system data owner]	[ITSM / portfolio owner]	[Architecture governance owner]	[AI software delivery owner]	Evidence: app catalog, architecture decision records. Trigger: duplicate AI tools or ownerless apps.
Risk and controls	[Global owner]	[Risk domain owner]	Control standard, risk acceptance	[Control operations owner]	[Control evidence owner]	[GRC platform owner]	[Policy owner]	[AI risk assessment owner]	Evidence: control library, test results, issue log. Trigger: AI-assisted control lacks accountability.
Agentic AI operations	[Global owner]	[Business use-case owner]	Agent permissions, autonomy, rollback	[Agent operations owner]	[Prompt/context owner]	[AI platform owner]	[AI governance owner]	[Model/agent owner]	Evidence: model card, evals, approvals, incidents. Trigger: agent acts outside policy or lineage.
M&A integration	[Global owner]	[Deal / BU owner]	Target-state ownership, system migration	[Integration owner]	[Source data owner]	[Integration platform owner]	[Compliance owner]	[AI migration assist owner]	Evidence: TSA, integration plan, ownership transition. Trigger: inherited process lacks owner.

Auto-update triggers

The map should be reviewed when any of these happen:

Reorganization or owner departure
New AI workflow or agent deployment
System migration or new platform purchase
Regulatory, audit, or control issue
Process moves across functions, regions, or vendors
Documentation or evidence source becomes stale
Conflicting metrics or duplicated systems appear

Human approval rule

Automation can flag stale ownership, missing owners, and broken lineage. It should not silently rewrite the approved ownership model. Material changes need a named human approver and version history.

Future Lapemo Use

The JSON schema turns ownership map 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.