Ars ContextaClaims, typed and queryable.
A vault of linked markdown claims becomes a graph the reactor indexes and a person approves into.
Knowledge managementRunnable demo
The boundary
A wiki link is text inside a file. The corpus holds 7,684 of them, and nothing outside the file that contains one can say what it means. In the vault a relationship is a typed row in the reactor's own table, so orphan detection, semantic search and map-of-content navigation all read the same edge.
Approval comes from a different actor than the author, and the model enforces it. An agent that drafts a note cannot move it to canonical, so nothing becomes settled knowledge because the thing that wrote it also blessed it.
The agent writes through typed operations and has no free-form path into the graph. A note is assembled from SET_TITLE, SET_DESCRIPTION, SET_CONTENT and ADD_TOPIC, so what it can do to a document is the list of actions the model defines.
The 249 claims stay on disk. They are the methodology a note is checked against rather than documents in your vault, so grounding a note against them writes nothing into the graph.
What is Ars Contexta?
Ars Contexta is an open-source methodology for agent-operated knowledge systems, published as a plugin under MIT. It derives a vault from conversation: atomic claims, maps of content and a processing pipeline, backed by a corpus of 249 research claims that cite one another. What it produces is markdown on disk.
- Data in
- Research claims, sources and working sessions
- Structure
- Atomic notes with typed links and provenance
- Access
- The agent may write, and may not approve its own note
- Direction
- One way in. Claims and sources become documents in the vault, while the methodology corpus stays on disk as reference the agent reads.
How material gets in
- The 249 research claims that ship with the plugin, read from disk as the methodology a note is grounded against.
- Articles, papers, transcripts and sessions, filed as a source document before anything is extracted from them.
The document model
This is the structure the integration writes into. The fields are the same whether a person opens the record, an application queries it, or a scoped agent reads it.
- title
- String
- One claim, written as a sentence.
- description
- String
- A summary, capped at 200 characters.
- content
- String
- The markdown body, with the argument and its references.
- noteType
- Enum
- concept, decision, pattern, architecture, bug-pattern and five more.
- status
- Enum
- Position in the lifecycle below.
- topics
- Array
- Tags the graph clusters and navigates by.
- provenance
- Object
- Author, source origin and the time it was written.
Lifecycle
- draft
- in review
- canonical
- archived
Every transition is a signed operation on the record, so the history of the document is the audit trail.
How it runs
- 01RecordA source lands in the vault with its origin, its type and a status, before any claim is taken out of it.
- 02ReduceOne note per claim, each carrying an edge back to the source it came from. The skip rate is reported rather than hidden.
- 03ReflectTyped links are proposed between the new notes and what the vault already holds, and every link has to state its reason.
- 04ReweaveOlder notes are revisited where a new claim changes what they should say, so the graph stays current in both directions.
- 05VerifyA quality gate checks description length, connection count and whether each link survives being read back.
Where the result shows up
One record, reachable from several places. The archive keeps the original document, and the structured state is available wherever the work happens.
- Knowledge Vault app
- Read the graph, browse notes by map of content, and ask questions of the same index the agent writes into.
- Connect
- Review a draft and approve it, which is the step the agent is not allowed to take.
- Switchboard
- Query notes, topics, backlinks and semantic neighbours over GraphQL.
- Agent host
- Claude Code, Codex, Cursor, Zed and others read one generated instruction set.
Ask the graph a question in plain language
{
knowledgeGraphSemanticSearch(
driveId: "<DRIVE-UUID>"
query: "how does the reactor store operations?"
mode: HYBRID
limit: 5
) {
similarity
node {
title
noteType
status
}
}
}Run it yourself
The example is published as a repository you can clone and run against your own reactor.
What you need
- A Powerhouse reactor with the bai-knowledge-note Vetra package deployed.
- The Switchboard CLI, pointed at that reactor by profile. There is no default vault, so the target is chosen rather than assumed.
- An agent host. Claude Code reads its own frontmatter file, and the rest read the AGENTS.md convention.
Packages installed
- arscontexta
- The methodology and its 249 claims, published under MIT at agenticnotetaking/arscontexta.
- powerhouse-knowledge
- The instruction set and eighteen skills. This is the vault's write path.
- bai-knowledge-note
- The Vetra package holding the document models the vault writes into.
- switchboard-cli
- Dispatches the actions, and injects the timestamp and action id each one needs.
Limits worth knowing
- Semantic search needs the Switchboard package at 1.0.50 or newer, which embeds notes and queries on the server. Older deployments fall back to keyword search without saying so.
- Batched actions are applied in reverse, so pipeline steps that depend on each other are dispatched one at a time rather than together.
- A description over 200 characters fails silently and takes the rest of its batch with it.
- An enum value outside the model's set reports success and writes nothing, which is why every write is read back before it is reported.
Start with a workflow assessment.
Find out where Powerhouse can improve operational efficiency. We structure the first workflow before a build starts.
All integrations