Separating Knowledge Curation from the Core Knowledge Store
Decide which system should propose, review and apply knowledge changes, and how to connect that workflow to a versioned agent knowledge store.
Key takeaways
- Storage and curation answer different questions: A store holds and retrieves records; a curation workflow decides which proposed changes should become authoritative.
- Make review ownership explicit: Name the person or service that can propose, approve and apply a change.
- Use supported interfaces: Versioned APIs and documented tools provide a clearer integration boundary than direct writes into a store’s internal files.
- Choose based on your workflow: Separate curation offers flexibility but needs an operator; an integrated product is useful when its actual review process fits the team.
Separate curation from storage when you need a review process that the store does not provide and can operate the integration. Consider an integrated platform when its supported workflow already matches your approval, source-tracking and recovery requirements. Start by tracing one proposed change from discovery to retrieval, rather than comparing long feature lists.
What belongs in each layer?
The knowledge store is responsible for the records and interfaces it documents. Curation adds decisions about quality: whether two records mean the same thing, whether an old instruction should be retired, and who can approve a correction.
| Responsibility | Example owner | Acceptance question |
|---|---|---|
| Store and retrieve records | Knowledge service | Can an authorized client read the intended version? |
| Detect a possible issue | Rule, scheduled job or reviewer | What evidence supports the proposed change? |
| Decide whether to accept it | Named source owner or reviewer | Does the change preserve the source’s meaning and scope? |
| Apply an approved change | Authorized integration | Can it detect that the record changed during review? |
| Verify and recover | Operator and source owner | Is the revised record retrievable, and can an incorrect change be reversed? |
These are proposed responsibilities, not claims that every knowledge product includes them. A small team may assign several to one person. The useful boundary is that proposing a change does not automatically authorize a write, though low-risk or routine formatting edits may follow automated policies rather than requiring manual human approval.
A concrete review workflow
Suppose a maintenance job finds two onboarding documents that give different setup instructions. It should retain their source identifiers, provenance and observed revisions, explain the disagreement, and create a proposal for the owner without overwriting original source evidence.
A workable sequence is:
- Read original source records through supported interfaces, preserving raw provenance and revisions.
- Create a proposed output item with explicit review status and ownership, keeping original sources untouched.
- Validate permissions for both the responsible reviewer and the target destination audience so that combining restricted sources never widens access.
- Ask the authorized reviewer to accept, reject or modify the proposal.
- Recheck current source revisions and authorization immediately before applying the approved change.
- Write the change via documented update operations using revision controls, and record proposal ID, base/result revisions, evidence, approval actor and timestamp in a protected audit record.
- Verify stored revisions and retrieval results; monitor index catch-up separately.
This sequence is an illustrative integration design. Teams must test permission validation and conflict controls against their own security policies, rather than assuming storage layers automatically calculate permission intersections.
Where AKB fits
AKB documents Git-backed document revisions, PostgreSQL text and metadata, and a driver-dependent derived vector index, alongside file storage and MCP interfaces. Its public core separates the knowledge store from autonomous curation. Teams may operate an external curation service through supported interfaces; this is distinct from claiming a preconfigured approval workflow ships with the core.
That gives a team integration points rather than a preconfigured approval workflow. Check the specific release’s supported events and update operations before building a consumer. For example, the README describes revision-aware editing with akb_edit(base_commit=...); verify its response to a stale revision in your installation. Do not treat arbitrary writes to an internal Git worktree as the supported application API.
According to the public AKB design philosophy, writes record structured events in a PostgreSQL outbox, which an optional worker fans out to a Redis Stream (akb:events) when redis_url is configured. This event-delivery mechanism does not guarantee exactly-once curation automatically. Operators must verify their deployed release configuration and implement durable checkpoints, duplicate/out-of-order handling, poison event retry limits, and recovery from potential event gaps, without assuming fixed payload schemas or delivery SLAs.
Connecting through the Model Context Protocol standardizes client-server communication. It does not decide who should approve a correction or what counts as accurate company knowledge. Those remain application and organizational decisions.
Separate service or integrated platform?
A separate curation service can fit an existing ticketing or review process. It also creates work: operating the consumer, managing credentials, handling retries, checking compatibility and maintaining the proposal queue. An integrated platform can reduce the number of components your team operates, but only if its actual workflow meets the requirement.
Evaluate both against the same scenario:
| Test | What to observe |
|---|---|
| A record changes while a proposal is awaiting approval | The workflow detects stale input, rechecks permissions, and requests reconciliation. |
| The same event is delivered twice or out of order | The consumer uses durable checkpoints and idempotency to avoid duplicate writes. |
| A write times out or returns a network error | Lost-response recovery inspects committed state before deciding whether to retry. |
| A reviewer or destination has restricted access | The proposal view verifies reviewer and target audience permissions to prevent leaks. |
| A consumer write triggers a downstream event | Verify a supported origin marker, event filter, or bounded processing rule prevents recursive reprocessing; record the observed result. |
| Write committed but indexing pending | Record storage success separately from retrieval verification; check the intended revision when indexing catches up. |
| An approved correction turns out to be wrong | Restoring the intended document revision does not automatically undo other records or downstream side effects; verify retrieval separately. |
Use the results to compare implementation and maintenance work. Neither architectural pattern is automatically cheaper, safer or maintenance-free.
Plan the operating boundary before launch
Write down the service owner, review owner, supported API version, credential scope, retry limits and lost-response recovery procedure. Because Git history alone is not a complete audit trail, maintain a protected workflow record capturing the proposal ID, base and result revisions, evidence, approval actor/timestamp, and write outcome. Keep a small integration test covering reads, updates, stale revisions, infinite-loop prevention, and denied access. Re-run it when either side of the interface changes.
AKB’s commercial-use terms are defined in the applicable release’s LICENSE. Review those terms for the intended deployment, especially when a service is offered to third parties; technical extensibility does not by itself grant unrestricted commercial use.
FAQ
Does a knowledge store automatically clean and approve its contents?
Only if that behavior is documented and configured for the product in question. Storage, retrieval, issue detection and approval are separate responsibilities. AKB’s public core should not be described as including an autonomous knowledge gardener.
Can one service propose and apply changes?
It can, if that is the intended policy, but the workflow still needs explicit authority and failure handling. For changes requiring human review, retain the approval decision and verify that it applies to the revision being updated.
What should happen if the source changes during review?
Reconcile the proposal against the new revision. Do not apply an old replacement blindly. Use the chosen product’s documented conflict mechanism and verify the final stored record.
Review AKB’s integration boundaries
Check the core store, supported tools and extension mechanisms for the release you plan to operate.
