Map of Work
What is a Map of Work?
Enterprise AI rarely disappoints for lack of intelligence. It disappoints because a capable model arrives knowing nothing about how your company actually works: what a payment approval means here, who is allowed to sign one, when to escalate, and what an auditor will ask about it a year from now. A Map of Work is the description that closes that gap. It is your organization’s own governed account of how work really runs, written down so that your people and your AI agents can both read it.
- What is a Map of Work?
- Map of Work, defined
- Why do enterprises need a Map of Work?
- How does a Map of Work work?
- What are the key components of a Map of Work?
- What is the role of the cartographer?
- Map of Work use cases
- Benefits of a Map of Work
- How to build and maintain a Map of Work
- How UiPath supports the Map of Work
- Map of Work and related concepts
- Best practices
- Frequently asked questions
The Map of Work is an organization’s own governed, living description of how its work actually runs across its mapped business processes. It combines formal business structure, the operating knowledge experienced employees use to handle exceptions, and a record of consequential decisions, giving AI agents the enterprise context they need to act reliably. A Map of Work is a concept and a customer-owned asset, not a product. Nothing in it changes without an accountable owner’s approval.
In more detail, a Map of Work brings together three dimensions of enterprise work. The formal side: the business ontology that defines what things the business handles and what may happen to them, the Process Orchestrator definitions—including case plans and workflow definitions—that describe how each mapped process runs, and the business rules that must hold. The practical side: the operating knowledge experienced people carry in their heads, meaning the precedents, examples and exception guidance that never made it into a system. And a record of consequential decisions and the reasons behind them, carried inside the Map in the Decision Ledger, which is on the UiPath roadmap.
Daniel Dines introduced the idea in The Work That Remains as “the map and the rails.” The Map describes the organization’s work, including the processes, business meaning, rules and operating knowledge that govern it. The rails execute each process within those approved boundaries and stop what is not allowed.
A Map of Work is not: a process diagram, a BPMN model from a consulting engagement, a wiki, or a product you can buy. It is a living description of your own business that you own and govern.
Map of Work, defined
A Map of Work describes what the business handles, what its words mean in this particular company, which rules apply, who may decide what, what must happen afterward, and how experienced people actually handle the exceptions. It belongs to the organization it describes, and it changes only with an accountable owner’s approval.
Most organizations believe they already have this. What they usually have is process documentation: a set of diagrams, a wiki, a BPMN model produced during a transformation program some years ago. Those describe a business as somebody intended it to work, at a moment that has passed, and they are often maintained by people who have since moved on. A Map of Work describes how work runs today, and it changes as the business changes.
Is a Map of Work a product?
No. A Map of Work is a concept and an asset, not a product or a SKU. There is nothing to buy called a Map of Work, and no release date attached to it.
That distinction matters more than it might appear. The Map describes your business, in your vocabulary, reflecting decisions your organization is accountable for. It belongs to you. Software can help you build it, keep it current and put it to work, and UiPath makes capabilities that do exactly that. But the asset itself is yours, and it should remain readable and meaningful independently of any vendor.
What does “governed” mean here?
Governed means two things. First, that every part of the Map has a named, accountable owner. Second, that nothing in it changes without that owner’s approval.
This is the discipline that separates a Map of Work from a knowledge base. A knowledge base accumulates. A Map of Work is versioned, owned and deliberately changed, because software and AI agents are going to act on what it says. If an agent can be briefed from the Map, then an unreviewed edit to the Map is an unreviewed change to how the business behaves.
Why do enterprises need a Map of Work?
Because enterprise AI is rarely limited by the intelligence of the model. It is limited by the absence of governed context about how a specific company operates. A model can reason well and still be unable to act safely in your business, because nothing has ever told it how your business works.
The bright stranger problem
A modern model is capable, and it is also a stranger in your building. It does not know what a payment approval means in your company, who is permitted to sign one, at what point a case should be escalated, or what an auditor will ask for twelve months from now. Somebody on your team knows. Possibly only one person knows.
Unlike a new hire, the model does not learn any of this on the job. It arrives every morning capable and new, with no memory of you. You can prompt a stranger. Without a description of the work, you cannot orient one.
Why intelligence alone is not enough
Capability and context are different problems, and only one of them is solved by a better model. Reliable execution in an enterprise depends on knowing which rule applies to this case, which version of that rule is current, who holds the authority to override it, what evidence has to be attached, and what must happen after the decision is made. None of that is inferable from general knowledge. It is specific to one organization, and often to one team inside it.
This is why capable agents stall on real work. The intelligence is available. The governed enterprise context is not.
The gap between documented process and actual work
Every organization runs on a description of how its work happens, and almost none of them have written it down.
It lives in the accounts payable lead who knows which supplier’s freight charges always run over and always get paid. In the claims adjuster who recognizes which repeat addresses are actually fraud. In the operations manager who knows the approval step everyone bypasses on the last day of the quarter. This is tribal knowledge, and it is load-bearing. When those people are on holiday, the organization gets slightly worse at its job. When they leave, it forgets.
Judgment is produced every day and lost every day
There is a second loss, and it is larger. Every time a reviewer approves something, rejects it, edits a recommendation or escalates a case, they produce judgment. Almost all of it disappears the moment the task closes.
For twenty years that was an inefficiency. It becomes a structural problem the moment work is handed to AI agents, because those decisions are precisely the material an agent would need in order to handle the same situation well. The reasoning that would teach it is generated constantly, and then thrown away.
How governed context produces reliable execution
Governed context is what makes the difference between an agent that can reason about work and an agent that can be trusted to participate in it. When the description of the work is written down, owned and versioned, three things become possible at once.
An agent can be briefed from the Map rather than prompted from scratch, so it starts from what the business has decided rather than from what it can infer. A decision can cite the rule version it applied, so the outcome is explicable afterward. And the boundary of the agent’s authority is explicit, which means a human is asked at the points where a human should be asked.
That is the operating model the Map exists to serve: AI proposes, humans decide, automation executes.
How does a Map of Work work?
A Map of Work operates as the context layer between the description of a business and the systems that carry out its work. The formal structure says what exists and what the rules are. The operating knowledge says how experienced people handle the situations the rules do not settle. Agents are briefed from both. Consequential decisions are recorded with their reasons. Patterns in those decisions become proposed changes to the Map, which an accountable owner approves or rejects.
AI proposes, humans decide, automation executes
The Map is built for a specific division of labor, and it is worth stating plainly because it determines the shape of everything else.
AI agents interpret context, investigate, plan and prepare work. People remain accountable for consequential decisions. Deterministic automation executes what has been approved, exactly, every time. Each part does what it is actually good at: the agent handles interpretation and preparation, the human carries the accountability, and the automation provides the precision and the audit trail.
The Map of Work is what makes that division workable, because all three parties are operating from the same governed description of the work.
The map and the rails
In The Work That Remains the Map is one half of a pair. The rails are the machinery that executes what is approved, exactly and repeatedly, and stops what is not allowed.
The distinction is worth holding onto. The map describes the work. The rails make that description binding: they enforce permissions, execute approved actions, record what happened, and refuse what falls outside the boundary. The Map without the rails remains the organization’s governed source of truth, but it cannot make that description binding in execution. The rails without the Map are automation without the governed business context needed to know what the work means.
Step by step
Each mapped process is put to work through six stages.
The formal description is written down
The business ontology, case plans and business rules are recorded formally, on open standards, so that a machine can verify them and an agent can be briefed on them. The Map points at systems of record rather than copying their data, so the data stays where it lives and those systems remain authoritative.
Operating knowledge is captured alongside it
Precedents, worked examples and exception guidance are written down and attached to the work they apply to. Operating knowledge guides agents and recommendations. It does not override a rule or a policy.
Agents are briefed from the Map
An agent working on a case starts from the business meaning, the applicable rules and the relevant precedents, rather than from a prompt written by whoever set it up.
Work runs on the rails
Approved actions are executed deterministically under enforced permissions, with state held across systems and time, approvals waited for, and every action recorded.
Consequential decisions are recorded with their reasons
When a person decides something that matters, the recommendation, the evidence, the rules and Map version applied, the decision, the reason, the action taken and the outcome are captured together in the Decision Ledger.
Patterns become proposals, and owners decide
When the record shows a repeated pattern, a change to the Map can be drafted and tested against past cases. The accountable owner approves or rejects it. The Map is never rewritten automatically.
How the Map improves after go-live
The Map grows and improves process by process. Each mapped process starts as a governed description of what should happen; live work then exposes where that description is incomplete, and approved learnings update the relevant part of the organization-wide Map.
The Decision Ledger records the moments where written policy and experienced judgment diverged, and the reasons given. When a pattern emerges, the system drafts a change and replays past cases against it, showing which outcomes would have been different. The cartographer curates and routes the proposed change; the accountable owner of the affected process or Map component decides whether it is approved. The next run carries that decision forward, and the cycle begins again.
The distinction from process mining is the important part. Mining tells you what happened. This cycle uses what happened as evidence, and keeps a person in charge of what becomes the rule. Observed behavior is evidence. It is not policy.
Improving the process, not just the agent
There is considerable current interest in making individual agents self-improving: mine the traces, find the failures, propose a prompt fix. That is useful, and it is narrow. An agent is one actor in a process that also contains rules, case stages, human decisions and deterministic automation. Improving the actor while the process around it stays frozen produces a very capable agent inside a slow business.
The Map of Work is aimed at the organization’s whole system of work, improved process by process. The rules, process definitions, operating knowledge and automation around an agent can all change as evidence accumulates. The controls still have to be clear on day one. But teams no longer have to anticipate every exception before a process reaches production, because finding the exceptions is what the loop is for.
What are the key components of the Map of Work?
The Map of Work contains structured knowledge (the formal half) and operating knowledge (the practical half). The Decision Ledger is the record of consequential decisions, carried inside the Map.
Structured knowledge
Sits within: The Map of Work
The formal half of the Map: what exists, what may happen, and which rules apply. Written formally and on open standards so a machine can verify it and an agent can be briefed on it.
Business ontology
Sits within: Structured knowledge
The entity-and-action component: the business entities the organization handles, the states they can be in, and the actions that can be taken on them. A component of structured knowledge, not another name for the Map of Work.
Business rules
Sits within: Structured knowledge
The rules that must hold, each with a named owner and a version. A rule states what must be true. A decision applies rules to current facts and chooses a path.
Process Orchestrator definitions
Sits within: Structured knowledge
How each mapped process runs, including its case plans, stages, workflows and other execution patterns.
Operating knowledge
Sits within: The Map of Work
The practical half: captured precedents, worked examples and exception guidance that experienced people currently carry in their heads. It guides agents and recommendations without overriding rules or policy.
Decision Ledger
Sits within: Carried inside the Map of Work
The record of consequential decisions: the recommendation, the evidence, the applicable rules and Map version, the human decision and the reason for it, the action executed, and the outcome. Not a knowledge layer, not an execution log, and not a replacement for audit.
Structured knowledge
Structured knowledge is the formal core of the Map of Work. It is the part a machine can check.
It has three components. The business ontology defines the entities the business handles, the states those entities can occupy, and the actions that can be taken on them: an invoice, a claim, a dispute, a vendor, and what may legitimately happen to each. Business rules state what must hold, each with a named owner and a version, so that a decision can cite the rule version it applied. The Process Orchestrator definition describes how that mapped process progresses through its lifecycle, including case-led, workflow-led and other execution patterns.
Together they answer three questions: what exists, what may happen, and which rules apply.
Structured knowledge is written formally and on open standards, and it operates against systems of record rather than duplicating them. A rule about invoice matching refers to the invoice in the system that owns it. The system of record stays authoritative.
Business ontology is a component, not a synonym
A business ontology is the entity-and-action component within structured knowledge, which is in turn one half of the Map of Work. It defines the business entities an organization handles, their states, and the actions available on them.
It is not another name for the Map of Work. A Map of Work that contained only a business ontology would be missing its rules, its case plans, its operating knowledge and its record of decisions, which is to say most of what makes it useful.
Operating knowledge
Operating knowledge is the practical half of the Map of Work: how the organization’s people actually handle the situations the formal rules do not settle.
The supplier whose invoice variances are always acceptable. The precedent for expediting a part when a field team is up against a service level agreement. The reason a particular category of exception gets escalated rather than approved. Today this is oral tradition, held by whoever has been doing the work longest. In a Map of Work it is captured, attached to the work it applies to, and available to an agent preparing the same kind of case.
Operating knowledge guides. It does not govern. It informs agents and shapes recommendations, and it never overrides a business rule or a policy. That boundary is deliberate, and the best practices section explains why it has to hold.
The Decision Ledger
The Decision Ledger is the record of consequential decisions, carried inside the Map of Work. Each entry holds the recommendation that was made, the evidence behind it, the applicable rules and the version of the Map in force, the decision a person took and the reason they gave, the action that was executed, and what happened as a result.
It is not a knowledge layer, not an execution log, and not a replacement for audit. Its job is narrower and more useful than any of those: it is where the Map stops being a document, because it shows the specific points at which written policy and experienced judgment diverged. That is what gives a process owner evidence to decide whether a rule is wrong or an exception should stay exceptional.
The reason is the part that carries the value. Without it, the record shows what somebody decided but cannot tell an owner whether the rule should change.
What is the role of the cartographer?
The cartographer is the person accountable for building and maintaining an organization's Map of Work. The job is to observe how work actually happens, interview the people who do it, reconcile the contradictions between different accounts, and move changes into the Map deliberately, routing each proposed change to the owner accountable for that part of the work. The cartographer curates and routes and the process owners decide, so nothing enters the Map without a human owner's approval. The cartographer is a person, not software.
Who acts as a cartographer?
In most organizations, somebody already does much of this work. The cartographer is typically a business analyst, a process owner or a subject matter expert the organization already employs. It is a recognition of a role rather than a new hire.
What changes is that the role becomes accountable and explicit. Somebody’s name is attached to how a piece of work is described, and to every change in that description. In regulated work, compliance sits alongside the cartographer rather than reviewing the outcome afterward.
Daniel Dines named the role in The Work That Remains, among the roles that survive the handover of work to AI: mentors, culture-keepers, cartographers, process architects.
How organizational knowledge gets captured and governed
The most useful thing about the way a Map of Work is built is that it is not built in a workshop.
Formal structure can be documented deliberately. Operating knowledge mostly cannot, because the people who hold it do not experience it as knowledge. It surfaces inside real work instead. Each time an experienced person corrects an agent, rejects a proposal and says why, or edits a draft before accepting it, a piece of the unwritten description gets written down, attached to a real case rather than to a hypothetical one.
This is also newly practical. Capturing this kind of knowledge used to be prohibitively expensive, because it meant interviewing experts at length and turning transcripts into structure by hand. The same assistants that need the description turn out to be a good instrument for producing it: they can interview experts patiently, in plain conversation, on the expert’s own schedule, and draft a description from what they hear.
The governance rule holds throughout. Software gathers evidence and drafts proposals. The cartographer curates and routes them. The accountable owner of the affected process or Map component approves or rejects the change.
The rule worth adopting
Daniel Dines puts one constraint on the whole approach: no accountable Map owner, no agentic deployment.
If nobody in the organization will put their name to how a piece of work should run, that work is not ready to be run by software.
Map of Work use cases
A Map of Work is most valuable where work is consequential, where the path varies, and where experienced judgment currently fills the gap between the rule and the case in front of somebody.
Worked example: an invoice that exceeds its purchase order
The following example is illustrative. It shows how one mapped process operates within an organization-wide Map of Work; it is not an account of a specific customer deployment.
A freight supplier’s invoice arrives. The business ontology recognizes it as an invoice, tied to a supplier and to a purchase order. The matching step finds that the total is six percent above the purchase order, which is more than the business rules permit to be approved automatically. The case routes to a person in accounts payable.
Alongside the invoice, she sees something she has not had before: this supplier has exceeded its purchase order eleven times this year, and every one of those was approved and paid without dispute. She approves it and records her reason. Both the decision and the reason go into the Decision Ledger.
The reason is what makes the entry useful. Without it, the record would show what she decided but could not tell the process owner whether the rule itself should change.
Some weeks later the pattern is unambiguous. A single change is drafted, a variance threshold for this supplier, and the year’s decisions are replayed against it to show the process owner exactly which outcomes would have been different. The owner approves it. What existed only in one person’s memory is now policy, and the next invoice of that kind never reaches her desk.
Examples of processes represented in a Map of Work
Invoice and payment exceptions
Variance rules with owners and versions, precedent about which suppliers routinely run over, and a record of approvals and their reasons so thresholds can be revised on evidence.
Claims handling
Case plans for a claim’s lifecycle, plus operating knowledge about which patterns experienced adjusters treat as suspicious.
Disputes
A stable lifecycle with a path that may wait, change route, accumulate evidence or move between owners, described once and reused.
Onboarding
Business meaning and rules described once, so the same process can be run consistently and audited afterward.
Investigations
Evidence accumulated against a case, decision rights made explicit, and consequential decisions recorded with reasons.
Control integrity under deadline pressure
Visibility of the gap between the documented control and what actually happens at quarter end, as evidence for the owner rather than as an automatic change.
Service level exceptions in supply chain and field operations
Captured precedent for expediting, so an agent preparing the case starts from how the organization has actually handled it.
Benefits of a Map of Work
A Map of Work changes what an organization can safely hand to software, and what it retains when people move on.
Governed enterprise context
The description of the work is owned, versioned and approved, so the context an agent acts on is something the business has decided rather than something a model inferred.
Better context for AI agents
An agent can be briefed from business meaning, applicable rules and relevant precedent, instead of being prompted from scratch by whoever configured it.
Operating knowledge is preserved
What experienced people know is captured while they are still there. The organization stops getting measurably worse at its work when a key person takes leave, and stops forgetting when they resign.
Accountability and auditability
A consequential decision carries the recommendation, the evidence, the rule version applied, the person who decided, their reason, and the outcome. That is a materially better answer to “why did this happen” than a log of actions.
More reliable execution
Approved actions run deterministically under enforced permissions, and actions outside the boundary are stopped rather than attempted.
Faster time to production
Teams no longer have to anticipate every exception before a process goes live, because the loop is how exceptions are found. The controls still have to be clear on day one.
Improvement across the system of work
Evidence from real work can improve process definitions, rules and operating knowledge across the Map, not only the prompt of a single agent.
Reusable business meaning
One description of what an invoice or a claim means, resolved consistently by the people, agents, applications and automations that touch it.
The asset stays yours
The Map describes your business in your vocabulary, and it remains meaningful independently of the software that helped you build it.
How to build and maintain a Map of Work
Building the Map of Work is an operating discipline rather than a documentation project. Organizations typically grow the same enterprise Map process by process. For each process added or redesigned, six steps apply.
Name the accountable owner before anything else
Decide who owns the description of this work and who approves changes to it. Doing this first prevents the most common failure, which is a mapping exercise that produces an artifact nobody is responsible for. If no one will put their name to how the work should run, stop here.
Start with one consequential process, then expand the Map
Choose one consequential process as the next slice of the organization-wide Map: work that matters, varies, and relies on experienced judgment. Start narrowly and reach production, then add or improve other processes in the same Map. You are not creating a separate Map for each process, but rather adding to your existing one.
Write the formal description
Define the entities the work handles, the states they occupy and the actions available on them. Record the rules that must hold, each with a named owner and a version. Describe how a case moves through its lifecycle. Write it formally, on open standards, so it can be verified by a machine. Point at systems of record rather than copying their data.
Capture operating knowledge from the people who hold it
Interview the people who handle the exceptions, and interview them on their own schedule rather than in a workshop. Expect contradictions between accounts and resolve them rather than recording all of them. Keep operating knowledge clearly separate from rules: it guides, and it does not govern.
Capture decisions and reasons inside real work
The richest material is produced continuously by people doing the job: the correction, the rejection with a reason, the edit before acceptance. Capture the reason, not only the decision. A record of what was decided without why cannot tell an owner whether a rule should change.
Govern change deliberately, and treat the Map as living
Establish one route for change: a proposal supported by evidence, tested against past cases to show what would have been different, approved by the accountable owner, versioned and published. Never let observed behavior become policy automatically. Review on a schedule as well as on evidence, and keep compliance alongside the owner in regulated work.
What to expect it to feel like
A Map of Work is never finished, and that is the intended condition rather than a shortfall. It begins as a description of what the organization believes should happen, and live work steadily exposes where that belief was incomplete. An organization that treats its Map as a deliverable to be signed off will have a stale one within a year. An organization that treats it as an asset under active ownership will have one that becomes more accurate as it is used.
How UiPath supports the Map of Work
A Map of Work is a customer-owned asset, and an organization can build one without any particular vendor. UiPath builds capabilities that help create it, keep it current, and put it to work, within its Business Orchestration and Automation Platform.
UiPath Cartographer
UiPath Cartographer assists the human cartographer. It gathers evidence from documents, systems and interviews, works out the rules and the business ontology behind a process, exposes contradictions between accounts, and drafts changes to the Map.
It proposes. It does not approve and it does not publish. Every change is approved by the accountable owner.
UiPath Cartographer is generally available.
From approved Map to implementation
Once a mapped process, or a new version of it, is approved, its implementation details can be generated from the Map. Generating the documents is an export action on the mapped process: UiPath Cartographer produces the process definition document (PDD) for stakeholder sign-off and the task-by-task solution design document (SDD) for the builders. From that same approved process definition within the Map, coding agents build the relevant cases, workflows, automations and tests in Maestro and Studio, with evaluations gating each deploy.
Because downstream artifacts are generated from the relevant governed process definition in the Map, they stay aligned with it: change that definition and regenerate its downstream artifacts. Cartographer sits upstream of the build—here too it drafts and proposes, and a person approves.
Maestro and Maestro Case
Maestro provides process orchestration with durable execution: it holds state across time and systems, waits for approvals, resumes, retries and recovers, coordinating people, agents, robots and APIs inside one business process.
Maestro Case is the runtime authority for case-shaped work, owning the lifecycle, the stage graph, routing, timers, assignments and live state. The Map describes the reusable business meaning and points to the case implementation. It does not replace the case runtime.
Action Center
Action Center is the human-in-the-loop verification surface, which is where the “humans decide” part of the operating model actually happens. A reviewer sees the proposal, the evidence, the rules that were checked and the consequence, then approves, edits, rejects or escalates with a reason.
That reason is not administrative overhead. It is the material the Decision Ledger needs in order to be useful, which means human attention counts twice: first as a control before consequence, and then as evidence for improvement.
Decision Ledger
The Decision Ledger is the planned shared record of consequential decisions: the recommendation, the evidence, the applicable rules and Map version, the human decision and reason, the action executed, and the outcome. It is an artifact within the Map, and it is on the UiPath roadmap.
Supporting capabilities
Several existing parts of the platform contribute to building and using a Map of Work.
Automation Hub with Process, Task and Communications Mining supply discovery evidence: what happened in system logs, on desktops and in communications. Mining shows what happened, not why, so it informs the Map without replacing business analysis.
Data Fabric provides entity services: business-readable mappings over objects in systems of record, so an invoice or a claim has one view even when several systems hold fragments of it. The business ontology defines the reusable meaning those mappings implement, and systems of record stay authoritative.
Context Grounding retrieves the enterprise’s own policies, documents and precedents into an agent’s context under permission controls. Context Grounding supplies knowledge; the Map supplies governed work context.
The platform foundation enforces governance while work runs rather than documenting it afterward: Orchestrator for identity, scheduling and audit records, the Agent Registry for the agent fleet, the AI Trust Layer for model access, Guardrails to constrain behavior and Evals to test it.
Business ontology
A component, not a synonym. The business ontology provides the shared entity-and-action vocabulary used by structured knowledge across the Map’s processes. It defines the entities the business handles, their states and the actions on them. A Map of Work contains a business ontology; the two terms are not interchangeable.
Structured knowledge
The formal, machine-verifiable knowledge associated with the Map’s processes: the business ontology, the business rules, and the case and workflow definitions. It is the part a machine can verify.
Operating knowledge
The practical knowledge attached to the processes and situations it applies to within the Map of Work: precedents, examples and exception guidance. It guides agents and recommendations. It does not override rules or policy.
Decision Ledger
An artifact carried inside the Map of Work, holding consequential decisions and their reasons. It is not a knowledge layer, not an execution log, and not a replacement for audit.
The rails
The other half of the pair from The Work That Remains. The Map describes the work; the rails make the description binding by enforcing permissions, executing approved actions, recording what happened and stopping what is not allowed.
Process documentation
Process documents, diagrams and models describe how work was intended to operate at the moment they were written. A Map of Work describes how work runs now, is owned and versioned, and is readable by agents as well as people. Documentation is a picture; a Map of Work is a living asset.
Process mining
Complementary, and frequently confused with it. Mining shows what happened in system logs, on desktops and in communications. It does not show why. It informs the Map without replacing business analysis, and observed behavior is treated as evidence rather than as policy.
A process map
A process map describes the steps in one process. A Map of Work describes the business those processes run inside: the entities and their states, the rules and who owns them, decision rights, the operating knowledge behind exceptions, and the record of consequential decisions. The Map of Work contains the organization’s mapped processes together with the shared business meaning, rules, operating knowledge and decision history that connect them. It is not just a description of a process–it is much more than that.
Business process management
BPM disciplines and notation contribute to the formal half of the Map. A BPMN model can express a case plan or a workflow definition. What the Map adds is ownership, versioning, operating knowledge, and a record of decisions and reasons.
Context Grounding
Adjacent and distinct. Context Grounding retrieves an organization’s policies, documents and precedents into an agent’s context under permission controls. Context Grounding supplies knowledge; the Map of Work supplies governed work context.
Entity services
Entity services provide business-readable mappings over objects held in systems of record, so one invoice or claim has a single view. The business ontology defines the reusable business meaning those mappings implement. Systems of record remain authoritative.
Business Orchestration and Automation
The broader positioning the Map of Work sits inside. UiPath describes itself as a Business Orchestration and Automation Platform; within that, the Map of Work is the governed context layer that the orchestration and execution capabilities resolve business meaning from.
Best practices
Ten practices, drawn from how the concept is intended to operate.
Name the owner before you write anything. Accountability first, content second. No accountable Map owner, no agentic deployment.
Treat observed behavior as evidence, never as policy. If the record shows that everyone bypasses a control under deadline pressure, the answer is not to remove the control. A Map that redraws itself to match whatever people did would erode every control an organization has, one reasonable-looking change at a time.
Record the reason, not just the decision. A decision without a reason tells an owner what happened but not whether the rule should change. The reason is the part that makes the record worth keeping.
Keep agents proposing and people deciding. Software gathers evidence, exposes contradictions and drafts changes. A person approves them. Nothing enters the Map automatically.
Keep rules and operating knowledge clearly separate. Rules govern. Operating knowledge guides. Blurring the two is how a precedent quietly becomes a policy nobody approved.
Version everything, and let decisions cite versions. Rules carry named owners and versions, and a consequential decision should be able to cite the rule version it applied. Without versioning, an explanation a year later is guesswork.
Test changes against history before approving them. Replay past cases against a proposed change and show the owner which outcomes would have been different. It converts an argument about a rule into an inspection of consequences.
Point at systems of record instead of copying them. The Map describes meaning and rules. The data stays in the systems that own it, and those systems stay authoritative.
Keep compliance alongside the cartographer in regulated work. Beside them as the Map is drawn, not reviewing the outcome afterward.
Map, build, validate, then redesign roles. In that order. Organizations that map their work and immediately reduce the people who did it discover that they removed the people who knew where the Map was wrong.
Frequently asked questions
What is a Map of Work?
A Map of Work is an organization’s own governed description of how its work actually runs. It combines formal business structure, the operating knowledge experienced employees use to handle exceptions, and a record of consequential decisions. It gives AI agents the enterprise context they need to act reliably. A Map of Work is a concept and a customer-owned asset, not a product.
Is Map of Work a UiPath product?
No. Map of Work is a concept, not a product or a SKU, and it has no release date. It describes a customer-owned asset: your organization’s governed description of how its own work runs. UiPath builds capabilities that help organizations create a Map of Work, keep it current and put it to work, but the asset itself belongs to the customer.
Why do AI agents need a Map of Work?
Because a capable model knows nothing specific about how a particular company operates. It does not know what a payment approval means there, who may sign one, when to escalate, or what an auditor will later ask. Unlike a new employee, it does not learn this on the job. A Map of Work supplies that governed enterprise context so an agent can act reliably rather than plausibly.
What information does the Map of Work contain?
Across the organization’s mapped processes, the Map of Work contains structured knowledge, operating knowledge, and a record of consequential decisions. Structured knowledge holds the business ontology, the business rules with their owners and versions, and the case plans and workflow definitions. Operating knowledge holds captured precedents, examples and exception guidance. The Decision Ledger, carried inside the Map, holds consequential decisions and the reasons behind them.
What is a cartographer?
A cartographer is the person accountable for building and maintaining an organization’s Map of Work. They observe how work actually happens, interview the people who do it, resolve contradictions between accounts, and route proposed changes to the accountable owners then approve changes to the Map. It is usually a business analyst, process owner or subject matter expert the organization already has. The cartographer is a person, not software.
What is UiPath Cartographer?
UiPath Cartographer is the UiPath product that assists the human cartographer. It works process by process: gathering evidence, defining how the selected process runs, resolving the relevant business meaning and rules, exposing contradictions, and contributing the result to the organization’s Map. It proposes and never approves or publishes. Once the Map is approved, it generates the implementation from it. UiPath Cartographer is generally available.
What is a business ontology?
A business ontology is the entity-and-action component within the structured knowledge of a Map of Work. It defines the business entities an organization handles, such as an invoice, a claim or a dispute, the states those entities can occupy, and the actions that can be taken on them. A business ontology is a component of a Map of Work, not another name for it.
What is the Decision Ledger?
The Decision Ledger is the record of consequential decisions carried inside a Map of Work. Each entry holds the recommendation, the evidence, the applicable rules and Map version, the human decision and the reason for it, the action executed and the outcome. It is not a knowledge layer, not an execution log and not a replacement for audit. The Decision Ledger is on the UiPath roadmap.
What is operating knowledge?
Operating knowledge is the practical half of a Map of Work: the precedents, worked examples and exception guidance that experienced employees currently hold in their heads. It covers how people actually handle the situations formal rules do not settle. Once captured, operating knowledge guides AI agents and recommendations. It does not override business rules or policy.
What is structured knowledge in a Map of Work?
Structured knowledge is the formal half of a Map of Work, and the part a machine can verify. It contains the business ontology, the business rules with named owners and versions, and the case plans and workflow definitions. Together these define what exists in the business, what may happen, and which rules apply.
How does a Map of Work support enterprise AI?
A Map of Work supplies the governed context an AI agent needs to act inside a business. The agent is briefed from business meaning, applicable rules and relevant precedent rather than prompted from scratch. Decisions can cite the rule version applied, the boundary of the agent’s authority is explicit, and consequential decisions are recorded with their reasons so the description improves as work runs.
How does Map of Work relate to Business Orchestration and Automation?
UiPath describes itself as a Business Orchestration and Automation Platform. Within that positioning, the Map of Work is the governed context layer: the description of the business that orchestration and execution capabilities resolve business meaning from. Orchestration coordinates people, agents, robots and APIs inside individual business processes; the Map of Work is the organization-wide governed context from which each process resolves its definition, business meaning and applicable rules.
How is the Map of Work different from process mining?
Process mining shows what happened in system logs, on desktops and in communications. It does not show why. The Map of Work describes what the business handles, which rules apply, who may decide what, and how experienced people handle exceptions, and it is owned and versioned. Mining informs the Map of Work as evidence. Observed behavior is treated as evidence, never as policy.
How is the Map of Work different from process documentation?
Process documentation describes how work was intended to operate at the moment it was written, and it goes out of date quietly. The Map of Work describes how work runs now, has a named accountable owner, is versioned so that changes are deliberate, and is written formally enough for an AI agent to be briefed from it as well as for a person to read.
Who builds and maintains the Map of Work?
The organization does. The cartographer maintains the organization-wide Map, while accountable process, domain or policy owners approve changes to the parts they own. In regulated work, compliance sits alongside them. Software can gather evidence and draft proposals, but a Map of Work is never changed automatically: an accountable owner approves every change.
Where did the term Map of Work come from?
Daniel Dines, founder of UiPath, introduced the concept in his book The Work That Remains, published in 2026, where he describes “the map and the rails.” The map is the description of the business an agent can act inside. The rails are the machinery that executes what is approved and stops what is not.