Start with one low-impact fact, such as an approved project convention. Keep extraction, approval and reuse separate so the team can see why a later session trusts the record.
Key takeaways
- Begin with one useful fact type: accept a narrow record with a source and scope.
- Keep candidates separate: extraction proposes a value; application policy decides whether it becomes reusable.
- Handle contradictions explicitly: route a conflicting value to review instead of silently replacing accepted knowledge.
Choose a record that the team can explain
A convention record needs a project, the convention, its source, an effective date where relevant, and a review state. Add only the fields the workflow needs.
In a synthetic conversation, an owner says, “For project Atlas, run pytest -q.” The extractor proposes the command as a candidate scoped to Atlas and cites that conversation as its source; after an authorized reviewer approves it, a later Atlas session retrieves and reuses pytest -q.
The OWASP prompt-injection guidance is useful context for separating instructions from untrusted content. The candidate schema and acceptance rule remain application decisions.
Use three visible states
| State | Meaning in this proposed workflow | Next decision |
|---|---|---|
| Candidate | A value has been extracted but is not accepted knowledge | Validate source, scope, type, and retention eligibility |
| Accepted | The configured rule or authorized owner approved this version | Make it available within the approved scope |
| Review required | Evidence conflicts, required fields are missing, or impact needs a person | Correct, approve, or decline the specific proposal |
Keep the source reference so an owner can revisit the decision. Before accepting a write, recheck the writer or reviewer’s current authorization and the record’s expected version to avoid overwriting a concurrent change.
Make repeated and conflicting writes predictable
A repeated proposal should not create needless duplicates. A conflicting value needs a clear route: proposed revision, review, or refusal. An older source arriving later must not automatically replace a newer accepted decision; use its effective context and review result. These are requirements for the write path, not assumed product behavior.
Add the knowledge destination last
AKB provides shared, vault-scoped documents, tables and files, linked by AKB URI relations and accessed through MCP, Web UI or REST. Use it for accepted knowledge and linked evidence. Conversation extraction and curation remain separate unless the selected edition documents them.
Before making the accepted item retrievable, test that the intended agent sees its source and version and that another project cannot access it. Approval of a stored convention should also remain separate from permission to run a tool described by that convention.
Rehearse a correction
Have the owner correct a convention, then retrieve it from a new session. Check the accepted version, history and affected search or cache entries. The owner should also know how to withdraw the record and find failed writes. Add more record types once this process works.