KanBo Perspective

The Execution Record

Enterprises have digitized their transactions and left the coordination between them undigitized. That missing layer is the last unmodelled dataset in most organizations — and it has quietly become the binding constraint on everything they now want to do with AI.

The blind spot between systems

An enterprise data estate is usually a good one. ERP holds the transactions. CRM holds the customer relationships. PLM holds the product structure. HRIS holds the people. The warehouse joins them, the catalogue describes them, the lineage tooling traces them, and a competent data function governs the whole arrangement.

Now ask a question that sits between those systems.

A purchase order was raised on 3 March and approved on 27 March. ERP records both facts precisely. What it does not record is that the approval waited nineteen days on a legal review, that the review was owned by a named person in another department, that the objection concerned an indemnity clause, that a decision was taken to accept a modified wording, or that the same review step has now delayed eleven other orders this quarter.

Every one of those facts existed. Each was known to somebody. None of them is in any system that a query can reach. They were in an inbox, a chat thread, a meeting nobody minuted, a spreadsheet on a coordinator’s desktop, and — mostly — in people’s heads.

This is the blind spot. Enterprises have systems of record for outcomes and no system of record for how the outcome happened. And because the gap is invisible in every individual system, it is rarely named as a data problem at all. It gets named as a process problem, a culture problem, or an unfortunate fact about how organizations work.

It is a data problem. Specifically: the layer where work is coordinated has never been instrumented.

Why this layer was never captured

Three reasons, and none of them is negligence.

The tools were unstructured by design. Email, chat and meetings are extraordinarily successful coordination technologies precisely because they impose no schema. That is what makes them adoptable and what makes their output unusable as data. A message has a sender, a timestamp and a body. It has no owner, no status, no due date, and no relationship to anything else. The flexibility that makes email universal is the same property that makes it analytically empty.

Nobody owned it. Transactional data has an obvious custodian. Coordination data belongs to everyone and therefore to no one. It falls outside the CDO’s traditional scope because it was never conceived of as data, and outside IT’s scope because the tools that produce it are commodity productivity software.

The value only became legible recently. For most of the last two decades, the argument for capturing coordination was an argument about efficiency, and efficiency arguments lose to inertia. The argument changed when systems arrived that could reason over structured context — at which point the missing layer stopped being an inconvenience and became a prerequisite.

Why mining the chat logs does not work

The obvious response is to leave the tools alone and extract meaning afterwards. Point a model at the message archive, the meeting transcripts and the ticket text, and reconstruct what happened.

This fails, and it fails in a particular way that matters for a data function.

Inference is not resolution. A model reading a thread must infer who owns something, and inference produces a probability distribution over interpretations, not a fact. When structured data is wrong it is usually wrong loudly — a null, a constraint violation, a failed join. When inferred data is wrong it is wrong quietly and confidently, which is far worse in any context where the output feeds a decision.

Entity resolution is the hard part and it is unsolved in prose. “Get Marek to look at the Riyadh contract” requires resolving which Marek, which contract, whether looking at it is a review or an approval, and what state the item was in before and after. Every one of those is a join that structured capture performs for free and text mining performs badly.

Context is missing, not merely unstructured. The most important thing about a decision is often the alternative that was rejected and why. That rarely appears in writing anywhere. No amount of processing recovers information that was never expressed.

And the archive is the wrong shape legally. Mining employee communications for operational insight raises questions about purpose limitation, proportionality and — in much of Europe — works council agreement, that mining a purposefully-created work record does not. Capturing coordination in a system built for it is not only more accurate; it is a cleaner position to defend.

The conclusion is not that text is worthless. It is that the record has to be created structured, at the moment the work happens, by the people doing it — because that is the only moment when the structure is known for certain.

What execution data looks like when it is captured properly

This is where a work coordination platform stops being a productivity tool and starts being a data source. The distinction is not the interface. It is whether the output is typed.

The description that follows is of KanBo specifically, because that is the platform we build and the one these properties come from. Read it as a specification as much as a description — the section near the end turns it into a checklist you can apply to anything, including us.

In KanBo, a unit of work is an object with stable identity, not a message. It carries a responsible person as a relation to a named user rather than as a sentence. It carries contributors, dates, documents, custom fields with declared types, and a status.

The links between objects are typed too. Parent and child express decomposition; predecessor and successor express sequence; and both have cross-space variants, so a dependency between two departments is a first-class link rather than a note in someone’s plan. That means the record forms a navigable graph of how the work actually connects, rather than a collection of items in folders.

