# Prove one outcome all the way to an exact read

The Golden Journey turns protected external check evidence into a narrow outcome and a bounded, inspectable History read.

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

Reviewed: 2026-10-06.
Backend source: 16f1e66d303a43e245a5cff5c392e9ebd3adf201.
Native toolkit review candidate: fe3df1c237b48d04347b6f159cc49e2f0d830a2c (unmerged).
HTML: /docs/golden-journey

> Use the public SDK boundary—not private database edits—to demonstrate the product.

## One small journey, separate evidence stages

1. **Map a protected external result** — Use an approved terminal check result and stable business identity. Unknown or pending is not automatically failure.

2. **Accept and retry exactly** — Keep the original payload and revision identity. Compare the returned acceptance behavior without creating another logical outcome.

3. **Enumerate a pinned day** — Preserve the generation across bounded allIds pages. A short page with a cursor is not completion.

4. **Hydrate named revisions** — Use byIds and inspect each records[] status. Check the exact event rather than assuming any successful JSON is a match.

5. **Keep the right receipt** — The harness result explains the stages it actually performed. It is not proof of live Memory delivery or model-input consumption.

## Do not confuse three different demonstrations

The website example is synthetic browser data and does not call the backend. The native toolkit candidate supplies synthetic storage observations to the actual Rust engine. An authorized SDK/service Golden Journey crosses the real HTTP boundary.

Local source/package tests and these demonstrations do not substitute for separately authorized deployed buyer, IAM, recovery, or AgentCore qualification.

[Open the synthetic History example](/explore)

[Read the scoped SDK example](/docs/integrate)

[Explore the native candidate](/developers)