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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

Stats

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

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.

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 — 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.