Changelog

2026-10-09 — Stonly metadata filter

STONLY sources accept an optional metadata filter on the guides' Stonly custom metadata: a flat AND of eq / in conditions, stored in a canonical lower-case form. The rule is set at creation and is immutable (400 metadata_filter_immutable).
Guides are admitted only after their metadata have been read: a filtered source ingests nothing on its first sync. A guide whose metadata cannot be read, or that lacks a metadata the rule names, is neither ingested nor removed.
New endpoint POST /v1/sources/stonly/metadata-preview — tests a rule on a random sample of the folder and lists the metadata names and values seen.
Several STONLY sources may share one folder and language when their filters differ; a duplicate returns 409 source_scope_exists. Nested folders are still refused.
Optional Filter by metadata step with sample test in the admin portal's source creation modal.

SHAREPOINT_DRIVE sources accept an optional metadata filter: a rule on the library's custom columns and on six file properties (file:name, file:extension, file:mime_type, file:size, file:created, file:modified), applied on full scans and delta runs.
New endpoints POST /v1/sources/sharepoint/columns (filterable columns and their operators) and POST /v1/sources/sharepoint/metadata-preview (first matching files before saving).
Changing a rule forces a full rescan; saving a rule on a source that already holds documents requires acknowledge_metadata_filter_rescope: true.
Several SHAREPOINT_DRIVE sources may share one scope path when their filters differ; a duplicate returns 409 source_scope_exists.
Optional Metadata filter step with preview in the admin portal's source creation modal.

New source connector for Stonly knowledge bases: published Articles of one folder subtree in one language, converted to Markdown with inline images embedded, each prefixed with its folder-path domain header.
Authentication by Stonly personal API token (read:folder + read:guide, Commenter access). Tokens expire after at most 365 days; rotation is manual.
Folder picker in the admin portal; nested sources in the same language are refused (400 overlapping_stonly_scope).

Organization API keys (ks_org_…) are now accepted directly in Authorization: Bearer on the K-AI Audit API, the K-AI Retrieval API, and both MCP endpoints — no OAuth consent screen and no token-exchange step. Built for agent platforms that run unattended. The K-AI Platform API still requires an exchanged token.
Authentication on that path returns 401 (credential refused — stop) or 503 with Retry-After (momentarily unavailable — retry), and nothing else.
retrieval_instances_list_available_instances documents its notice field: returned with an empty instances array when the identity belongs to no retrieval group.
New page: Autonomous agents (API key).
Corrected the documented token-exchange response — it is wrapped in { "response": … } and expires_in is 900, not 3600.

Audit API now 48 operations; Audit MCP surface now 21 tools.
New tool audit_question_conflict_ignore — mark a question conflict as IGNORED (false positive / no change needed), mirroring audit_full_audit_conflict_ignore. Question conflicts now expose the full OPEN · ANSWERED · RECOMMENDATIONS_READY · MANAGED · IGNORED state set.
Priority surfacing on full-audit conflicts: audit_full_audit_conflict_list accepts only_linked_to_question, and conflicts linked to a mandatory question are flagged is_important (with linked_questions). These share priority with question conflicts.

Documentation rebuilt around the Document Knowledge Platform positioning.
5-layer conceptual architecture documented (Sources → Ingestion → Semantic Document Layer → Governance & Quality → Exposure).
Three OpenAPI 3.1 specifications published: Instance API (33 ops), Retrieval API (5 ops), Audit API (47 ops with 20 MCP).
Authentication surfaces consolidated into a single section with a chooser table.
Glossary of 22 DKP terms added.

/search and /conversation removed from the K-AI Instance API. Replacements: retrieval_semantic_nodes_search and host-LLM-driven conversation via MCP.
Retrieval API (5 ops) and Audit API (47 ops) extracted as standalone surfaces hosted at api-retrieval.kai-studio.ai and api-audit.kai-studio.ai.
MCP exposure added on both surfaces. Retrieval MCP and Audit MCP both stable.

Earlier history captured in the internal monorepo git logs.

Last updated 12 hours ago