VIRGO

Product record graph

Source
docs/design/RECORD-GRAPH.md
Pinned at
d62e85485903a5537ee2b73c14201597e29bdaa5
sha256
b320c871efcee2ab11ca847d8d91e22c26f47a9c3c032ecc9e2146aa4293fc21

This page is the specification itself, rendered from the pinned source above. Its text is reproduced exactly; only its presentation is added.

Product record graph

Status: approved product contract (2026-08-04). Continuous-sync and reporting- line additions in this revision are proposed amendments.

Virgo records are typed, content-addressed graph nodes. Materialized files such as PEOPLE.md, DECISIONS.md, MEMORY.md, and FINDINGS.md are indexes and human-readable views; the graph is canonical.

Node contract

The first product node kinds are:

  • person
  • decision
  • memory
  • finding
  • work-record

The continuous-source proposal adds:

  • session for persistent logical-session records;
  • policy for reviewed canon invariants and authority rules; and
  • procedure for reviewed operational traps and confirmed recovery steps.

procedure is deliberately distinct from finding: a finding records an observed fact, while a procedure records what an operator or persona should do under a named condition. These kinds become active only with their reviewed schema and source-ledger amendments.

Every node carries a content hash, workspace and persona provenance where applicable, author/producer identity, source reference, and recorded timestamp. Payload validation is kind-specific, while the common envelope remains stable. Future kinds, including conversation archives, extend the kind registry without changing the common viewer or edge contract.

Edges

The common edge kinds are supersedes, relates, depends, and reports_to. Edges are directed, provenance-bearing records. A decision history therefore remains walkable across revisions instead of being flattened into the latest text. reports_to is directed from subordinate person to superior person and requires explicit source evidence; a title never implies a reporting line.

Continuous projection

Each source revision publishes a manifest-backed current view while retaining all prior nodes and edges. Stable reviewed record_key values let an unchanged record reuse its existing content hash; changed records and relationships add new content-addressed graph data. A current view may stop referencing an old version only through a reviewed successor or tombstone, never by deleting the historical record.

Push hints, periodic reconciliation, and manual virgo record sync all execute the same source-SHA-pinned, idempotent sync bundle described in RECORD-INGESTION.md. The graph never advances from an unreviewed Markdown interpretation.

Each registered source owns an independent manifest and CAS pointer. A unified semantic view may reconcile records across sources only through reviewed stable identity mappings and exact content-hash edges. Source priority is explicit: virgo-canon/base/PEOPLE.md is authoritative for person facts and reporting relationships, while persona copies remain lossless historical materializations rather than competing current person records.

Materialization

Persona checkpoint writes graph nodes first and then renders verified file indexes/views for the snapshot. Restore verifies node and edge hashes before materializing those views. A rendered file is never an independent source of truth: edits enter through a typed mutation path and produce a successor node.

First production validation

An existing long-form persona canon dataset (DECISIONS.md and QUEUE.md class documents) is the first real migration case. Acceptance must preserve dated entries, per-person decisions, supersedes chains, source provenance, and byte-verifiable rendered views. The migration is a product mechanism test, not a bespoke importer.