Vault card schemas v2: extension fields, memory families, tension/tombstone + validator

[aarontrowbridge]

Important

Problem — The vault's card schemas cover 12 note types with no provenance/confidence/TTL/subject fields, no memory-card types (the filename-typed feedback_/project_/reference_/user_ family is invisible to validation), and no tension/tombstone types — so no downstream engine can query the corpus, and no validator can refuse an ill-formed card.
Approach — The open-contract half of the distillation pass (spec: Card Families + schemas): extend the 12 schema-check types with optional extension fields, add the 4 memory-family types, add tension and tombstone, define the reviewed provenance_unrecoverable sentinel, and ship the validator with its negative corpus in amicode (open — anyone can validate a card; enforcement stays in telaio).
Scope — in: schema files for 12+4+2 types, sentinel semantics, validator, valid + negative fixture corpora · out: the writer layer, any pass runtime, index derivation.

Acceptance Criteria

• All 18 types validate: 12 extended schema-check types, 4 memory families (feedback/project/reference/user), tension, tombstone
• Extension fields enforced where present: provenance (pointer list), confidence (low/medium/high), review_by (ISO date), subject (normalized string)
• The sentinel: provenance_unrecoverable: true valid ONLY alongside an empty provenance list and a resolvable reviewed_after journal pointer; an unreviewed sentinel is a schema violation
• Tombstone justification vocabulary closed: superseded_by · expired_ttl · provenance_unrecoverable · redundant_with; pointers must resolve to existing non-archived cards; expired_ttl names a well-formed past date
• Negative corpus: ≥ 15 invalid fixtures refused with the violated schema path named (sentinel-without-review, provenance+sentinel both set, unknown confidence, malformed review_by, open-vocabulary tombstone, dangling tombstone pointer, untyped card, unknown-type card, …)
• Valid corpus: ≥ 30 cards across ≥ 6 types, all pass and round-trip (serialize → deserialize → re-serialize, byte-equal under canonical JSON)

Testing Decisions

New surface in amicode (the validator is new code; the schema-check skill's table is the documented contract this implements). Authorship split (reviewer ≠ implementer) attested in the fixture README.

Key Decisions

Schemas are JSON Schema files, versioned, published as the open contract (a telaio writer enforces; anyone may validate). Extension fields optional on the 12 legacy types (migration is the census's job, not the schema's). The claim-bearing type list lives in the spec (normative v1) — this slice implements the provenance field on exactly those types plus tension/tombstone rules.

Constraints & Invariants

No behavior change to existing notes: a legacy card with no extension fields validates today (census stamps later). Field names exactly per the spec's data contracts.

Prior Art

The amico-schema-check skill (the 12-type table + auto-fix rules this extends); the spec's Card Families section.

Source

Part of harmoniqs/telaio#14 · spec spec-20260821-090401-vault-distillation-pass.md (Card Families, D2, Measurement Protocol) · no blockers. Cross-repo slice: this issue lives in amicode; the parent and sibling slices live in telaio (native sub-issue edges cannot span repos — this line is the mirror).

[aarontrowbridge]

Scope note (Amendment 2 to the distillation-pass spec, 2026-08-22 — insight-20260822-172218 in the personal vault): the vault reorganizes into seven planes (capture / state / knowledge / evidence / runtime / archive / index), organized by movement rather than document genre. For this slice: type schemas are unchanged — they survive as card frontmatter inside knowledge/ (minimal provenance on evidence/ records). The one addition is a plane-residency column in the type table (which plane each type lives in). The validator/fixtures otherwise proceed as specced.

[aarontrowbridge]

Scope-note update (Amendment 2 was revised same-day after adversarial review — see the spec's review note): the records-vs-cards distinction is now load-bearing for this slice. Plane residency determines machinery: knowledge/ residents are CARDS (full schemas, the 12+4+tension/tombstone types); evidence/ residents are RECORDS — a separate minimal schema (type, date, origin pointer only — never stamped, TTL'd, or superseded); work/ residents are working documents outside card machinery. So the schema slice delivers: the card schemas as before, PLUS a minimal record schema for evidence-plane files, PLUS the plane-residency column. The 'no code slice changes' framing from the first draft is withdrawn — this is a real (small) schema addition.