Mushin Docs / The Neuro-Symbolic Approach

The Neuro-Symbolic Approach

A Mushin project builds an application the neuro-symbolic way: the AI’s natural-language design (the “neural” part) is distilled into a precise, structured specification (the “symbolic” part) that you can review, version, and generate from. This is the deliberate, auditable way to build something larger. This page explains how it fits together; the mechanics of versioning are in Design Streams & Version Control .

Why neuro-symbolic

Describing software in a chat is fast, but for a real system you want more: to see exactly what the AI decided, to change one part without disturbing the rest, and to keep a reviewable history. Mushin gives you that by keeping two representations in step:

  • A natural-language design that reads like a specification a person would write.
  • A structured form of that same design — the KenshoProtocol — that is exact enough to generate code from.

You work in natural language; Mushin maintains the structure alongside it.

Organizing with features

You divide a Mushin application into features — named slices such as “accounts,” “billing,” or “reporting.” Each feature has its own blackboard , so the requirements of one feature stay separate from another’s and the AI can concentrate on one feature at a time. Features are how you keep a growing application legible.

Design streams and prompts

Within a feature you work in design streams. A design stream pairs the AI with two guiding prompts :

  • A persona prompt sets the role the AI plays — a data architect shaping your tables, a UI designer shaping your pages, and so on. Different personas develop different aspects of the application.
  • A delta prompt governs how the AI expresses changes — so each contribution reads as a clear, reviewable difference rather than a wholesale rewrite.

You provide an input — what you want this stream to work on — and the stream produces a contribution to the design, which you review before it becomes part of your specification. The design-stream editor gives you the input, the resulting output, the difference it introduces, and the structured metadata it produces, each on its own tab.

From design to structure

The step that makes this “neuro-symbolic” is the distillation from language to structure. The AI first works out a design in natural language; that design is then converted into KenshoProtocol commands — the exact “add this table, add this field, add this page” statements that make up your application’s specification. You always have both: the readable design and the precise structure it compiles to.

Committing your work

When you are happy with a contribution, you commit it. Committing snapshots the blackboard and folds the new structure into your application’s metadata knowledge base . If a contribution went the wrong way, you can revert the last commit. This commit-by-commit rhythm — building the specification up in reviewable steps — is the heart of a Mushin project, and it is covered next.

← PreviousBuilding Conversationally