Obstacles are objects, not adjectives. A blocker carries a name, a reason and a responsible owner, and can be defined once and reused across the organization. This is a small design decision with a large consequence: it turns friction into a controlled vocabulary. “Waiting on external legal review” stops being a phrase people happen to repeat in different words and becomes a countable thing with an owner, a frequency and a downstream impact.

Activity is an event stream — actor, action, object, timestamp — attached to the work rather than to a channel. Documents are connected to the repositories the organization already uses rather than copied, so the file referenced by a decision is the file in the library, with its identity preserved.

Put together, this is a semantic layer over execution: entities, typed relations, controlled vocabularies, and an attributed event log. Not because anyone set out to build an ontology, but because coordination that is going to be governed has to be typed anyway.

Semantic reconciliation, done at source

The hardest problem in enterprise data is not capture. It is agreement on meaning. Two departments both report “complete” and mean different things; harmonizing them is a project that takes a year and is stale before it lands.

The mechanism that avoids this is worth understanding in detail, because it generalizes.

Each space in KanBo defines its own statuses in its own words — a sales team runs Prospecting, Discovery, Proposal, Negotiation, Closed Won; an engineering team runs something else entirely. Every one of those local names is assigned one of five types: Information, Not started, In progress, Completed, Cancelled.

The local vocabulary is therefore never taken away, and the shared meaning is never inferred. The mapping between them is explicit, maintained by the people who own the vocabulary, and updated by them at the moment they change it. Aggregation across the organization is exact without anyone being asked to speak head office’s language.

This is semantic reconciliation performed at source rather than downstream. Anyone who has run a master data programme will recognize what that is worth. The alternative — a central mapping table maintained by people who do not own the underlying processes — is the failure mode that consumes years of data-function credibility.

The same principle appears throughout: thin shared structure, thick local freedom. It is also the reason the resulting dataset is consistent enough to query without having flattened the organization to make it so.

Born inside a permission model

Most enterprise datasets have governance retrofitted. They are created by an application, copied to a warehouse, and then wrapped in access controls designed by a different team, at a different granularity, some months later.

Execution data captured this way arrives already governed, and the mechanism deserves attention because it is the answer to the question every CDO asks before any other: if we open this to another system or to a model, what can it see?

Access in KanBo runs across six permission levels and can be granted to groups that contain other groups, so entitlement mirrors organizational structure. The relevant part for integration is what happens when the consumer is not a person.

A service connecting through the API authenticates with a JWT signed by the organization’s own X.509 certificate. It can be configured to act as a specific user — in which case it sees exactly what that user sees, no more. A service identity that is not mapped to a user holds no permissions at all until a role explicitly grants them. Access is deny-by-default, and the same entitlement model governs a Power BI refresh, a Power Automate flow, a UiPath robot and an AI agent connected over MCP.

That is a materially different position from the usual one, where “the integration account” is a superuser everybody has quietly stopped thinking about. Here the answer to what a machine consumer can see is not a policy document. It is the same access control, applied to a different kind of consumer.

Deployment follows the same logic. The platform runs on-premises, on the organization’s own Azure tenant, or in a hybrid arrangement — which matters because execution data is among the most sensitive material an organization holds. It describes decisions, disputes and internal friction. The question of where it resides is not a preference.

What becomes answerable

Abstract arguments about data assets are easy to nod at. Here is the concrete payoff: a set of questions most large organizations cannot currently answer, and can answer once execution is instrumented.

Where does work wait? Transactional systems record where work happens. Nothing records where it waits. In most processes the waiting dominates the doing, and it is invisible.

Which obstacles recur, and who owns them? If blockers are named objects with owners, the question “what is the single most expensive recurring obstacle in this organization, and whose decision would remove it” becomes a query rather than an opinion.

How long does anything actually take? Not milestone to milestone, which your systems already know, but arrival to decision, request to owner, escalation to resolution.

When a date moves, what moves with it? With dependencies recorded as links including across departments, this is a traversal. Without them, it is a meeting.

Which interfaces between departments are systematically underestimated? The cross-space dependency data answers this directly, and the answer is usually not where people assume.

Who decided this, when, and on what basis? For any decision, at any point in the past, without a reconstruction exercise.

How much of a policy is actually in force? Obligations with owners, dates and states, rather than a policy document and a hope.

None of these require a modelling project. They are properties of a record that was captured in the right shape to begin with.

The real structure of your organization

There is a second-order finding hiding in this data, and it is the one that tends to interest executives most.

Melvin Conway observed in 1968 that organizations produce designs which mirror their own communication structures. The observation is usually cited about software architecture, but it is a claim about organizations, and it has always had a practical problem: nobody could measure the communication structure. The org chart describes the intended one. The real one lives in who actually talks to whom about what, and it has never been visible.

