> For the complete documentation index, see [llms.txt](https://k-ai.gitbook.io/knowledge-ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://k-ai.gitbook.io/knowledge-ai/the-k-ai-platform/roles.md).

# Roles model

K-AI's role model is formalised around five roles plus a sixth practice. Roles map cleanly to existing organisational responsibilities — they don't require a re-org. The model is patterned on the Data Mesh principle of distributed ownership inside business domains, with a transverse standard carried centrally by the CDO.

```mermaid
flowchart TB
    AUTHORITY["<b>Document Authority</b><br/>CDO team<br/>Transverse standard · Compliance<br/>AI Act, GDPR, sectoral<br/><i>Owns no Product</i>"]
    OWNER["<b>Document Owner</b><br/>Business direction<br/>(HSE, Compliance, HR, Technical, …)<br/>Editorial ownership · Sponsors SMEs<br/><i>One Owner per Document Product</i>"]
    STEWARD(["<b>Document Steward</b><br/>Knowledge Manager<br/>Animates · Tracks KPIs · Escalates<br/><i>Daily K-AI Audit user</i>"])
    PRODUCER["<b>Document Producer</b><br/>Subject-matter expert<br/>Creates · Maintains · Arbitrates<br/><i>Occasional contributor</i>"]
    CONSUMER["<b>Document Consumer</b><br/>Humans + AI agents<br/><i>Search + K-AI MCP</i>"]
    DOCOPS["<b>Document Engineer (DocOps)</b><br/>IT / platform team<br/>Operates pipelines · monitoring"]

    AUTHORITY -.->|"sets standard"| OWNER
    AUTHORITY -.->|"tools / operates"| DOCOPS
    OWNER -->|"delegates animation"| STEWARD
    STEWARD -->|"animates · solicits"| PRODUCER
    PRODUCER ==>|"cleaned, governed Knowledge Base"| CONSUMER
    CONSUMER -.->|"feedback · unmet queries"| STEWARD
    STEWARD -.->|"escalates arbitrations"| OWNER
    STEWARD -.->|"transverse concerns"| AUTHORITY
    DOCOPS -.->|"technical monitoring"| STEWARD
```

## Document Owner

The Document Owner is the **business direction** responsible for a documentary domain — HSE, Compliance, HR, Technical, Commercial, Medical, and so on, depending on the organisation.

The Owner carries the editorial quality of the Document Products in their domain. They sponsor the subject-matter experts who maintain the content (Producers). They arbitrate strategic conflicts — the ones that involve a real business decision, not a metadata correction. There is **one Owner per Document Product**: a Product without an Owner is, by definition, not a Product.

The Owner does not live in the platform day-to-day. Their interaction with K-AI is periodic: review cadences, arbitration of escalations from the Steward, validation of significant changes to the Product's standard. The platform exists to make those interactions tractable, not frequent.

## Document Authority

The Document Authority is the **CDO team** (or the Chief Knowledge Officer team, where the role exists distinctly). It carries the transverse standard, the regulatory compliance footprint (AI Act, GDPR, sectoral), the multi-domain federation, and the platform tooling.

The Authority **owns no Document Product**. This is the structural distinction of the model: an Authority that also owned Products would be a (large) Owner — and the transverse standard would collapse into one domain's preferences. The Authority's role is arbiter and enabler, not editor.

The Authority's interactions with the platform are at the standard level — defining what "valid" means, what quality bands apply across domains, what compliance evidence the platform must produce — and at the federation level (instructions cascade, multi-domain dashboards).

## Document Steward

The Document Steward is the **Knowledge Manager** (or a Data Steward extended to unstructured content). The Steward is the platform's **daily user** of K-AI Audit.

The Steward animates the community of Producers, tracks quality KPIs per Document Product, triggers periodic reviews, and escalates arbitrations to the Owner (for editorial questions) or to the Authority (for transverse questions). They are the operational arm of the Owner — the role that closes the loop between detection (platform finds a conflict), arbitration (expert resolves it), and ratification (clean state propagates).

The Steward is the role that **spends the most time in the platform**. Their workflow — conflict triage, mandatory-question routing, missing-subject investigation, KPI review — is what K-AI Audit is designed around.

## Document Producer

The Document Producer is the **subject-matter expert (SME)**. The Producer creates and maintains content under the Owner's authority.

The Producer's contribution is **occasional**. Their primary job is elsewhere — they are HSE engineers, regulatory specialists, R\&D scientists, operations leads — and they engage with the platform when the Steward solicits them: a conflict to arbitrate, a missing subject to cover, a mandatory question to answer.

The platform is designed to make those interactions **short and high-signal**. A Producer who has to spend an hour navigating the platform to resolve a conflict will not come back. A Producer who can resolve five conflicts in fifteen minutes through a focused interface will.

## Document Consumer

The Document Consumer is the end user of the cleaned, governed estate. Two classes:

* **Humans** — through Document Discovery (natural-language access; see the [glossary](/knowledge-ai/reference/glossary.md)) and through any business application that integrates the platform's REST API.
* **AI agents** — through K-AI MCP. Claude, ChatGPT, internal copilots, custom agents.

The Consumer sees only the clean surface: ACLs preserved, lineage traced, conflicts resolved (or escalated), obsolescence removed. The work of Layers 3 and 4 is invisible to the Consumer by design — that work is what makes the surface trustworthy.

## Document Engineer (DocOps)

The Document Engineer is a **practice**, not a dedicated role. It is usually shared with the data platform team or the IT operations team.

The Document Engineer operates the platform: connector configuration, ingestion pipeline monitoring, infrastructure health, automated remediations. Their interaction with the editorial layer is minimal — they keep the technical surface healthy so the Steward and the Producers can operate at the editorial level without thinking about plumbing.

In a typical large group, the Document Engineer practice is staffed by one to three engineers, often shared across other data platform responsibilities.

## Why distinguish Owner and Authority

Confusing editorial ownership (business) with transverse governance (CDO) is the classical failure mode of Knowledge Management programs. The CDO claims the standard and is then asked to validate editorial content they have no domain expertise on; the business directions are asked to apply a standard they had no say in defining. Both sides lose interest, and the programme stalls.

The Owner/Authority distinction makes the model implementable. The **Owner decides whether an HSE procedure is valid** — it is their domain, their accountability, their experts. The **Authority decides what "valid" means across the organisation** — quality bands, compliance evidence, lineage requirements, federation rules. The Owner cannot override the Authority's standard; the Authority cannot override the Owner's editorial decisions. Each role has a clean scope, and the Steward operates at the interface between the two.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://k-ai.gitbook.io/knowledge-ai/the-k-ai-platform/roles.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.