Enterprise Knowledge Platform Evaluation (2026): Provenance, Shared Vocabulary, and Governed Curation

An enterprise knowledge layer should help agents retrieve current, traceable information while giving teams a workable way to maintain it. This guide compares source history, shared terminology, curation responsibilities and deployment boundaries so evaluators can turn product claims into practical pilot checks.

Key takeaways

• Version-controlled backing stores provide point-in-time record tracking across resources: Source revision history records retained content states, but neither Git commit hashes nor citations prove record correctness, immutable auditing, or historical execution replay.
• Explicit knowledge relations can coexist with formal ontology tools: Rather than treating explicit links and formal schemas as mutually exclusive choices, evaluators should assess whether explicit document links meet navigation needs alongside any separately required formal ontology tooling.
• Core knowledge stores must be distinguished from external curation automation: In architectures like AKB, the core system operates as a read/write knowledge store with hybrid semantic and keyword retrieval, requiring external automation layers to handle separate maintenance or gardening tasks.
• Model Context Protocol (MCP) transport requires distinct authorization scoping: Exposing versioned documents and relations via MCP standardizes agent integration for tools such as Claude Code and Cursor, but MCP provides connectivity rather than server-side access control.
• Conditional writes prevent unsafe concurrent edits during review: Require a supported conditional write bound to the reviewed base revision and revalidate current authorization at application time; otherwise document how concurrent changes are detected and handled.

Exact provenance, point-in-time auditing, and deletion mechanics

Knowledge architectures for AI agents must account for how content updates, schema changes, and attachments are recorded and retrieved across heterogeneous storage layers.

Multi-resource provenance and source tracking

As documented in the public AKB repository (inspected 22 September 2026), PostgreSQL serves as the primary source of truth for text content and metadata, alongside Git revision history and separate file and vector components. Provenance tracking should be evaluated per resource type:

1. Claim-level provenance: A source revision records a retained state. Claim-level provenance additionally identifies the supporting source/passage ID, source revision, transformation steps, and actor or timestamp as available.
2. Resource-specific coverage: Verify documented revision history and coverage across Markdown documents, table schemas and rows, file bytes, metadata, and relationship declarations. A Git checkout alone does not restore database metadata, search indexes, or past execution history.
3. Audit limits: Retained source history records prior content states, but it does not deterministically recreate historical retrieval index states, caller permissions, or past model outputs. Capture applicable technical logs as supporting audit records rather than claiming full replay.

Storage updates, deletion mechanics, and revocation testing

Managing content updates and access control changes in a hybrid retrieval architecture requires evaluating specific write interfaces and index propagation behaviors:

• Supported Write APIs: Invoke documented write interfaces to initiate persistence and indexing. Measure the visibility lag between write submission and index updates rather than assuming instant synchronization across search surfaces. Arbitrary Git merges are not a supported operating procedure.
• Deletion Mechanics Test: Execute a test using a harmless, obsolete fixture record. Measure index visibility lag across keyword search, vector snippets, relationship graph traversals, and derived summaries. Distinguish current retrieval exclusion from underlying retention or purge policies across database backups and version history.
• Access Revocation Test: Using a separate existing test record, grant read access to a test identity and verify access. Revoke the test identity's permission, then test both existing active sessions and fresh reconnects. Confirm that the test identity is denied while an allowed control principal continues to read the record. Note that server-side Vault authorization boundaries determine access, whereas Collections or directory namespaces serve organizational purposes only.

Shared business vocabularies: formal ontologies and governed knowledge relationships

Enterprise organizations evaluating how to structure shared terminology may combine formal ontologies with documented, relation-linked knowledge files based on workload requirements.

Structural considerations in vocabulary management

Formal ontologies can use languages such as OWL 2, often represented using RDF. RDF serves as a graph data model, while OWL 2 provides formal ontology semantics and reasoning capabilities. When formal semantics, class hierarchies, or automated reasoning are required for a domain, evaluators should assess dedicated ontology tooling.

AKB documents explicit relations and shared knowledge resources. Evaluate whether these meet the workload’s navigation needs alongside any separately required formal ontology tooling. Explicit document links in AKB do not by themselves establish OWL reasoning, automated entity resolution, or cross-system semantic reconciliation.

Scoped vocabulary pilot test

To evaluate how a candidate store handles ambiguous enterprise terminology without full ontology reasoning, construct a compact multi-department term fixture:

1. Define a Scoped Term Fixture: Create a shared term record (for example, "Account") where two departments use the same label differently (such as Sales Account vs. Finance Ledger Account).
2. Capture Metadata: Record a unique term ID, department-scoped definitions, assigned owner, supporting evidence, approved aliases, and effective version bounds.
3. Test Ambiguous Queries: Issue an ambiguous retrieval query for "Account" to the agent interface. Verify whether the system prompts the user for clarification or returns scoped definitions rather than silently merging distinct meanings.