Cross-department dependency data makes it visible for the first time in a form that is neither a survey nor a guess. Which functions are genuinely coupled. Which reorganization moved boxes without moving the coupling. Which department is a hub that nobody planned. Which “independent” workstreams are in fact one workstream with two budgets.

Treat this finding carefully — it is organizationally charged. But it is real, it is derived from work people actually did rather than from what they reported, and there is no other instrument that produces it.

Why AI made this urgent rather than interesting

The case above would have been true five years ago and would have lost to other priorities. What changed is that the missing layer became a prerequisite for something the organization now urgently wants.

An AI assistant or agent can only reason about what is written down. Ask one to assess whether a programme is at risk, prepare a decision, or summarize a situation, and it needs purpose, ownership, history, constraints, dependencies, and what has already been tried and rejected. That is precisely the material that lives informally.

This is the unglamorous explanation for a pattern many organizations are living through: AI pilots that perform impressively on documents and stall completely on operations. The model is not the limitation. It is being asked to reason about a state of work that was never recorded. What it produces is fluent, confident and unverifiable — the worst possible output in an operational context, because checking it costs more than doing the work.

Once execution is captured as typed data, the situation inverts. An agent connected over MCP reads the current state — this card, its owner, its status type, its unfinished predecessor, its named blocker and who owns it — and reasons over resolved facts. Its output can be checked against the record because the record exists. And it acts under an identity whose permissions you set, which is what makes the whole thing deployable rather than merely demonstrable.

The sequence matters, and most organizations attempt it backwards. Instrument the execution layer first. Introduce the agent second. An agent deployed onto an undocumented process consumes the credibility that the next attempt will need.

The loop: out, and back in

None of this argues for another silo. The value compounds when the traffic runs both ways.

Outward, the execution record joins the estate through the interfaces the organization already uses: OData directly into Power BI, the JSON API into the warehouse and into models, MCP for AI systems. It reconciles against the transactional systems it sits between — filling in exactly the gap between the milestones ERP records.

Inward, other systems create and update work. A ticket raised elsewhere, an exception thrown by an operational system, a supplier message, a scheduled obligation from a compliance calendar — any of these can create a card with an owner and a date through the API, through Power Automate, UiPath or Nintex, or by email into a space with controlled permissions over who may do so. An agent can do the same, within its granted entitlements.

The resulting loop is the point. Systems of record trigger the work. The work is coordinated where people already are, in a structure they control. The execution data returns to the estate as a governed asset. Nothing is re-keyed, and nothing is self-reported.

What it takes to produce this, and where it exists

A reader who accepts the argument to this point is entitled to a direct answer to the obvious question: what actually produces this data? Most tools that sit in this space do not, and the reasons are specific enough to make a usable checklist.

Is the unit of work a typed object or a message? If the primary artefact is a message, thread or document, the output is prose and everything above collapses back into inference.

Are relationships between work items first-class, and do they cross organizational boundaries? Sub-tasks within a project are not enough. The valuable dependencies are the ones between departments, and they have to be links rather than references in a text field.

Are obstacles objects with owners? If “blocked” is a flag or a comment rather than a named, reusable entity with a responsible person, the single most valuable analysis — what recurs and whose decision would remove it — is unavailable.

Can local vocabulary map to shared meaning without being replaced? If the platform forces one global status set, adoption suffers and the data thins. If it allows free-text statuses with no mapping, nothing aggregates. The requirement is both: local names, explicitly typed.

Does the permission model extend to machine consumers? Ask what an integration account can see. If the honest answer is “everything,” the dataset cannot be opened to models or to other systems without building a governance layer on top of it first.

Is the data reachable without a UI, through interfaces you already govern? An export button is not an interface. Neither is a reporting module.

Can it run where your data has to live? Execution data describes internal disputes, decisions and friction. For many organizations, where it resides is a constraint rather than a preference.

KanBo meets these because they are consequences of what it was built to be rather than a data feature added later. It is a work coordination platform for large organizations — spaces, cards, relations, statuses, documents, permissions — that has been developed for fifteen years against enterprise governance requirements. Typed objects, cross-space dependencies, blockers as owned entities, per-space statuses mapped to five fixed types, six permission levels extending to service identities, a JSON API secured by the customer’s own certificate, OData, MCP, and on-premises or hybrid deployment are all properties of that design.

The result is a platform with two faces. Business users see work coordination: their spaces, their process, their documents, their language. The rest of the organization sees a structured, permissioned source of execution data that other systems and AI agents can read and write under governed identities. Neither face is a by-product of the other. They are the same record, viewed by different kinds of consumer.

That is the claim, and the checklist above is deliberately written so that it can be used against us as easily as against anyone else.

What this means for the CDO’s mandate

