The Metadata Knowledge Base
Behind every Mushin application is a structured specification — a precise, machine-readable description of the app’s data, pages, and services. Mushin calls the language of this specification KenshoProtocol, and the accumulated specification the metadata knowledge base. It is what the code generator reads to produce your application. This page explains it.
KenshoProtocol
As the AI develops your design in natural language, that design is distilled into KenshoProtocol — a set of exact commands describing the application:
- add a thing (a table, a field, a relationship, a page)
- remove a thing
- rename a thing
Each command names precisely what it affects. Where the natural-language design reads like a specification a person would write, the KenshoProtocol is the exact, unambiguous form of that same design — detailed enough to generate working code from, and small enough to review a change at a time.
The knowledge base
The KenshoProtocol commands accumulate into the metadata knowledge base — the current, versioned set of facts about your application. It captures the shape of your app:
| Kind of fact | Examples |
|---|---|
| Data model | Tables, their fields, relationships between them, unique constraints and indexes |
| User interface | Pages, the components and widgets on them |
| Services | The operations your application exposes |
Because the knowledge base is tied to your project’s commits , it is versioned along with everything else — you can see the specification as it stood at any point in the project’s history.
Building the knowledge base
The knowledge base is (re)built by the Build Meta step — one of the BrainChain job types. Build Meta reads the KenshoProtocol produced in your design streams, parses it, and rebuilds the knowledge base from it. The parser is built to be forgiving of the AI’s output, so a slightly untidy response is still turned into clean, structured facts.
Running Build Meta is how the structured layer is kept in step with the design you have committed — the “sync” step of the Mushin Cycle .
Why keep a structured layer at all
Generating code straight from a chat gives you a result but not a specification you can reason about. The knowledge base gives you both: a readable design and an exact, versioned, structured description of your application that the generator turns into code deterministically. It is what makes a Mushin application reviewable, diff-able, and reproducible.
Related pages
- The Neuro-Symbolic Approach — how the KenshoProtocol is produced
- BrainChain — the Build Meta step
- Code Generation & Templates — turning the knowledge base into code