Records and history
Records and history let you read what exists and what changed in Records & Lists. A past value answers a different question from a current value.
Ownership
Records and history address one Record by its Entity kind and identifier. Two kinds can use the same identifier, so a bare id is not a full address. Schema model owns the kind and its fields. The Record owns the values stored under that definition. In the Console, /records starts with a kind before showing its Records.
Lifecycle
Records and history separate a current read from a point in time. A create or update returns the changed Record when the write succeeds. History can browse a Record's version windows, read its state at an instant, or compare two instants. A comparison must end at or after its start. Those reads inspect past state. They do not restore it or authorize an undo.
Boundaries
Records and history apply current access decisions even when the requested values are old. A history read cannot recover a field that the caller is no longer allowed to see. Public history names one declared kind and Record id. An Interface is not a history target. Activity describes work across kinds. Record history instead answers what changed on the one Record you selected.
Failures
Records and history can refuse different parts of a read. An unknown kind or incomplete address cannot identify the Record. A denied field does not become readable through a List or past state. A missing historical result does not prove the current Record never existed. Check the selected time and the returned history outcome before drawing a conclusion about when a value appeared.
| History outcome | Meaning and response |
|---|---|
history_pending | Current values are saved, but history has not caught up. Read history again later. |
history_unavailable | The history store cannot be read. Resolve the outage before reading again. |
unknown_interval | The requested interval was not captured. Recover the missing history or retain the gap as unknown. |
Recovery
Records and history need the same full address throughout an investigation. Read the current Record, then inspect the relevant time window. Use entities.query to find a Record when its identifier is unknown. Resolve an access refusal with the Workspace administrator. If the value came from an import, inspect Runs and lineage to find its originating Run before correcting the data.
Records and history also need a coverage check. Repeating a read cannot fill an unknown interval. Keep that gap visible when comparing past values. A returned version does not prove that every earlier change was captured.
Related
- Lists and membership explains how operators retain a selection of addressed Records for work.
- Import and target records joins a Record's origin with a durable List target.
- API gives builders HTTP setup for current Record reads.