Vision
Why Muse exists, what makes it fundamentally different from file-level version control, and why semantic diffing is the only model that scales to the AI-agent era.
Why Muse
Git versions files. Muse versions meaning.
The unit of history is not a byte sequence — it is a thing with structure, semantics, and independently meaningful dimensions.
Every version control system before Muse treats repositories as bags of files and changes as line-level byte diffs. That model works well for source code where the file is the natural unit of meaning. It breaks immediately the moment your data has richer structure: a MIDI arrangement with 21 independent musical dimensions, a genome with overlapping annotations, a 3D scene with material and mesh data on the same asset.
Muse asks a different question: what is the smallest independently meaningful unit in this domain? For MIDI it is an individual note event attribute. For code it is a symbol. For genomics it will be a base-pair annotation. The answer determines the diff algebra, the merge strategy, and the conflict surface — and Muse's domain plugin protocol makes all three programmable in six methods.
The binary diff problem
Here is the same change — a velocity adjustment on three notes — as seen by Git and by Muse:
Git cannot tell you what changed inside a MIDI file. It hands you two opaque blobs and says they differ. Muse knows that three notes in bar 2 had their velocity increased. It knows which notes, which attributes, and by how much. It can display that diff to a human, replay it for conflict resolution, and apply it surgically to a merge.
The same principle holds for any structured domain. A genome annotation update is not "the file changed" — it is a specific base-pair range with a specific annotation delta. A 3D scene change is not "the asset changed" — it is a material property on a specific mesh node. Muse gives every domain the language to say exactly what changed.
Independent dimensions auto-merge
When two changes touch independent dimensions of the same object, there is no conflict. Muse detects this and merges automatically — no human intervention required.
Alice modifies cc_sustain — MIDI continuous controller 64.
Bob modifies C4.velocity — the attack velocity of a note.
These are two different rows in the MIDI event model. They are
structurally independent. Muse merges them without any conflict, just as
two developers editing different functions in the same file merge cleanly
in Git.
The difference: Git's independence is at the line level. Muse's independence is at the semantic dimension level — which is what actually matters for the domain.
MIDI: 21 dimensions, 18 independent
A MIDI file is not a blob. It is a composition of 21 named dimensions. 18 of them are completely independent — changes on separate dimensions never conflict. Only the 3 positional dimensions (onset position, bar reference, beat reference) interact, because two events at the same position on the same pitch create genuine ambiguity.
This is the mathematics of music: the sustain pedal and the note velocity are as independent as two different variables in a program. They happen to be encoded in the same binary file, but that encoding is an implementation detail. Muse works on the semantics, not the encoding.
Domain agnosticism
The domain plugin protocol is six methods. Implement them for any state space and you get content-addressed history, branching, three-way merge, time-travel, typed diffs, and semantic conflict resolution — for free.
class MuseDomainPlugin: def snapshot(self, live_state: LiveState) -> StateSnapshot: ... def diff(self, base: StateSnapshot, target: StateSnapshot) -> StateDelta: ... def merge(self, base: StateSnapshot, left: StateSnapshot, right: StateSnapshot) -> MergeResult: ... def drift(self, committed: StateSnapshot, live: LiveState) -> DriftReport: ... def apply(self, delta: StateDelta, live_state: LiveState) -> LiveState: ... def schema(self) -> DomainSchema: ...
The object store, snapshot model, commit DAG, branch refs, push/fetch
wire protocol, and all of Harmony's conflict resolution machinery are
completely domain-agnostic. They operate on
sha256:<id> blobs and typed delta lists. The domain
plugin tells Muse what the blobs mean.
AI agents need this
Git was designed for human developers committing once or twice a day. AI agents commit hundreds of times per session. They branch, merge, and resolve conflicts in automated pipelines with no human in the loop.
At that scale, binary diffing breaks down entirely. When ten agents are editing the same module simultaneously, "these two byte sequences differ" is not a conflict resolution strategy — it is a deadlock. You need a system that understands what changed, at what granularity, and why two concurrent changes are or are not compatible.
Muse was built for exactly this model. Every commit carries cryptographic
agent provenance (--agent-id, --model-id,
--sign). The coordination system (Phase 06)
provides work queues, reservations, and conflict forecasting. Harmony
(Phase 05) learns from every resolved conflict
and auto-replays known resolutions. The MCP server
(Phase 07) exposes all of this to any agent that
speaks Model Context Protocol.
The result: agents can commit at machine speed with full semantic awareness of what they are changing, what might conflict, and how prior conflicts were resolved — without human intervention on the happy path.
Domains
Any state space with a programmable diff algebra becomes a first-class Muse domain. Two are live today; more are on the roadmap.