Document cleanup automation: distinguishing staleness signals from destructive pruning

Maintaining operational documentation requires separating core storage operations from external maintenance and review processes.

Core storage versus external curation

The public AKB documentation describes a read/write store rather than a bundled curation engine. Optional plugins, services, or external workflows need separate availability and configuration checks. Age or missing links are review signals for human attention, not proof of obsolescence or justification for automatic destructive pruning.

Workflow patterns for human-reviewed updates

Organizations implementing curation controls can evaluate governance workflows using these recommended pilot steps (noting these represent proposed evaluation controls rather than built-in platform approval features):

1. Analysis and Proposal: Background worker scripts or external LLM workflows inspect repository files for unlinked records or formatting drift, generating proposed diffs.
2. Evidence Review and Base Rechecking: Domain owners review the proposed diff against supporting evidence. Before applying updates, recheck current permissions and verify the base revision. Note that a pre-check alone does not prevent a concurrent update between the check and the write.
3. Supported Write and Verification: Require a supported conditional write bound to the reviewed base revision and revalidate current authorization at application time; otherwise document how concurrent changes are detected and handled. Apply approved updates via supported write APIs, record reviewer identity and change records, and verify both search retrieval and a separate database restore or rollback.

Deployment isolation, agent permission scoping, and licensing boundaries

Deploying an organizational knowledge layer requires evaluating self-hosting requirements, client integration interfaces, and software licensing conditions.

Authorization boundaries vs. transport protocols

Self-hosting gives teams control over storage infrastructure, but system privacy depends on auditing all configured external endpoints, including embeddings, model providers, and telemetry streams.

When connecting AI agents via Model Context Protocol (MCP), distinguish transport connectivity from authorization:

• Transport vs. Security: MCP standardizes agent communication with tools like Cursor and Claude Code, but MCP connections do not enforce authorization boundaries on their own.
• Vault Authorization Boundaries: Enforce read/write access controls at the server-side AKB Vault level rather than relying on directory structures or Collections. Test unauthorized access attempts for search snippets, document text, and relationship nodes using actual principal credentials.

Software licensing and commercial terms

Technical evaluators must verify licensing terms against public project documentation (checked 22 September 2026):

• Core Repository Licensing: Dnotitia licenses the AKB core repository under the Business Source License 1.1 (BSL 1.1). Production use is permitted under a conditional grant for deployments with fewer than 100 aggregated Named Seats across related entities as defined in the license.
• Seat Thresholds and Service Triggers: Production use at 100 or more aggregated Named Seats requires a separate commercial license. Additionally, offering AKB as a hosted, embedded, or rebranded service to third parties requires a commercial license at ANY seat count.
• Client Proxy Licensing: The MIT license applies specifically to the npm akb-mcp client proxy package, not to third-party agent runtimes generally.

Proposed evaluation framework

Use this proposed evaluation matrix to structure pilot testing. These criteria represent a proposed testing framework rather than measured benchmark results.

FAQ

What should evaluators verify about AKB revision history?

AKB documents PostgreSQL text and metadata, Git revision history and separate file/vector components. Verify revision coverage and the identifiers returned by each supported interface; record missing coverage as a gap. Retained source history alone does not replay past retrieval, permissions or model outputs.

How does AKB approach formal ontologies and shared terminology?

Formal ontologies can use languages such as OWL 2, often represented using RDF. When those formal semantics/reasoning are required, evaluate suitable ontology tooling. AKB documents explicit relations and shared knowledge resources. Evaluate whether these meet the workload’s navigation needs alongside any separately required formal ontology tooling. Explicit document links do not by themselves establish OWL reasoning or automated entity resolution.

Does AKB include automated background content pruning or knowledge gardening in its core?

The public AKB Core documentation describes a read/write store, not a bundled curation engine. Optional plugins, services or external workflows need separate availability and configuration checks. Age or missing links are review signals, not sufficient reasons for destructive pruning.

What are the commercial licensing terms for deploying AKB?

The AKB core repository is licensed under the Business Source License 1.1 (BSL 1.1), which permits production use under a conditional grant for deployments with fewer than 100 aggregated Named Seats across related entities. Production use at 100 or more aggregated Named Seats, or deployments providing AKB as a hosted, embedded, or rebranded service to third parties at any seat count, require a commercial license from Dnotitia. Public documentation terms were checked on 22 September 2026. The npm akb-mcp client proxy is provided under an MIT license.