# Doctrine entity engine

Every authored artifact type in doctrine — slices, ADRs, specs, requirements,
and memories — rides one shared entity engine rather than a bespoke
implementation each. When you add or change an artifact, you are working *with*
this engine, not around it.

What the engine gives every entity:

- **Identity + a claim seam** — a stable uid minted once, plus the
  born-frame/claim mechanism that records where an entity came from. The impure
  capture lives behind a thin seam (`src/git.rs`); the pure layer never touches
  clock, rng, git, or disk directly (the date/uid pattern).
- **Relations and edges** — typed references between entities live in the small
  sister TOMLs (e.g. `slice-nnn.toml`), never in prose bodies, so a registry can
  parse them cheaply. This is the same TOML/MD split the storage rule mandates
  ([[mem.concept.doctrine.storage-model]]).
- **The behaviour-preservation gate** — the engine is shared machinery. When you
  change it, the existing test suites are the proof of correctness: they must
  stay green *unchanged*. Don't rewrite a passing suite to accommodate an engine
  change; that defeats the gate.

Don't build a parallel implementation for a new entity type — ride the existing
seam and look for duplication first.

Point of truth: `doc/entity-model.md` (the consolidation direction and the one
storage rule everywhere) and `doc/relation-index.md` (why relations stay in
typed sister files and a cache is deferred). The code lives under `src/`. See
[[mem.signpost.doctrine.file-map]] for the layout and [[mem.pattern.doctrine.conventions]]
for the pure/imperative split and no-parallel-implementation rules. For the
relation-authoring surface, see [[mem.signpost.doctrine.relating-entities]].
The concept map ([[mem.signpost.doctrine.concept-map]]) provides a visual
overview of these entity relationships.
