Core knowledge model
Knowl separates current truth, abandoned choices, temporary status, and supporting evidence into typed atoms while retaining history.
Atom categories
Every atom has exactly one of seven categories:
| Category | Use it for |
|---|---|
fact |
Stable project truths, conventions, and verified behavior |
decision |
A selected option with reasoning and alternatives |
goal |
An intended outcome that guides future work |
constraint |
A rule or boundary that must continue to hold |
architecture |
How components are arranged and interact |
state |
Current progress, readiness, blockers, or operational status |
skill |
A reusable procedure or learned workflow description |
A skill atom describes a procedure; it is not automatically an executable file-backed package.
Metadata, history, and ownership
The item is the current view; related records retain provenance and history:
- Status:
active,deprecated,rejected,archived, orsuperseded. Retrieval defaults toactive; other states remain queryable through explicit history and maintenance paths. - Freshness:
fresh,needs_review, orstale, independently of status. - Organization: numeric confidence and free-form tags.
- Source:
source,sourceCommit, and repository-relativeaffectedPaths. - Conflict identity: normalized key, sorted scope, and an optional exclusive flag.
- Ownership:
originRepo,visibility, and a repository label on peer results. - History: immutable assertions, linked evidence, and knowledge commits for governed changes.
Use a timeline when the question is what an item said before it changed:
knowl timeline <item-id>
knowl conflicts
knowl supersede <old-item-id> <replacement-id>
Supersession retires the predecessor with status: superseded; it does not delete the item,
its assertions, or its history.
Governed writes and current truth
The deterministic MCP write path accepts structured atoms without an AI provider:
knowl_store({
"category": "constraint",
"title": "Authentication tokens stay server-side",
"content": "Browser code must not persist bearer tokens.",
"tags": ["auth", "security"]
})
When a verified correction replaces an item already returned by retrieval, make the relationship
explicit in the same store call with supersedes, or store the replacement and then point the old
item at it:
knowl_update({
"id": "<new-item-id>",
"supersedeId": "<old-item-id>"
})
With the default security configuration, every structured write rejects content that exceeds the
configured size boundary, contains a detected secret, or references a sensitive path.
security.rejectSecrets=false disables both secret detection and the sensitive-path check; field
and raw-output size limits still apply. Accepted writes then follow these reconciliation rules:
- An exact normalized title-and-content match is a no-op.
- Knowl examines up to the top three active BM25 candidates in the same category.
A normalized title subset with at least two significant shared tokens and at least
0.35significant-token overlap identifies the same subject and retires the predecessor. - If no detected candidate qualifies for supersession, an explicitly named active
supersedesitem is retired. A qualifying detected same-subject candidate currently takes priority when it differs from that explicit ID. - Other semantic or lexical overlaps coexist. The result reports the nearby active item so the caller can reconcile it explicitly if necessary.
- An exclusive write is rejected before insertion when another active exclusive item has the same normalized conflict key and sorted conflict scope.
These rules apply across atom categories rather than assigning special fuzzy behavior to only decisions or state. Batch ingestion and update-plus-supersede sequences should not be treated as an atomic multi-record transaction: current operations may commit individual records separately. Use explicit IDs and inspect the returned result when a correction spans records.