# Identity, ordering, and revisions

Read the exact result version an AgentCore application recorded. Corrections preserve prior revisions; a retained reference never silently resolves to the newest value.

Status: Implemented in source. Prelaunch; not a live service guarantee.

Reviewed: 2026-10-14.
Backend source: e16b81b4a637acec91f3aed8a71cf5b0f42f0c19.
Native toolkit: merged in PR #176, reviewed at e16b81b4a637acec91f3aed8a71cf5b0f42f0c19.
HTML: /docs/history

## In short

An AgentCore task can refer back to the result version your application recorded. Stable identity and numbered revisions keep corrections inspectable. An exact lookup returns the named retained revision or an explicit non-found result, without substituting the newest value.

**Available today:** Exact History is implemented in source and exercised by the private SDK. A stored result does not prove a tool completed or a model used it.

> Inspect the exact version your AgentCore application recorded, within retention and access limits.

## Pin what the application recorded

- **Name the result** — Use the stable identity and revision from the AgentCore workload.
- **Keep membership fixed** — Preserve generation and cursor while paging.
- **Read the retained version** — Missing or expired evidence stays explicit; execution is not replayed.

## A correction is a new revision, not a new event

Identity is tenant + subject + type + ID. An exact retry returns the original receipt. A changed payload at the same revision conflicts. A correction uses the next revision and cannot change ID, scope, or occurrence time.

Idempotency is bounded by retained evidence. Do not recycle IDs after expiry. Deduplicating an outcome record does not prevent an external operation from executing twice.

## Three clocks, three meanings

1. **Occurrence time** — Places the event in a UTC day. Daily membership sorts by occurrence time, then ASCII ID.

2. **Acceptance sequence** — Orders applied revisions inside one tenant/subject/type scope.

3. **Publication time** — Marks when a fixed view became available. It is not the event’s business time.

## Pin the collection while browsing

A daily generation names a fixed manifest of bounded reference pages. Reuse its generation with the next cursor so a late arrival does not change the collection mid-read. Daily generations and trajectory generations are different references, not interchangeable identifiers.

[See record → retry → correction](/?capability=workflows&frame=corrected#trajectory)

## Inspect what was recorded, without replaying it

inspectHistory uses one exact byIds read and keeps requested-reference order. Each entry preserves its hydration disposition; an incomplete read is shown as partial.

The client can explicitly report local, remote or unknown acceptance location. That adapter setting is not delivery proof. Model consumption and tool effects remain not_observed; inspection executes no model, tool or re-evaluation.

The separate default-off inspectResult source API requires an exact Outcome revision, invocation ID/version and admitted attestation. It reads existing History and Context evidence without inventing an association. The durable local host does not support it.

## Read exact revisions without inference

A daily read returns at most 32 references. byIds() restores requested order and reports missing, expired, or unresolved keys explicitly. A failed or unprocessed lookup is not replaced with the latest revision.

Source pointers and hashes do not certify an outside business claim. Availability alone proves neither consumption nor correct reasoning; retain the generation actually supplied to an agent to record that application input.