The three graphs

One record, read three different ways

A single relational ledger holds the truth. The graphs are projections that can be rebuilt at any time, which is why an indexing problem is never a data loss problem. Each graph answers a different question, and none of them is allowed to become a second authority.

Code graph

Understanding what a change would reach

The code graph covers symbols, calls, data boundaries, impact and code taint. MUON does not build this layer itself. It pins and ships GitNexus, an open indexing project, and binds the results to your recorded decisions and review obligations.

Everything a change to chargeCustomer would reach

POST /checkoutretryQueuechargeCustomerchargeLedgerrefundWorkercharge testsreceiptMailer

Choose a symbol

6 direct relationships indexed

The code graph is served by GitNexus, the indexing project MUON pins and ships with. MUON adds the part GitNexus does not try to do: attaching your recorded decisions to the same coordinates and deciding whether an agent is allowed to make the edit.

Credit where it is due

The indexing layer comes from GitNexus

We use GitNexus for repository indexing, impact queries and data flow evidence because it already does that job well. MUON pins a known version of it to the workspace so the results stay reproducible, and treats the output as evidence rather than as authority.

What MUON adds

Decisions and permission on the same coordinates

An index tells you what calls what. It cannot tell you that the payment team decided something about this function in March, that a constraint applies to it, or that this particular agent is not allowed to edit it. Those three answers are the part MUON is responsible for.

Knowledge graph

Answering who decided what, and why

Every material decision resolves to the person or agent who made it, the authority they held, the mission and code coordinates, the evidence they were given, the alternatives, the reason, and what the decision replaced. People and agents read the same objects.

The knowledge graph for one payment service

Select any record to see what it holds and which other records it is connected to. Colour marks how far a claim has travelled: confirmed, crew vouched, still pending, or superseded.

supportsapplies togroundsboundssame sourceD-114C-27C-31retry originretry windowkey derivationunique indexold beliefchargeCustomer0054_keysPriya
Confirmed decisions and constraints in blue, crew vouched memory in green, pending proposals in amber, superseded records in red, code anchors in yellow.

Selected record: Retries come from the gateway rather than the client

Crew vouched memory

Retries come from the gateway rather than the client

Proposed by the explorer lane, then corroborated independently by the implementer lane while reading the queue code. It can be retrieved and cited, and it is still waiting for a person to confirm it.

Crew vouched · 2 sources

Connected records

Retrieval

Several arms, one disclosed policy

Lexical search, dense search, entity matching and exact anchors each produce ranked candidates, and they are fused under a policy you can read. Graph expansion adds bounded lineage after the roots are chosen. Being central in a graph never makes a claim true.

Clustering

Memory belongs to more than one place

Tenant, workspace and authorisation scope are hard partitions. Inside a partition, a memory can belong to a mission, a repository, a symbol, a person, a decision and an outcome at the same time. Cluster membership improves navigation and never grants authority.

Context and communication graph

Seeing who is working on what while it happens

Live agents, tasks, sessions, work claims, messages between agents, context frames, deliveries, handoffs, dependencies and attention state. It is a directed multigraph, because real reviews and conversations go in circles.

One mission as the runtime sees it

Drawn from a sample record. Select a node to see what the runtime recorded about it during the run.

assignsdispatchesdispatchesdispatchesallocatesdeliversdeliversmissioncoordinatorimplementerexplorerreviewerwork claimhandoffcontext framemerge gate
Every dispatch, delivery, claim and handoff is written to the ledger, so a completed mission can be replayed exactly as it happened.

Selected record: The coordinator holds the plan and the gates

Agent lane

The coordinator holds the plan and the gates

It decides how many lanes the work needs, writes each role contract, allocates context to each lane and stops the run at the points a person has to decide.

Claude Code · coordinate class

Connected records

  • A work claim on a file stops a second lane from editing it in parallel
  • Messages between agents are recorded, so a change of direction has an author
  • Handoff packets carry the evidence rather than a summary of the evidence
  • Directed acyclic graphs model the parts that really are acyclic: objectives, dependencies, delegation and supersession
Taint

Untrusted input stays labelled

MUON tracks information and authority flow from an untrusted source, through transformations, summaries, messages and context delivery, all the way to a sensitive sink. Grounding, corroboration, confirmation, redaction and policy checks are the only things that clear a label. Summarising a tainted document does not launder it, and neither does citing it.