> 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/k-ai-audit/audit-ui.md).

# K-AI Audit web app

The K-AI Audit web app is the browser application at `https://app.kai-studio.ai`. It is the Document Steward's daily tool for animating the audit workflow. Sign-in is delegated to the central auth service; once authenticated, the browser holds a `kai_auth` HttpOnly cookie that the UI presents to the Audit API on every request. See [Authentication — Cookies](/knowledge-ai/authentication/cookies.md) for the cookie lifecycle and the sliding-window refresh.

## Main views

The K-AI Audit web app is organised around seven main views, all scoped to a single audit instance (except the top-level dashboard, which spans every instance the signed-in user belongs to).

### Dashboard

The entry point. Summary cards across all audit instances the user has access to: pending conflicts, unanswered mandatory questions, missing-subject count per instance, duplicates pending review. Backed by `audit_dashboard_get`.

{% hint style="info" %}
At a glance: a grid of summary cards, one per audit instance the user belongs to. Each card surfaces four counters — open conflicts, unanswered mandatory questions, missing-subject clusters, duplicates pending review — and a click drills into the instance. See the live application at `https://app.kai-studio.ai` to follow along.
{% endhint %}

### Conflicts list

Open conflicts for one instance, filterable by state (`OPEN`, `WAITING_VALIDATION`, `CLOSED`). The default filter is `OPEN`. Each row shows the underlying question, the number of conflicting documents, and the timestamp of detection. Backed by `audit_question_conflict_list`.

{% hint style="info" %}
At a glance: a tabular view filtered on `state=OPEN` by default. Columns: question text, number of conflicting documents, detection timestamp, state badge. A state filter at the top toggles between `OPEN`, `WAITING_VALIDATION`, and `CLOSED`.
{% endhint %}

### Conflict detail

The core resolution view. Left pane: conflicting excerpts side-by-side with links back to the source documents. Right pane: expert-answer form. Once the expert answer is submitted, the platform displays AI-generated modification recommendations per impacted document; the Steward confirms each was applied in the source system before marking the conflict managed. Backed by `audit_question_conflict_get`, `audit_question_conflict_set_answer`, `audit_documents_get_recommendations`, `audit_question_conflict_close`.

{% hint style="info" %}
At a glance: a two-pane layout. The left pane lists the conflicting excerpts side-by-side, each with a source-document link and the surrounding paragraph for context. The right pane holds the expert-answer form. After submission, the right pane reflows to display per-document modification recommendations with check-off controls and a final "Mark managed" action.
{% endhint %}

### Mandatory questions

Questions the system requires SMEs (Document Producers) to answer for a Document Product to be considered complete. The Steward creates, dispatches, and tracks the answers; Producers respond. Backed by `audit_mandatory_question_list` and friends.

{% hint style="info" %}
At a glance: a list view with one row per mandatory question. Each row carries a status badge (`UNANSWERED`, `ANSWERED`, `VALIDATED`), the assigned Producer, the deadline, and a quick-action menu to dispatch a reminder or escalate to the Owner.
{% endhint %}

### Missing subjects

Clusters of expected but uncovered topics, computed against the Document Product's expected scope. The Steward can mark a cluster as out-of-scope or trigger the generation of an AI companion document to fill the gap. Backed by `audit_missing_subject_list`, `audit_missing_subject_set_state`, `audit_missing_subject_generate_compagnon_document`.

{% hint style="info" %}
At a glance: each missing-subject cluster appears as an expandable card with the sample queries that triggered it, a relevance score, and state controls — `MARK_OUT_OF_SCOPE`, `ASSIGN_TO_PRODUCER`, or `GENERATE_COMPANION_DOCUMENT` (the last triggers an AI-drafted starter document the Steward can hand off for review).
{% endhint %}

### Duplicates

Sets of semantically duplicate documents detected across the repository. Each set lists the candidate originals and copies; the Steward marks a set as managed once the duplication has been resolved upstream.

{% hint style="info" %}
At a glance: each duplicate cluster groups two or more candidate documents. Per row: title, source, last-modified date, and a similarity score. The Steward picks the canonical version, marks the others as derived (or for retirement), and closes the cluster once the source systems reflect the decision.
{% endhint %}

### Stats

KPIs per Document Product and per Steward: conflicts opened vs closed over time, mandatory-question answer rate, time-to-resolution, top collaborators.

{% hint style="info" %}
At a glance: a KPI dashboard. Top row of metric tiles (conflicts closed this month, average time-to-resolution, mandatory-question answer rate, missing-subject closure rate). Below, time-series charts and a per-Steward leaderboard for cross-team visibility.
{% endhint %}

## Conflict-first walkthrough

The recommended Steward routine, mapped to the UI:

1. Land on the **Dashboard**.
2. Click on an instance with open conflicts.
3. Click **Conflicts** in the instance navigation. The list opens, default filter `state=OPEN`.
4. Click a conflict to open the detail view.
5. Read the conflicting excerpts. Click the source-document link to verify in context, if needed.
6. Compose the expert answer in the answer panel; submit.
7. The platform displays modification recommendations for each impacted document. Confirm each was applied in the source system.
8. Click **Mark managed** to close the conflict.

Steps 4–8 are the same five MCP operations described in the [conflict-first workflow](/knowledge-ai/k-ai-audit/audit.md#conflict-first-workflow) — the K-AI Audit web app is the visual surface, the MCP is the programmatic surface, and the underlying state machine is shared.

## When to use the K-AI Audit web app vs MCP

| Use case                                  | K-AI Audit web app | MCP           |
| ----------------------------------------- | ------------------ | ------------- |
| Daily Steward animation                   | ✅                  | partial       |
| Batch agent automation                    | limited            | ✅             |
| Configuration / instance setup            | ✅                  | ❌ (REST-only) |
| Quick visual inspection of a conflict     | ✅                  | via text only |
| LLM-assisted resolution of many conflicts | ❌                  | ✅             |

The K-AI Audit web app and the Audit MCP are complementary, not redundant. The browser is irreplaceable for visual review and configuration; the MCP is irreplaceable for batch and agent workflows. Both authenticate the same end-user against the same audit instances, with the same group-based RBAC.