A compiler for knowledge.

How a capsule is born

Six stages, one invariant: models propose, humans decide, the compiler is deterministic. Each stage emits a typed, schema-validated artifact — so the process itself is inspectable, not just the result.

1. 01

   Source pack

   Documents are normalized into a content-addressed pack: every file hashed, every span addressable, rights recorded. Nothing enters the capsule that cannot be pointed at later.

   source_pack.json · spans · sha256 per document

2. 02

   Extraction proposals

   Models read the pack and propose — claims, episodes, graph edges, ontology terms, reasoning devices, language rules. Proposals are typed records with confidence and source spans. The architectural rule is absolute: models propose, they never write.

   extraction_proposals.jsonl · proposal boundary (ADR-007)

3. 03

   Review gates

   A human expert decides: approve, approve with caveats, or reject — per record. Decisions are part of the capsule forever, with the reviewer’s role and reasoning attached. This is where tacit judgment enters the object.

   reviewer_decisions.json · review_queue.json

4. 04

   Promotion

   Approved records are normalized into the canonical ledgers. Rejected ones leave a trace — so the next analyst can see what was considered and declined, not just what survived.

   promoted_record_set · promotion_summary.json

5. 05

   Deterministic compile

   The compiler assembles the nine-layer bundle byte-stably: the same inputs always produce the same bytes. Determinism is not a nicety — it is what makes a future signature mean something.

   manifest · ledgers · graph.jsonld · embedded graph

6. 06

   Archive & packs

   The bundle ships as a portable .capsule archive and compiles down to whatever the consuming agent speaks: a PRAXIS context pack, an agent skill, an MCP resource.

   .capsule (mimetype-first zip) · context packs

The proposal boundary is the engine’s deepest design decision. A model can be brilliant and wrong; a capsule must be checkable. By restricting models to proposals — typed records that a named human promotes or rejects — DIALECTICA gets the best of both: machine breadth, human warrant.

Why layered graphs, not one big graph

A single undifferentiated graph collapses things that must never be confused: what a source said, what an analyst concluded, when each became known, and which method produced the judgment. DIALECTICA keeps them as nine named graphs inside one JSON-LD document — each with its own mutability contract and trust character.

The payoff is precision on both sides of the human-machine boundary: an agent can cite at the right level (this claim, from this span, under this trust rule), and a human can contest at the right level (the source is fine; the inference is wrong; the method was misapplied).

Every capsule ships its own graph database

Alongside the semantic JSON-LD, the compiler builds a read-only Ladybug projection — capsule.lbug — an embedded graph database queryable with Cypher, no server required. It is digest-pinned to the source graph: if the semantic layer changes, the projection is rebuilt and both hashes are recorded. The snippets below are from the actual reference capsule, not mockups.

CREATE NODE TABLE CapsuleNode(
  id STRING, node_type STRING, label STRING,
  review_state STRING, source_span_ids_json STRING,
  properties_json STRING, PRIMARY KEY(id));

CREATE REL TABLE CapsuleEdge(
  FROM CapsuleNode TO CapsuleNode,
  id STRING, edge_type STRING, confidence DOUBLE,
  temporal_scope_json STRING, source_span_ids_json STRING,
  review_state STRING, explanation STRING);

MATCH (n:CapsuleNode) RETURN count(n) AS node_count;

MATCH (a:CapsuleNode)-[e:CapsuleEdge]->(b:CapsuleNode)
RETURN a.id, e.edge_type, b.id LIMIT 50;

"engine": "ladybug",
"database_path": "graph/ladybug/capsule.lbug",
"source_graph_digest": "sha256:f28a32eceba22140f2e14a19508e4bd8…",
"projection_digest":   "sha256:8ee639b5cec225f95127ab60250fc611…",
"read_only": true,
"rebuildable": true

Each capsule type gets a graph profile suited to what it holds:

Two clocks, thirteen relations

Every claim carries two timestamps: when the thing happened (valid time) and when the capsule learned it (observation time). The separation is what lets analysis be honest about its own past — “what did we know on the 14th?” is a query, not an argument. Episodes relate through Allen’s thirteen interval relations, and superseded claims chain to their successors instead of disappearing.

A kernel grammar, extended per capsule

The semantic layer starts from a kernel of eight typed primitives — the grammar practitioners actually think in — and grows a capsule-specific ontology blueprint on top: domain terms proposed during extraction, mapped with confidence, and promoted through the same review gates as everything else. The kernel is stable and MIT-licensed; the extensions are local, versioned, and provenance-mandatory.

The nine capsule layers and the eight kernel primitives are orthogonal: primitives are the vocabulary, layers are the epistemics. A Commitment is a primitive; whether it sits in claims (asserted), temporal (scheduled), or governance (reviewed) depends on what kind of statement is being made about it. Full formal treatment: the grammar and Ontology-Augmented Generation.

Byte-stable today. Signed next.

The compiler is deterministic: identical inputs produce identical bytes, every time. That is the precondition for the integrity envelope on the spec roadmap (ADR-009) — a Merkle root over the bundle, Ed25519 signatures, and a one-line capsule verify. Today every published capsule carries its SHA-256, and the Seal you see in the viewer is drawn deterministically from that hash. We state plainly what is shipped and what is roadmap — on this page and everywhere else.

Capsule anatomy, for reference: evidence · claims · graph · temporal · ontology · reasoning · memory · governance · runtime.