Governing AI knowledge

How I turned provenance into an investigation workflow for an enterprise AI MVP. The client accepted the direction and praised its precision and detail.

Context

Provenance is a workflow, not a citation. Enterprise teams need to trace an AI response back to the knowledge and rules behind it, make a correction and evaluate again.

Role: Sole Product Designer
Stage: MVP design
Users: PMs, Data Ops and Admins
Collaboration: PM, engineers and executive review
Validation: Client presentation
Outcome: MVP direction accepted; qualitative praise for precision and detail

Problem

The intended users (PMs, Data Ops and Admins) needed a way to govern sensitive enterprise knowledge without understanding every detail of an AI system. The product needed to make access restrictions, document state and the reasons behind an answer inspectable.

A citation could answer “Where did this come from?” It could not, on its own, explain what happened to the information, what the system used, which rules affected it or what to change next.

Three overview cards showing document sensitivity, connected sources and document freshness, including an alert for documents needing attention. — Knowledge governance goes beyond document volume. This illustrative overview brings sensitivity, connected sources and freshness together so managers can understand what information an agent might rely on and where attention is needed.

Responsibility

Designing the Knowledge Hub required a working understanding of how enterprise knowledge moves through an AI system, from ingestion and parsing through chunking, embeddings, retrieval, provenance and evaluation.

That understanding helped me decide which system states needed to be visible and where users needed a way to investigate or intervene. Parsing state could help explain a processing problem; processed passages could reveal what was available for retrieval; rules and configuration could explain why particular knowledge was used. Evaluation provided a way to check a correction.

My design scope connected those states into a navigable investigation workflow. PM, engineers and executive review were part of the process; no major PM or engineering constraint materially changed the concept at this stage.

Discovery

I organized the required capabilities around three connected activities: bringing knowledge in, governing its use and improving the answers it supported.

The scope covered source connection, document processing, synchronization and versioning, knowledge collections, access controls, retrieval configuration, and evaluation. These were parts of the MVP design scope, rather than findings from user testing.

Seven Knowledge Hub workflows grouped into connecting, governing and improving knowledge. — The seven workflows form a connected system: bring knowledge in, govern its use, and improve the answers it supports. Provenance links governance to improvement by helping users trace a problem back to something they can change.

The central design question was how those capabilities could help someone act on an incorrect answer. Exposing more system information would only be useful if it led to an understandable next step.

Decisions

1. Make the investigation chain navigable

I treated provenance as a workflow through the system:

Response → Knowledge → Source → Processed content → Rules/configuration

Users could start with an answer, inspect the knowledge supporting it, open the source, examine what had been processed and investigate the rules or configuration affecting its use.

A parental-leave answer leading to supporting handbook passages, document details and access permissions. — Starting with an answer, users can inspect the supporting passage, then the document and its access rules. Each step reveals more context without requiring an understanding of the retrieval pipeline upfront.

The starting point was familiar: an answer, its supporting passages and the source document. More technical information became available as the investigation required it. This balanced a readable first view with access to the detail needed to diagnose a failure.

2. Connect diagnosis to correction and evaluation

The workflow needed a return path. After identifying the cause of a bad output, users should be able to correct the underlying knowledge or configuration and return to evaluation.

Depending on the issue, the next step could be editing a document, changing a collection, adjusting permissions, reprocessing a source or modifying retrieval settings.

A four-stage loop: observe a failed evaluation, diagnose its source, correct the document, collection or retrieval settings, and evaluate again. — Provenance becomes actionable when an incorrect answer leads to its source and a targeted correction. Rerunning the evaluation closes the loop between understanding a failure and checking whether the change improved the answer.

This made the investigation reversible: users could move back from an output to its cause, make a targeted change and check the resulting behavior. A visible source was the beginning of that work, not its completion.

3. Keep governance in view

A document could exist in the system without being appropriate for every agent, user, region or use case. The investigation therefore needed to show both where knowledge came from and the conditions under which it could be used.

Permissions and configuration remained connected to the information they governed, giving users context for a corrective decision.

Outcome

I presented the MVP direction to the client, including the governance model and investigation workflow. The client product lead gave strongly positive feedback, highlighting the precision, level of detail and strong first impression. The MVP direction was accepted as presented.

This was a client presentation, not user testing. No user testing preceded the presentation, and there was no later design-iteration cycle to report. I treat the response as qualitative stakeholder validation, not evidence of production usability or impact.

Reflection

The project reinforced that AI transparency is useful when it supports action. Users need a path from an output to the underlying knowledge, configuration and next corrective step, and a way to evaluate the change.