Chief Data Officer
Your organization has a system of record for transactions, for customers, for products, for people. It has none for execution. ERP knows a purchase order was raised and approved. It does not know that it waited eleven days on a legal review, who owned that review, what the objection was, or that the same obstacle has now delayed nine others. That information exists — in inboxes, chat threads, spreadsheets and people’s heads — where nothing can query it and nothing can govern it. KanBo has two faces. For business users it is a governed work coordination platform. For the rest of the organization it is a structured, permissioned source of execution data, reachable by API, by OData, and — increasingly the point — by AI agents through MCP.
The execution record as a data asset
Coordination data has an unusual property: it is generated as a by-product of people doing their work, not by anyone filling in a form about their work. That makes it substantially more truthful than self-reported status, and it is why it is worth treating as an asset rather than as application exhaust. What it contains is what every operational question actually turns on. Who is responsible. What depends on what, across which departments. What is blocking, who owns the obstacle, how often that obstacle recurs. What was decided, when, by whom, and on what basis. How long things really take between the milestones your other systems record. For a CDO the significance is threefold. It is a dataset the organization does not have. It is born inside a permission model rather than having governance retrofitted to it. And it is the context layer that AI systems need and currently cannot reach.
Semantic Work Objects
Meaning carried by structure
Cards, people, documents and dependencies are typed objects with typed links between them. Anything reading the record resolves a relation instead of inferring meaning from prose.
API and OData
Consumable by systems you already run
A JSON API secured by your own certificate, OData straight into Power BI, and supported integrations for Power Automate, UiPath, Nintex, Teams, Outlook and Active Directory.
MCP
The context layer AI has been missing
Purpose, ownership, history and dependencies are what a model needs and what is never written down. MCP gives agents the execution record, under the same rules as a person.
Identity and Permissions
Machine access inherits your permission model
A service can act as a named user and holds exactly that user’s permissions. An unmapped service identity holds none until a role grants it. Deny by default.
A day in the life of a Chief Data Officer
Two halves, and the order matters. The CDO uses the platform before they consume the data it produces — which is how they come to know what is in it.
Step 1 — Your own programme runs here
The obligations from the latest policy, the open classification disputes, the AI use cases waiting on assessment, the remediation items sitting with system owners in three other departments. Each is a card with an owner, a date and its dependencies. You start the day on exceptions — what is overdue, what is blocked, what the platform has flagged as a conflict between dates and dependencies — rather than on a status pack describing last Thursday. Communication belongs to the same objects. The discussion that produced a decision sits on the card that carries it, so the reasoning survives the people involved.
Step 2 — You learn what the record contains by working in it
This is the half most data leaders skip, and it is the half that determines whether the rest works. Specifying what to extract from a system you have never used produces a schema that answers last year’s questions. A quarter of running your own governance programme in KanBo tells you exactly which relations matter — that blocker ownership is more predictive than status, that the cross-department dependencies are where the time actually goes. You end up defining the extract as a practitioner rather than as an architect.
Step 3 — The record flows outward
The same objects reach the rest of the estate without an export step: OData into Power BI, the JSON API into the warehouse and the models, MCP for AI systems that need to reason about the current state of work. Nothing is re-keyed and nothing is self-reported, because the data was produced by people doing the work rather than by anyone describing it afterwards. Execution data now joins the datasets you already govern, and reconciles against the transactional systems it sits between — the gap between the milestones ERP records and what happened in between.
Step 4 — And other systems write back in
The traffic runs both ways. A ticket raised elsewhere, a supplier message, a signal from an operational system can create or update a card through the API, Power Automate, UiPath or Nintex, or arrive by email into a space as a structured item with an owner and a date. An agent connected through MCP can do the same, acting as an identity whose permissions you control. The loop closes: the systems of record trigger the work, the work is coordinated where people already are, and the resulting execution data returns to the estate as a governed asset.
Governing what you do not own
A CDO’s authority is real but narrow. You can set a standard; you rarely control the systems, budgets or people that make it true. Governance therefore succeeds or fails on whether the organization can see the same picture you do. James C. Scott’s study of how states make societies legible is the useful warning. Central authorities impose simplified schemas so things can be measured and administered — and the simplification routinely destroys the local knowledge that made the system work. Enterprise data governance faces exactly this trade-off. Standardize too little and nothing aggregates; standardize too much and domains quietly maintain a second, real version of their world. The design conclusion is not moderation for its own sake. It is that the shared layer should be thin and structural — ownership, dependency, status type, evidence — while local vocabulary and process stay local. That is also, not coincidentally, what makes the resulting dataset consistent enough to query.
Spaces and Relations
A policy is a commitment, not a document
A policy is a commitment, not a document Every obligation becomes a card with a named owner, a date and its dependencies — including the ones owned by departments you do not manage.
Comments and Activity
Why, recorded where the what is
Classification disputes, access exceptions and AI approvals are decided on the card that carries them. Two years later the reasoning is still attached to it.
History and Searchs
The version that is actually in force
Documents are connected to your existing repositories rather than copied, so the policy on the card is the policy in the library — and a moved library is repaired, not broken.
History and Search
What did you know, and when
Activity history stays on the work and search reaches inside it. Auditors and second-line functions get reader access rather than a compiled pack.
Get started today with
KanBo!
KanBo is a work coordination software designed to help self-organizing teams work smarter and faster. You can see KanBo in action by accessing our Sandbox demonstration environment.
Q&A
Have a question? We’ve got answers!
No, and the distinction matters. KanBo does not catalogue data, trace lineage, profile quality or manage master data, and it belongs alongside the tools that do. It contributes in two different ways: it runs the governance programme itself — obligations, owners, decisions, remediation, evidence — and it produces a dataset about how the organization executes that no other system holds.
Typed entities with stable identity — cards, spaces, people, documents, labels, custom fields — and typed links between them: parent and child, predecessor and successor, including across departments. Responsibility is a relation to a named person rather than a sentence. A blocker is a reusable object with a name, a reason and an owner, which makes it a controlled vocabulary of obstacles rather than a phrase people repeat. Every local status name is mapped to one of five types, so semantic reconciliation happens at source, maintained by the people who own the vocabulary, instead of in a central mapping project that is stale the month it finishes. All of it reachable through the JSON API, through OData for Power BI, and through MCP for AI systems. The practical difference for anything consuming it: prose has to be interpreted, and interpretation fails silently. This record is already resolved.
Only what the identity they act as is permitted to see. A service can be configured to run as a specific user and inherits exactly that user’s permissions; a service identity that is not mapped to a user begins with none and gains only what a role grants. The same six permission levels apply to integrations and agents as to people.
It should be treated that way from the start, particularly in jurisdictions with works council involvement. The record exists to make work legible, not people — and the access model is the control that keeps it so. It is a conversation worth having before the first dashboard, not after it.
Honest answer: as good as adoption. The execution record is a by-product of real work, which is what makes it truthful and also what makes it thin where the platform is not used. Start with one programme rather than a rollout, and judge the dataset from a domain that is genuinely working in it.
At organization level, with access governance and deployment decided centrally — including on-premises and hybrid arrangements — which is usually the first question your security colleagues will ask, and the reason coordination data does not have to leave your estate to be useful.
Chief Data Officer
Your organization has a system of record for transactions, for customers, for products, for people. It has none for execution. ERP knows a purchase order was raised and approved. It does not know that it waited eleven days on a legal review, who owned that review, what the objection was, or that the same obstacle has now delayed nine others. That information exists — in inboxes, chat threads, spreadsheets and people’s heads — where nothing can query it and nothing can govern it. KanBo has two faces. For business users it is a governed work coordination platform. For the rest of the organization it is a structured, permissioned source of execution data, reachable by API, by OData, and — increasingly the point — by AI agents through MCP.
The execution record as a data asset
Coordination data has an unusual property: it is generated as a by-product of people doing their work, not by anyone filling in a form about their work. That makes it substantially more truthful than self-reported status, and it is why it is worth treating as an asset rather than as application exhaust. What it contains is what every operational question actually turns on. Who is responsible. What depends on what, across which departments. What is blocking, who owns the obstacle, how often that obstacle recurs. What was decided, when, by whom, and on what basis. How long things really take between the milestones your other systems record. For a CDO the significance is threefold. It is a dataset the organization does not have. It is born inside a permission model rather than having governance retrofitted to it. And it is the context layer that AI systems need and currently cannot reach.
Semantic Work Objects
Meaning carried by structure
Cards, people, documents and dependencies are typed objects with typed links between them. Anything reading the record resolves a relation instead of inferring meaning from prose.
API and OData
Consumable by systems you already run
A JSON API secured by your own certificate, OData straight into Power BI, and supported integrations for Power Automate, UiPath, Nintex, Teams, Outlook and Active Directory.
MCP
The context layer AI has been missing
Purpose, ownership, history and dependencies are what a model needs and what is never written down. MCP gives agents the execution record, under the same rules as a person.
Identity and Permissions
Machine access inherits your permission model
A service can act as a named user and holds exactly that user’s permissions. An unmapped service identity holds none until a role grants it. Deny by default.
A day in the life of a Chief Data Officer
Two halves, and the order matters. The CDO uses the platform before they consume the data it produces — which is how they come to know what is in it.
Step 1 — Your own programme runs here
The obligations from the latest policy, the open classification disputes, the AI use cases waiting on assessment, the remediation items sitting with system owners in three other departments. Each is a card with an owner, a date and its dependencies. You start the day on exceptions — what is overdue, what is blocked, what the platform has flagged as a conflict between dates and dependencies — rather than on a status pack describing last Thursday. Communication belongs to the same objects. The discussion that produced a decision sits on the card that carries it, so the reasoning survives the people involved.
Step 2 — You learn what the record contains by working in it
This is the half most data leaders skip, and it is the half that determines whether the rest works. Specifying what to extract from a system you have never used produces a schema that answers last year’s questions. A quarter of running your own governance programme in KanBo tells you exactly which relations matter — that blocker ownership is more predictive than status, that the cross-department dependencies are where the time actually goes. You end up defining the extract as a practitioner rather than as an architect.
Step 3 — The record flows outward
The same objects reach the rest of the estate without an export step: OData into Power BI, the JSON API into the warehouse and the models, MCP for AI systems that need to reason about the current state of work. Nothing is re-keyed and nothing is self-reported, because the data was produced by people doing the work rather than by anyone describing it afterwards. Execution data now joins the datasets you already govern, and reconciles against the transactional systems it sits between — the gap between the milestones ERP records and what happened in between.
Step 4 — And other systems write back in
The traffic runs both ways. A ticket raised elsewhere, a supplier message, a signal from an operational system can create or update a card through the API, Power Automate, UiPath or Nintex, or arrive by email into a space as a structured item with an owner and a date. An agent connected through MCP can do the same, acting as an identity whose permissions you control. The loop closes: the systems of record trigger the work, the work is coordinated where people already are, and the resulting execution data returns to the estate as a governed asset.
Governing what you do not own
A CDO’s authority is real but narrow. You can set a standard; you rarely control the systems, budgets or people that make it true. Governance therefore succeeds or fails on whether the organization can see the same picture you do. James C. Scott’s study of how states make societies legible is the useful warning. Central authorities impose simplified schemas so things can be measured and administered — and the simplification routinely destroys the local knowledge that made the system work. Enterprise data governance faces exactly this trade-off. Standardize too little and nothing aggregates; standardize too much and domains quietly maintain a second, real version of their world. The design conclusion is not moderation for its own sake. It is that the shared layer should be thin and structural — ownership, dependency, status type, evidence — while local vocabulary and process stay local. That is also, not coincidentally, what makes the resulting dataset consistent enough to query.
Spaces and Relations
A policy is a commitment, not a document
A policy is a commitment, not a document Every obligation becomes a card with a named owner, a date and its dependencies — including the ones owned by departments you do not manage.
Comments and Activity
Why, recorded where the what is
Classification disputes, access exceptions and AI approvals are decided on the card that carries them. Two years later the reasoning is still attached to it.
History and Searchs
The version that is actually in force
Documents are connected to your existing repositories rather than copied, so the policy on the card is the policy in the library — and a moved library is repaired, not broken.
History and Search
What did you know, and when
Activity history stays on the work and search reaches inside it. Auditors and second-line functions get reader access rather than a compiled pack.
Get started today with KanBo!
KanBo is a work coordination software designed to help self-organizing teams work smarter and faster. You can see KanBo in action by accessing our Sandbox demonstration environment.
Q&A
Have a question? We’ve got answers!
No, and the distinction matters. KanBo does not catalogue data, trace lineage, profile quality or manage master data, and it belongs alongside the tools that do. It contributes in two different ways: it runs the governance programme itself — obligations, owners, decisions, remediation, evidence — and it produces a dataset about how the organization executes that no other system holds.
Typed entities with stable identity — cards, spaces, people, documents, labels, custom fields — and typed links between them: parent and child, predecessor and successor, including across departments. Responsibility is a relation to a named person rather than a sentence. A blocker is a reusable object with a name, a reason and an owner, which makes it a controlled vocabulary of obstacles rather than a phrase people repeat. Every local status name is mapped to one of five types, so semantic reconciliation happens at source, maintained by the people who own the vocabulary, instead of in a central mapping project that is stale the month it finishes. All of it reachable through the JSON API, through OData for Power BI, and through MCP for AI systems. The practical difference for anything consuming it: prose has to be interpreted, and interpretation fails silently. This record is already resolved.
Only what the identity they act as is permitted to see. A service can be configured to run as a specific user and inherits exactly that user’s permissions; a service identity that is not mapped to a user begins with none and gains only what a role grants. The same six permission levels apply to integrations and agents as to people.
It should be treated that way from the start, particularly in jurisdictions with works council involvement. The record exists to make work legible, not people — and the access model is the control that keeps it so. It is a conversation worth having before the first dashboard, not after it.
Honest answer: as good as adoption. The execution record is a by-product of real work, which is what makes it truthful and also what makes it thin where the platform is not used. Start with one programme rather than a rollout, and judge the dataset from a domain that is genuinely working in it.
At organization level, with access governance and deployment decided centrally — including on-premises and hybrid arrangements — which is usually the first question your security colleagues will ask, and the reason coordination data does not have to leave your estate to be useful.
Chief Data Officer
Your organization has a system of record for transactions, for customers, for products, for people. It has none for execution. ERP knows a purchase order was raised and approved. It does not know that it waited eleven days on a legal review, who owned that review, what the objection was, or that the same obstacle has now delayed nine others. That information exists — in inboxes, chat threads, spreadsheets and people’s heads — where nothing can query it and nothing can govern it. KanBo has two faces. For business users it is a governed work coordination platform. For the rest of the organization it is a structured, permissioned source of execution data, reachable by API, by OData, and — increasingly the point — by AI agents through MCP.
The execution record as a data asset
Coordination data has an unusual property: it is generated as a by-product of people doing their work, not by anyone filling in a form about their work. That makes it substantially more truthful than self-reported status, and it is why it is worth treating as an asset rather than as application exhaust. What it contains is what every operational question actually turns on. Who is responsible. What depends on what, across which departments. What is blocking, who owns the obstacle, how often that obstacle recurs. What was decided, when, by whom, and on what basis. How long things really take between the milestones your other systems record. For a CDO the significance is threefold. It is a dataset the organization does not have. It is born inside a permission model rather than having governance retrofitted to it. And it is the context layer that AI systems need and currently cannot reach.
Semantic Work Objects
Meaning carried by structure
Cards, people, documents and dependencies are typed objects with typed links between them. Anything reading the record resolves a relation instead of inferring meaning from prose.
API and OData
Consumable by systems you already run
A JSON API secured by your own certificate, OData straight into Power BI, and supported integrations for Power Automate, UiPath, Nintex, Teams, Outlook and Active Directory.
MCP
The context layer AI has been missing
Purpose, ownership, history and dependencies are what a model needs and what is never written down. MCP gives agents the execution record, under the same rules as a person.
Identity and Permissions
Machine access inherits your permission model
A service can act as a named user and holds exactly that user’s permissions. An unmapped service identity holds none until a role grants it. Deny by default.
A day in the life of a Chief Data Officer
Two halves, and the order matters. The CDO uses the platform before they consume the data it produces — which is how they come to know what is in it.
Step 1 — Your own programme runs here
The obligations from the latest policy, the open classification disputes, the AI use cases waiting on assessment, the remediation items sitting with system owners in three other departments. Each is a card with an owner, a date and its dependencies. You start the day on exceptions — what is overdue, what is blocked, what the platform has flagged as a conflict between dates and dependencies — rather than on a status pack describing last Thursday. Communication belongs to the same objects. The discussion that produced a decision sits on the card that carries it, so the reasoning survives the people involved.
Step 2 — You learn what the record contains by working in it
This is the half most data leaders skip, and it is the half that determines whether the rest works. Specifying what to extract from a system you have never used produces a schema that answers last year’s questions. A quarter of running your own governance programme in KanBo tells you exactly which relations matter — that blocker ownership is more predictive than status, that the cross-department dependencies are where the time actually goes. You end up defining the extract as a practitioner rather than as an architect.
Step 3 — The record flows outward
The same objects reach the rest of the estate without an export step: OData into Power BI, the JSON API into the warehouse and the models, MCP for AI systems that need to reason about the current state of work. Nothing is re-keyed and nothing is self-reported, because the data was produced by people doing the work rather than by anyone describing it afterwards. Execution data now joins the datasets you already govern, and reconciles against the transactional systems it sits between — the gap between the milestones ERP records and what happened in between.
Step 4 — And other systems write back in
The traffic runs both ways. A ticket raised elsewhere, a supplier message, a signal from an operational system can create or update a card through the API, Power Automate, UiPath or Nintex, or arrive by email into a space as a structured item with an owner and a date. An agent connected through MCP can do the same, acting as an identity whose permissions you control. The loop closes: the systems of record trigger the work, the work is coordinated where people already are, and the resulting execution data returns to the estate as a governed asset.
Governing what you do not own
A CDO’s authority is real but narrow. You can set a standard; you rarely control the systems, budgets or people that make it true. Governance therefore succeeds or fails on whether the organization can see the same picture you do. James C. Scott’s study of how states make societies legible is the useful warning. Central authorities impose simplified schemas so things can be measured and administered — and the simplification routinely destroys the local knowledge that made the system work. Enterprise data governance faces exactly this trade-off. Standardize too little and nothing aggregates; standardize too much and domains quietly maintain a second, real version of their world. The design conclusion is not moderation for its own sake. It is that the shared layer should be thin and structural — ownership, dependency, status type, evidence — while local vocabulary and process stay local. That is also, not coincidentally, what makes the resulting dataset consistent enough to query.
Spaces and Relations
A policy is a commitment, not a document
A policy is a commitment, not a document Every obligation becomes a card with a named owner, a date and its dependencies — including the ones owned by departments you do not manage.
Comments and Activity
Why, recorded where the what is
Classification disputes, access exceptions and AI approvals are decided on the card that carries them. Two years later the reasoning is still attached to it.
History and Searchs
The version that is actually in force
Documents are connected to your existing repositories rather than copied, so the policy on the card is the policy in the library — and a moved library is repaired, not broken.
History and Search
What did you know, and when
Activity history stays on the work and search reaches inside it. Auditors and second-line functions get reader access rather than a compiled pack.
Get started today with KanBo!
KanBo is a work coordination software designed to help self-organizing teams work smarter and faster. You can see KanBo in action by accessing our Sandbox demonstration environment.
Q&A
Have a question? We’ve got answers!
No, and the distinction matters. KanBo does not catalogue data, trace lineage, profile quality or manage master data, and it belongs alongside the tools that do. It contributes in two different ways: it runs the governance programme itself — obligations, owners, decisions, remediation, evidence — and it produces a dataset about how the organization executes that no other system holds.
Typed entities with stable identity — cards, spaces, people, documents, labels, custom fields — and typed links between them: parent and child, predecessor and successor, including across departments. Responsibility is a relation to a named person rather than a sentence. A blocker is a reusable object with a name, a reason and an owner, which makes it a controlled vocabulary of obstacles rather than a phrase people repeat. Every local status name is mapped to one of five types, so semantic reconciliation happens at source, maintained by the people who own the vocabulary, instead of in a central mapping project that is stale the month it finishes. All of it reachable through the JSON API, through OData for Power BI, and through MCP for AI systems. The practical difference for anything consuming it: prose has to be interpreted, and interpretation fails silently. This record is already resolved.
Only what the identity they act as is permitted to see. A service can be configured to run as a specific user and inherits exactly that user’s permissions; a service identity that is not mapped to a user begins with none and gains only what a role grants. The same six permission levels apply to integrations and agents as to people.
It should be treated that way from the start, particularly in jurisdictions with works council involvement. The record exists to make work legible, not people — and the access model is the control that keeps it so. It is a conversation worth having before the first dashboard, not after it.
Honest answer: as good as adoption. The execution record is a by-product of real work, which is what makes it truthful and also what makes it thin where the platform is not used. Start with one programme rather than a rollout, and judge the dataset from a domain that is genuinely working in it.
At organization level, with access governance and deployment decided centrally — including on-premises and hybrid arrangements — which is usually the first question your security colleagues will ask, and the reason coordination data does not have to leave your estate to be useful.
Chief Data Officer
Your organization has a system of record for transactions, for customers, for products, for people. It has none for execution. ERP knows a purchase order was raised and approved. It does not know that it waited eleven days on a legal review, who owned that review, what the objection was, or that the same obstacle has now delayed nine others. That information exists — in inboxes, chat threads, spreadsheets and people’s heads — where nothing can query it and nothing can govern it. KanBo has two faces. For business users it is a governed work coordination platform. For the rest of the organization it is a structured, permissioned source of execution data, reachable by API, by OData, and — increasingly the point — by AI agents through MCP.
The execution record as a data asset
Coordination data has an unusual property: it is generated as a by-product of people doing their work, not by anyone filling in a form about their work. That makes it substantially more truthful than self-reported status, and it is why it is worth treating as an asset rather than as application exhaust. What it contains is what every operational question actually turns on. Who is responsible. What depends on what, across which departments. What is blocking, who owns the obstacle, how often that obstacle recurs. What was decided, when, by whom, and on what basis. How long things really take between the milestones your other systems record. For a CDO the significance is threefold. It is a dataset the organization does not have. It is born inside a permission model rather than having governance retrofitted to it. And it is the context layer that AI systems need and currently cannot reach.
Semantic Work Objects
Meaning carried by structure
Cards, people, documents and dependencies are typed objects with typed links between them. Anything reading the record resolves a relation instead of inferring meaning from prose.
API and OData
Consumable by systems you already run
A JSON API secured by your own certificate, OData straight into Power BI, and supported integrations for Power Automate, UiPath, Nintex, Teams, Outlook and Active Directory.
MCP
The context layer AI has been missing
Purpose, ownership, history and dependencies are what a model needs and what is never written down. MCP gives agents the execution record, under the same rules as a person.
Identity and Permissions
Machine access inherits your permission model
A service can act as a named user and holds exactly that user’s permissions. An unmapped service identity holds none until a role grants it. Deny by default.
A day in the life of a Chief Data Officer
Two halves, and the order matters. The CDO uses the platform before they consume the data it produces — which is how they come to know what is in it.
Step 1 — Your own programme runs here
The obligations from the latest policy, the open classification disputes, the AI use cases waiting on assessment, the remediation items sitting with system owners in three other departments. Each is a card with an owner, a date and its dependencies. You start the day on exceptions — what is overdue, what is blocked, what the platform has flagged as a conflict between dates and dependencies — rather than on a status pack describing last Thursday. Communication belongs to the same objects. The discussion that produced a decision sits on the card that carries it, so the reasoning survives the people involved.
Step 2 — You learn what the record contains by working in it
This is the half most data leaders skip, and it is the half that determines whether the rest works. Specifying what to extract from a system you have never used produces a schema that answers last year’s questions. A quarter of running your own governance programme in KanBo tells you exactly which relations matter — that blocker ownership is more predictive than status, that the cross-department dependencies are where the time actually goes. You end up defining the extract as a practitioner rather than as an architect.
Step 3 — The record flows outward
The same objects reach the rest of the estate without an export step: OData into Power BI, the JSON API into the warehouse and the models, MCP for AI systems that need to reason about the current state of work. Nothing is re-keyed and nothing is self-reported, because the data was produced by people doing the work rather than by anyone describing it afterwards. Execution data now joins the datasets you already govern, and reconciles against the transactional systems it sits between — the gap between the milestones ERP records and what happened in between.
Step 4 — And other systems write back in
The traffic runs both ways. A ticket raised elsewhere, a supplier message, a signal from an operational system can create or update a card through the API, Power Automate, UiPath or Nintex, or arrive by email into a space as a structured item with an owner and a date. An agent connected through MCP can do the same, acting as an identity whose permissions you control. The loop closes: the systems of record trigger the work, the work is coordinated where people already are, and the resulting execution data returns to the estate as a governed asset.
Governing what you do not own
A CDO’s authority is real but narrow. You can set a standard; you rarely control the systems, budgets or people that make it true. Governance therefore succeeds or fails on whether the organization can see the same picture you do. James C. Scott’s study of how states make societies legible is the useful warning. Central authorities impose simplified schemas so things can be measured and administered — and the simplification routinely destroys the local knowledge that made the system work. Enterprise data governance faces exactly this trade-off. Standardize too little and nothing aggregates; standardize too much and domains quietly maintain a second, real version of their world. The design conclusion is not moderation for its own sake. It is that the shared layer should be thin and structural — ownership, dependency, status type, evidence — while local vocabulary and process stay local. That is also, not coincidentally, what makes the resulting dataset consistent enough to query.
Spaces and Relations
A policy is a commitment, not a document
A policy is a commitment, not a document Every obligation becomes a card with a named owner, a date and its dependencies — including the ones owned by departments you do not manage.
Comments and Activity
Why, recorded where the what is
Classification disputes, access exceptions and AI approvals are decided on the card that carries them. Two years later the reasoning is still attached to it.
History and Searchs
The version that is actually in force
Documents are connected to your existing repositories rather than copied, so the policy on the card is the policy in the library — and a moved library is repaired, not broken.
History and Search
What did you know, and when
Activity history stays on the work and search reaches inside it. Auditors and second-line functions get reader access rather than a compiled pack.
Get started today with KanBo!
KanBo is a work coordination software designed to help self-organizing teams work smarter and faster. You can see KanBo in action by accessing our Sandbox demonstration environment.
Q&A
Have a question? We’ve got answers!
No, and the distinction matters. KanBo does not catalogue data, trace lineage, profile quality or manage master data, and it belongs alongside the tools that do. It contributes in two different ways: it runs the governance programme itself — obligations, owners, decisions, remediation, evidence — and it produces a dataset about how the organization executes that no other system holds.
Typed entities with stable identity — cards, spaces, people, documents, labels, custom fields — and typed links between them: parent and child, predecessor and successor, including across departments. Responsibility is a relation to a named person rather than a sentence. A blocker is a reusable object with a name, a reason and an owner, which makes it a controlled vocabulary of obstacles rather than a phrase people repeat. Every local status name is mapped to one of five types, so semantic reconciliation happens at source, maintained by the people who own the vocabulary, instead of in a central mapping project that is stale the month it finishes. All of it reachable through the JSON API, through OData for Power BI, and through MCP for AI systems. The practical difference for anything consuming it: prose has to be interpreted, and interpretation fails silently. This record is already resolved.
Only what the identity they act as is permitted to see. A service can be configured to run as a specific user and inherits exactly that user’s permissions; a service identity that is not mapped to a user begins with none and gains only what a role grants. The same six permission levels apply to integrations and agents as to people.
It should be treated that way from the start, particularly in jurisdictions with works council involvement. The record exists to make work legible, not people — and the access model is the control that keeps it so. It is a conversation worth having before the first dashboard, not after it.
Honest answer: as good as adoption. The execution record is a by-product of real work, which is what makes it truthful and also what makes it thin where the platform is not used. Start with one programme rather than a rollout, and judge the dataset from a domain that is genuinely working in it.
At organization level, with access governance and deployment decided centrally — including on-premises and hybrid arrangements — which is usually the first question your security colleagues will ask, and the reason coordination data does not have to leave your estate to be useful.