Understand the change,
not just the latest value.

The demo records a sequence of complete workspace snapshots. The revision identifies the state used by the graph, record list, and query engine.

Read the same state everywhere

Every accepted import, model change, record edit, relationship change, or source update creates a new revision. The revision selector changes the data being read, not just a timestamp displayed beside the current values.

Historical views are read-only. A record created after the selected revision does not appear in that earlier state. A previously deleted record can be inspected from revisions where it existed, and its history does not pull future values into its historical properties.

The History view shows actual before-and-after record changes, along with model additions and newly retained sources. A model-only revision is explicitly identified rather than being presented as an unexplained empty change.

Retain the input, then the correction

Each record and relationship has a source reference. An import retains its source payload. A later edit or observation adds a new source rather than rewriting the earlier source snapshot.

The current sourceId identifies the latest recorded change to the record. It is record-level attribution, not a claim of independent field-by-field lineage. Earlier revisions retain the record values and source references that existed at those revisions.

Verify an observable change

Start from the initial sample at revision 4. The exposed-enterprise query returns three accounts. Applying the payment recovery observation updates both the Payments service and its incident in one accepted change. Revision 5 returns two accounts.

Aster Labs and Fieldwork still match through Analytics and the degraded Reporting API. Selecting revision 4 restores the earlier query result while leaving revision 5 intact.

Restore a record, not the whole world

Use a record’s History tab to restore an earlier version. Restoration is a new write at the latest revision. It does not erase newer history or rewind other records.

Restoring only the Payments service does not also restore its incident. That is an intentional distinction between an individual record restoration and a coordinated domain update. A generic database cannot infer which other business facts you intend to change.

A restored relationship must still have valid participant records in the current model. Invalid restorations fail without partially changing the workspace.

Local retention and backups

The demo retains up to 80 revisions, including the initial empty revision. It stops accepting new revisions at that limit rather than silently dropping old ones. Export the workspace and explicitly create a new one to continue.

Browser storage is best effort. Use a full JSON export to keep the model, records, relationships, sources, and retained revisions together. Restoring a backup validates each revision and requires a contiguous revision sequence.

This is recorded snapshot history. It is not a complete bitemporal implementation, a distributed transaction protocol, or a hosted retention guarantee.