Why Yupana, and how it compares

Structural code intelligence is not new, and the strongest tools each prove out one signal. Yupana takes the best idea from each, then adds what none of them have: a whole team editing at once, governance, and time.

What it is for

• 🧵 Correct while a team edits. A shared base graph plus a copy-on-write overlay per developer or agent keeps every view right while many of them edit the same code at once. See The Tenancy Model.
• 🔀 Fusion, not one signal. Call and dataflow structure, plus historical co-change, plus embeddings. A coupling backed by a dataflow path is real; one without it is a refactoring smell, and only fusion tells them apart.
• 🪢 Governed and time-travelable. Committed facts promote into Quipu as SHACL-validated, bitemporal RDF: a versioned source of truth, not a best-effort cache. See Promotion to Quipu.
• 💥 Blast radius as a primitive. "What will this change break" is one query, per tenant, and it doubles as the incremental-update engine.
• ⚡ Two-tier freshness. Tree-sitter speed for breadth and LSP precision for depth, with every fact tagged by the tier that produced it so an agent knows what it is trusting. See Tiers and Freshness.
• 🛡️ Structure scopes the sandbox. Per-tenant blast radius bounds what an autonomous agent may touch, and can act as a guardrail on what it generates, not only as context.
• 🪙 Token-cheap. Structural answers instead of whole files in context.

How it compares

Each of these proves one piece. multilspy shows that LSP facts can also guard what a model generates; Joern established the Code Property Graph and dataflow; codebase-memory is a lean standalone analyzer with content-hash incremental freshness. Yupana is closest in spirit to codebase-memory, extended with Joern-style dataflow, LSP precision, tenancy, and a governed projection into Quipu.

The advantage is not any single signal. It is fusion, governance, time and tenancy, kept correct while a whole team edits.

What is built today

• Structure: analyze, refs, callers, impact (with --cochange reconciliation), intra-procedural dataflow, and verify, which returns a verdict on a proposed edit buffer. See the CLI reference.
• Serving: an MCP server (yupana serve) exposing the yupana_* tools, and a resident daemon (yupana daemon) that keeps the base graph and per-tenant overlays hot. See MCP Tools and Resident Daemon.
• Governance, around the graph: the pre-edit policy guard (scopes, structural and text rules, tripwires, and the work-item scope ladder), the record-only Bash action hook, session-start work-item briefings, the game-state harness, and the golden-path conformance guard. See Pre-Edit Policy Guard.

Rules that come from Quipu start at the advise tier: they warn, and they block only once their own enforcement gates are met. yupana exemplar drafts rule candidates from an example of what should have been caught, and yupana verifier prints the key that signs verdicts, for registering in Quipu. The full phasing is in the specification.