If the argument holds, execution is a new data domain, and it should be treated with the same seriousness as any other rather than as a by-product of a productivity tool.

That means the ordinary disciplines apply. It needs a named owner. It needs a documented model — the entity types, the relations, the controlled vocabularies, and the mapping between local status names and shared types. It needs retention rules, which are more nuanced here than elsewhere because the evidentiary value and the privacy exposure both rise with age. It needs a stated purpose, and the discipline to hold to it.

That last point deserves emphasis. Execution data is behavioural. It describes what people did, when, and how long they took. In much of Europe that makes it a works council matter before it makes it a dashboard, and the right sequence is to have the conversation before the first report exists rather than after someone has seen one. The defensible position is specific and worth stating plainly: the record exists to make work legible, not people. The access model is what keeps it that way, and the purpose limitation should be written down.

There is a related opportunity. This is one of the few datasets where the CDO can be a practitioner rather than an architect. Running the data governance programme itself in the platform — obligations, owners, decisions, remediation, evidence — means the CDO learns what the record contains by using it. Specifying an extract from a system you have never used produces a schema that answers last year’s questions.

Honest limits

Four, and they are worth stating before anyone builds a business case.

The dataset is only as rich as adoption. Execution data is a by-product of real work, which is what makes it truthful and also what makes it thin wherever the platform is not genuinely used. Judge it from a domain that is actually working in it, not from a pilot where people are updating a system alongside their real one.

This is not a data governance platform. It does not catalogue, trace lineage, profile quality or manage master data. It belongs alongside those tools, not instead of them. Any vendor implying otherwise should be treated accordingly.

It is not a substitute for process mining where the events already exist. If a process runs end to end inside a transactional system, that system’s event log is the better source. The gap this addresses is the coordination between systems, which is precisely where process mining runs out of events.

And the measurement will be gamed if you turn it into a target. Goodhart’s law is not a caution here, it is a prediction: the week that blocker counts become a departmental KPI is the week people stop naming blockers. The value of this data comes from being a faithful by-product of work. Use it to find out where the organization is stuck. The moment it becomes a performance instrument, it stops being either.

How to start

Not with a rollout, and not with a data project.

Take one programme with heavy cross-departmental dependencies — the hard one, not the easy one, because that is where the difference shows within weeks — and run it in KanBo. Obligations as cards with named owners and dates. Dependencies recorded as links, including the ones that cross departments. Recurring obstacles as named blockers with owners. Documents connected to the library you already use rather than copied into a new one.

Give it a quarter. Then do three things.

Connect the OData feed to Power BI and look at what you now have that you did not have before — particularly the waiting, and the recurring blockers. Ask an assistant, over MCP, a question you could previously only answer by asking a person, and check the answer against the record. And write down the data model as it actually emerged, rather than as anyone would have specified it in advance.

By the end of that quarter you will know two things with evidence rather than argument: whether the record is rich enough to be worth governing, and which relations in it actually carry the signal.

FAQ

Is this analytics on a project management tool?

No. A project management tool produces reports about its own contents. The argument here is that the coordination layer, captured as typed data, is an enterprise data asset in its own right — one that joins the warehouse, feeds models, reconciles against transactional systems and answers questions no existing system can.

How is this different from process mining?

Process mining reconstructs processes from event logs that transactional systems already produce. It works well where the process runs inside those systems and runs out of material exactly where the process crosses between them — which is where coordination happens and where the waiting is. The two are complementary rather than competing.

Could we not get this from our existing collaboration suite’s audit logs?

Those logs record that a message was sent and a file was opened. They do not record who is responsible for what, what depends on what, what is blocking, or what was decided. The distinction is between activity and state. Activity logs describe motion; execution data describes structure.

What is the actual interface story?

A JSON API with read and action method families, authenticated by JWT tokens signed with your own X.509 certificate; OData for Power BI; MCP for AI systems; and supported integrations for Power Automate, UiPath, Nintex, Teams, Outlook and Active Directory group synchronization. Deployment on-premises, on your own Azure tenant, or hybrid.

What can an integration or an agent see?

Only what the identity it acts as is permitted to see. A service can be mapped to a specific user and inherits exactly that user’s permissions; an unmapped service identity holds none until a role grants them. The same six permission levels govern machines and people.

Where should a CDO start if they are sceptical?

With the question that opened this article. Pick one recent decision that took longer than it should have, and try to establish from your existing systems who owned each step, what it waited on, and why. The difficulty of that exercise is the size of the gap.

Written by KanBo. We build the work coordination platform described above, which makes this an argument we have an interest in — hence the checklist rather than a feature list. The questions in it are worth asking of any candidate, including ours.