Docs / Memory model

Current facts. Addressable history.

Ax0s treats correction as a record transition. Normal recall favors live records; an explicit query can include the history those records replaced.

A record belongs to a project and collection.

The write contracts select a project slug and either attach to an explicit collection or use the product’s documented loose-collection behavior. Text, role, record type, tags, source fields, and agent fields travel with the record when provided.

See the provenance field table.

Recall returns a stable top-level shape.

The serialized contract contains slug, query, mode, limit, elapsed_ms, tokens_estimate, and hits. Optional per-hit fields appear only when present.

Default current view: superseded and expired records are excluded unless the caller explicitly opts in.

Correction does not require deletion.

Stale facts are superseded instead of deleted, and their history stays addressable.

  1. A source-linked record is written.
  2. A later correction becomes the current record.
  3. The earlier record is marked superseded and stays addressable.
  4. Normal recall returns the current view; --include-superseded includes retired history.
FIG 3.1 · recorded 2026-07-14 · v0.5.0

How did Wednesday become current without erasing Friday?

Scope: one recorded product round trip; environment stated in transcript header · Source: recorded terminal artifact

Recorded Friday-to-Wednesday supersession chain The Friday record and Wednesday correction enter a pending near-duplicate queue. A person confirms the candidate and applies it. Wednesday is current and carries a related pointer to the retained Friday record, which is marked superseded in history recall. 01 · FRIDAY RECORD record:r_demo_friday Friday · 17:00 UTC written first · initially live 02 · WEDNESDAY CORRECTION record:r_demo_wednesday Wednesday · 15:00 UTC written later · proposed keeper 03 · CONSOLIDATION QUEUE near_dup · status pending keep_id → Wednesday retire_ids → Friday applied 0 · queued 1 04 · DECISION human confirm then apply applied 1 queued 0 05 · CURRENT Wednesday is_superseded false related → Friday 06 · HISTORY Friday retained is_superseded true valid_until set retire_ids keep_id confirm apply related pointer

Scroll horizontally on a narrow screen to inspect the full chain.

Takeaway: This one receipt shows a human-confirmed replacement and retained history; it does not prove concurrency safety, durability, or automatic resolution for every conflict. Open the raw transcript.

Review the canonical implemented-capability row and pending release record.

Storage behavior is not an authorization promise.

Project slugs, collections, and record metadata describe storage and retrieval scope. They do not extend the access-control claims in the capability matrix or the security dossier.

Trace the fields behind these semantics.

Inspect record provenance fields, exercise the same paths from the CLI, or check the capability boundaries.