# Kam State documentation

Kam State is an add-on for Amazon Bedrock AgentCore, planned for AWS Marketplace.

AgentCore hosts your agents and tools. Your application decides; Kam keeps recorded State and exact versions.

Pinned source review, not live service health or deployment evidence.

Website documentation only. No cloud calls, local commands, or model inference are executed by this document.

## Current public status

Prelaunch · Private SDK evaluation · Hosted service not yet available.
Current source review: 2026-10-14; private SDK 0.40.0.
- [Explore real NFL results](https://kam-ai.com/demo): Dated public NFL snapshot. Dated public NFL captures from October 26, 2026. Not a live feed.
- Synthetic State inspection: Public example; Synthetic browser example. Reviewed 2026-10-15, Website example. Synthetic records and authored explanations. No engine, AWS, agent, or model execution.
- Exact History: Evaluation access only; Locally qualified. Reviewed 2026-10-14, Private SDK 0.40.0. Source and offline artifact evidence. Evaluation requires a supplied SDK artifact and authorized endpoint; retained versions and supported writes only.
- Recorded-input inspection: Evaluation access only; Source-implemented. Reviewed 2026-10-14, Private SDK 0.40.0. Inspect exact references recorded by the application. This does not infer an agent’s reasons or prove model consumption.
- Read permissions: Evaluation access only; Locally qualified. Reviewed 2026-10-14, Private SDK 0.40.0. Source and offline checks do not establish deployed isolation or a compliance certification.
- Accepted-work recovery: Evaluation access only; Source-implemented. Reviewed 2026-10-14, Backend e16b81b4. Recover Kam’s accepted work. Agent-task recovery and uncertain external effects remain the application’s responsibility.
- Declared dependent Views: Evaluation access only; Source-implemented. Reviewed 2026-10-14, Backend e16b81b4. Bounded same-scope dependency reconciliation. General calculation caching, cross-scope joins, and managed workflow recovery are planned.
- Conversational inspection: Unavailable; No qualified public release. Reviewed 2026-10-14, No qualified public conversational interface. Local development does not establish a public model-backed service.
- Managed Context preparation: Unavailable; Planned · not available. Reviewed 2026-10-14, Product direction. Exact Context APIs exist in source. Automatic ranking, runtime interception, and managed AgentCore wiring remain planned.

## Qualification, security, and measurement

- Source implemented: Recorded. Reviewed History, State, and exact Context contracts. Source tests establish implemented behavior; they do not establish deployed controls.
- Locally qualified: Selected artifacts. Offline service, private SDK, and Linux x64 native artifact receipts. Simulated AWS and local fixtures. Capability-specific source/local levels remain separate.
- Cloud-qualified: Not established. Requires a passing qualification receipt from an isolated AWS deployment, tied to the exact release. Passing live qualification receipts recorded for this release combination: 0. Provisioning attempts do not qualify it.
- Production commitment: Not offered. Requires cloud qualification and explicit authorization for a defined operating scope. No public hosted offer, production SLA, or production authorization is established by this review.

The service authorizes each scoped read; stale authority grants no access. Missing required evidence blocks current State or complete Context. These are source and offline test boundaries. Deployed IAM, revocation, tenant isolation, erasure, and restore journeys still require cloud qualification.
History reads and State queries have fixed work bounds. No measured cloud p99 is published for this release. Source and local evidence do not establish cloud qualification or a production commitment.

## Archived qualification

[Archived SDK 0.36 qualification](https://kam-ai.com/updates#state-queries). The October 7 receipts keep their original commits and package identities. They do not qualify the current release.

# Inspect recorded NFL results

Browse five real NFL game results with sportsbook-specific closing spreads and captured public source evidence.

Status: Implemented in source. Prelaunch; not a live service guarantee.
A dated snapshot of five successful public API captures from October 26, 2026. It is not a live feed, complete NFL week, Kam State acceptance receipt or authenticated History read.

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

## In short

Inspect five captured NFL results and the public-source evidence behind each one. Compare the displayed score, sportsbook-specific closing spread, and recorded against-the-spread result with its retained capture. The workspace does not simulate corrections or run an agent.

**Available today:** A fixed snapshot of five real NFL games with captured public-source evidence. The website does not run the Kam State engine, agents, models, or tools.

> Inspect the NFL source evidence an AgentCore application could read, from a game result to its captured records.

## Inspect a captured game

- **Choose a captured game** — Open one of the five games and its supplied records.
- **Inspect a supplied record** — Read its State, Raw fields, and captured Evidence.
- **Follow recorded references** — Inspect only the references supplied in this capture; no execution order or revision history is inferred.

## One workflow, from game to evidence

Open a captured game, then inspect a supplied score, closing spread, against-the-spread (ATS) result, profile reference, or recap. State shows the recorded value, Raw shows its allowlisted fields, and Evidence identifies the retained capture. No account is required.

[Explore real NFL results](/demo)

## What was captured

Five game-detail requests returned ready public responses between 04:44:38 and 04:44:48 UTC on October 26, 2026. Eight other requests did not return a ready result. The selected games are not complete-week coverage.

Capture time and the source response’s as-of time are separate. Each game names its selected sportsbook; no league-wide or official closing line is implied. The source did not supply a score certification timestamp.

## What this snapshot establishes

Displayed scores, spreads, recorded grades and identities were checked against retained public responses and their capture receipts. The interface does not calculate ATS grades, fabricate earlier revisions or simulate a correction.

Records are grouped by type, not execution order. Only supplied references are linked. Stage statuses do not establish a complete dependency graph; profile identities do not include rolling statistics, and the closing record does not include a full certificate body.

This example shows the source records an AgentCore application could inspect. The application owns calculations, decisions and explicit Kam calls; AgentCore hosts agents and tools. These public captures do not independently establish Kam State admission, live customer serving or a Rust runtime cutover.

## Share a selected record

Copy link preserves the selected game, supplied record, and inspection panel. Browser Back, Forward, and reload restore those selections. Search text, credentials, and unrelated URL parameters are excluded. An unavailable game or record stays unavailable. Old fictional-workflow links display a retirement notice and invite an explicit new selection.

## Use a keyboard or phone

Game choices, search and inspection tabs use ordinary controls. The same result and source evidence stay in one workspace. There is no autoplay, and optional hover transitions respect reduced motion. The homepage links directly to captured games.

# Normalized objects and versioned collections

The proposed collection architecture for AgentCore workloads: exact identities, ordered membership and bounded Views, with the existing History contract kept intact.

Status: Planned · not available. Prelaunch; not a live service guarantee.
Architecture direction, not a public generalized collection SDK. Existing allIds()/byIds() remain UTC-day History operations; the unpublished State Selection candidate is restricted to one Active State evidence-reference collection. No managed/customer-owned S3 snapshot service is qualified.

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

## In short

Plan how an AgentCore workload could share exact objects through scoped, versioned collections. The proposed generalization builds on History's identities and pinned membership. It does not turn today's History methods into a public general collection API.

**Available today:** General collections remain proposed. allIds() and byIds() keep their UTC-day History contract; scoped State and Components have their own bounded source APIs.

> Plan shared State for AgentCore tasks using exact identities and fixed, versioned collections. General collections remain proposed.

## Existing contract and proposed direction

- **Start with History** — Use exact revisions and fixed UTC-day membership for an AgentCore workload.
- **Add scoped State** — State and Components use declared, bounded evidence references.
- **Keep the proposal separate** — General collection adapters and managed integration remain future work.

## One Rust State engine; many typed collections

The foundational distinction is identity versus membership. Exact identity answers which retained object revision is requested. Collection membership answers which exact references belong to a particular ordered, pinned generation. A consumer can enumerate references and hydrate only selected records.

The existing History adapter scopes records by tenant, subject, and type, and pins UTC-day collection membership to a generation. This date-based History contract does not require every proposed collection to be date-based. General collection adapters, including project builds, documents, and tasks, are architectural direction only.

Knowledge is information represented as typed State, with provenance and review status where applicable. Context is a consumer-specific View selecting authorized references. Neither needs a second State engine.

1. **Exact object** — Stable identity plus exact revision and declared availability. A stored build record is not proof that the artifact is safe to reuse.

2. **Versioned membership** — An ordered collection of exact references with a pinned generation. Membership can change without duplicating objects.

3. **Materialized View** — A derived result with exact source/definition references, applicability, and its own publication boundary.

4. **Consumer Context View** — A task-scoped selection of eligible State/evidence references; permission is rechecked when serving.

## What the current History API actually guarantees

allIds() pages one bounded UTC-day generation. Generation-bound byIds() verifies exact membership; direct byIds() resolves known exact revisions without a membership claim. Missing, unresolved and expired evidence stays explicit; neither API silently follows the latest revision.

The existing Rust State engine already supports versioned Views, dependency membership, change detection and bounded reconciliation. The generalized collection contract described here must reuse those mechanisms rather than create parallel reducers or dirty-propagation loops.

[Existing History API and exact references](/docs/history)

[State queries and supported operators](/docs/state-api)

[Engineering contract](/docs/engineering-review)

## Adapter boundaries, not a different engine per vertical

1. **History adapter — implemented scope** — UTC-day ordered outcomes, specific revisions, retention and correction rules.

2. **Project collection — proposed** — Enumerate exact build, test, and task references by project instead of date; no build-specific inference or compiler required.

3. **Temporal collection — proposed** — Use explicit time and versioned rules as View inputs, so durable source facts may drive new bounded projections without being rewritten each year.

4. **Context collection — proposed** — Select exact evidence references for one consumer and budget; representation is separate from the original payload.

> **Dependency injection boundary**
> Adapters supply scoped access, membership policies, storage ports, and lifecycle configuration. Rust remains the semantic authority for supported deterministic validation and publication.

## Keep the existing dependency DAG

A changed source makes its affected dependent Views dirty. The existing reconciliation lifecycle evaluates bounded affected work and conditionally publishes. Within one traversal, a visited set avoids duplicate work. For supported Views, unchanged results can be reused when the required version, freshness, and authority checks still hold. General calculation caching remains planned.

A future nested collection may reference exact child generations, but the parent must pin each child version; old parents must not silently retrieve newer children. Traversal requires total depth, node, edge, byte, and read limits. A trie or Merkle DAG is an optional measured indexing optimization, not a prerequisite.

## Hot State and durable snapshots have different jobs

The target storage architecture uses DynamoDB for operational pointers, indexed membership and durable work. Immutable evidence and snapshots may live in an approved S3 store. Kam-managed and customer-owned S3 are proposed storage-ownership modes, not existing product offerings.

Retention, snapshot interval, application validity and hot working-set policy are distinct. Customers might select multi-year retention while only occasionally changing State. The current 365-UTC-date working History window is a real existing contract; generalizing future lifecycles must preserve it until separately migrated and qualified.

Snapshot publication must verify the exact durable object before advancing a conditional hot-State pointer. DynamoDB and S3 do not share a transaction. An absent or inaccessible archived object must not silently resolve to latest.

[Existing retention guarantees](/docs/retention)

[Qualification status](/reliability)

## Illustrative: three agents share one build record

Agent A submits a build result under a stable application-supplied ID. Agents B and C can retrieve the same authorized record or see it in different project collections without copying its payload. A new build gets a distinct exact identity or revision according to the declared producer contract.

Reusing the compiled artifact still depends on an external build cache and its compatibility checks. Kam does not compile Rust, certify arbitrary toolchains, infer build equivalence, or grant access because an agent knows an ID.

## Implementation boundary and next experiment

This document describes the intended generalization of existing primitives, not a shipped universal byIds/allIds service. Start by preserving the existing History adapter and qualifying one non-date, bounded collection through the real Rust engine, authorized reads, conditional publication, and recovery.

Only after that source-backed happy path should the website describe generic collections, customer-owned S3, generalized durable Context collections or managed multiagent artifact reuse as available.

# Kam State documentation

Use Kam State alongside Amazon Bedrock AgentCore. Start with one recorded result, read its exact version, and learn which source capabilities and integration steps still need qualification.

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

## In short

Kam State is a State Management add-on for Amazon Bedrock AgentCore. Your application records results and selects exact retained evidence; AgentCore hosts agents and tools. Systems of record remain authoritative for their own business data, and Memory recall stays separate.

**Available today:** Private SDK 0.40.0 includes exact History, Views, current State, bounded queries and Context manifests. Local receipts do not establish a hosted or live-qualified AgentCore integration.

> Reduce custom state-management work around your AgentCore application with exact State and History.

## What Kam does today

Your app sends results to Kam. Kam keeps numbered versions and corrections, returns the exact retained version requested, and reports when it cannot. Kam uses declared dependencies to identify and reconcile affected Views. General metric APIs, materialize and watch remain planned.

Amazon Bedrock AgentCore hosts your agents and tools. Your application decides when to call them and what their results mean. Kam preserves the State and exact versions your application records; AgentCore Memory provides separate recall.

1. **Identity · Implemented in source** — Stable logical identity for every entity, so a correction updates the same thing instead of creating a duplicate.

2. **Versions · Implemented in source** — Immutable revisions. A newer revision never rewrites what an older read returned.

3. **Membership · Implemented in source** — A fixed, ordered list of the exact revisions that belong to one collection at one point in time.

4. **History · Implemented in source** — The retained record of accepted revisions, corrections, and published generations.

5. **Dependencies · Implemented in source** — Versioned records of which Views read which sources, so a change can find exactly what it affects.

6. **Views · Implemented in source** — Bounded, owner-configured definitions over source State, normalized and hash-bound by Rust.

7. **Materialization · Implemented in source** — Conditionally committed Active State for bounded same-scope Views with one or more sources. Source implementation, not a public hosted service.

8. **Queries · Implemented in source** — Bounded where, pick, orderBy and take over one Active State's evidence, with explain() before value().

9. **Replay · Implemented in source** — Re-run synthetic scenarios against the real Rust engine and explain why State changed or was reused.

10. **Metrics · Planned · not available** — General derived metrics that recompute when an input changes. Today only rolling outcome comparisons are implemented.

11. **Watch · Planned · not available** — Customer subscriptions that fire when a materialized view changes.

## Three questions Kam answers today

1. **What exact evidence existed?** — History preserves accepted revisions and fixed membership under stable identity.

2. **What changed, and which Views need reconciliation?** — Versioned Views and State reconciliation separate affected dependencies from retained immutable evidence.

3. **What should this reasoning turn see?** — Your app selects exact captured evidence in a versioned Context manifest. Bounded assembly exists in source; the native toolkit also prepares local reference-only Turn Frames. Managed runtime wiring remains planned.

> **Current release boundary**
> Marketplace availability, production p99, and production AgentCore write-back remain qualification gates. The delivery loop is implemented, disabled by default, and tested through simulated transport. This is not live production qualification.

[Follow the History example](/?capability=workflows#trajectory)

[Read the State API design](/docs/state-api)

## Choose the right entry point

Start with private SDK 0.40.0. Exact History, Views, current-State reads, bounded queries and versioned Context manifests are implemented in source. The reviewed package receipts qualify local or simulated execution; they do not establish a publicly offered hosted service, live production use or a Marketplace listing.

[Normalized State and collection architecture](/docs/normalized-state)

[State queries and the design preview](/docs/state-api)

[State and required evidence](/docs/state)

[Native toolkit](/docs/toolkit)

[What changed](/updates)

## A rolling view, not permanent recall

The working history covers 365 UTC dates. Supporting evidence has its own inspection limits. A recovery checkpoint is saved processing state, not a lifetime summary.

[Read the retention contract](/docs/retention)

# State queries, Components, and what comes next

Select bounded State evidence for an AgentCore application with the private SDK. Components and queries are implemented; general metrics, materialize and watch remain planned.

Status: Implemented in source. Prelaunch; not a live service guarantee.
Private SDK 0.40.0 implements scoped State, Components, bounded evidence-reference queries, composition, and exact Context APIs (OpenAPI 1.31.0). Its clean offline artifact round trip passed on reviewed main. The SDK is not published to npm or qualified for customer production. Queries operate on admitted evidence references; general source-payload queries, managed metrics, materialize(), watch(), and managed lifecycle integration remain planned capabilities.

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

## In short

Give an AgentCore task a bounded selection of current State evidence. Bind one scope, name a View as a Component, and inspect the query plan before running it. The result supplies evidence; your application still decides whether to invoke a model or tool.

**Available today:** Queries, Components and bounded selection operators are in private SDK 0.40.0. General materialize, watch and metrics remain planned; managed runtime wiring is separate.

> Give an AgentCore task bounded evidence; keep the decision in your application.

## Read evidence before starting work

- **Choose one task question** — Bind the State scope your AgentCore application may read.
- **Inspect the admitted plan** — Check limits before value(); only a current result carries items.
- **Keep execution outside the query** — Your application decides when to invoke the agent or tool.

## Implemented in private SDK 0.40.0

state({ subjectId, type }) binds one scope; component() names a maintained View. Declarations perform no I/O. A query selects from the admitted evidence references of that View’s current Active State, not from arbitrary source payloads.

Rust admits the plan before anything runs: tenant-bound, at most 16 stages, 32 pick paths, take ≤ 32 as the terminal stage, at most 36 storage reads, and never a table scan. value() re-reads and re-checks current State, and only a current result carries items.

### Bounded State query — SDK 0.40.0 typings

```javascript
// Private SDK 0.40.0 · implemented in source · not on npm or production-qualified
const deployment = kam.state({ subjectId: 'checkout', type: 'deployment' });
const history = deployment.component('trajectory-current');

const required = history.query()
  .where('required', 'eq', true)
  .orderBy('key', 'asc')
  .pick(['key', 'revision', 'source.id'])
  .take(5);

// Inspect the plan before it runs.
const plan = await required.explain();

// Execute over the admitted Active State's evidence references.
const result = await required.value();
if (result.status === 'current') console.log(result.items);
// absent, blocked and stale results carry no usable items.
```

## Bounded operators introduced in SDK 0.37.0

SDK 0.40.0 retains the thirteen stages introduced in 0.37.0: chunk, flattenDepth, differenceBy, intersectionBy, indexUnique, distinctExact, diffRevisions, partition, groupBy, countBy, sumIntBy, allMatch, anyMatch. They operate on declared bounded evidence-reference collections, not arbitrary customer payloads. diffRevisions compares two explicit collections; its completeness describes those inputs, not outside source coverage.

Merged in PR #220, not published to npm. Introduced in SDK 0.37.0; included in the reviewed private SDK 0.40.0. These operators run only over one verified Active State's selected evidence-reference collection. They do not query arbitrary customer payloads, establish external completeness, provide a managed metrics service, or add automatic AgentCore lifecycle integration.

## What explain() returns

These are the fixed fields of the plan type in the SDK typings, not a captured response or a latency measurement. explain() reports the bound; it does not perform the reads.

### StateQueryPlan fields (SDK 0.40.0 typings)

```text
explain() → kam.state-query-plan.v1     (fields from the SDK 0.40.0 typings)
  storageAccess        tenant_bound_verified_active_state_read
  maxStorageReads      36
  tableScan            false
  crossTenant          false
  limits               16 stages · 32 pick paths · take ≤ 32
  executionAvailable   true
```

## Design preview: collections, materialized views, and watch

The direction beyond today’s SDK: chain operators over named source collections, keep the result materialized, and recompute it only when an input it reads changes.

Naming in the preview follows one concept: source collections are plural nouns (customers, subscriptions); derived views and metrics are camelCase descriptions of what they hold (atRiskCustomers, businessHealth).

### Design preview — collection sources, materialize and watch are not available

```javascript
// DESIGN PREVIEW · collection sources, materialize and watch are not available in any SDK
const atRiskCustomers = kam
  .state('customers')
  .where(lt('health', 0.6))
  .pick(['id', 'mrr', 'health', 'renewalDate'])
  .orderBy('mrr', 'desc')
  .take(100)
  .materialize('atRiskCustomers');

// Run your agent only when this view changes.
atRiskCustomers.watch(change => startCustomerSuccessAgent(change));

// Ask how Kam will execute it before it runs.
atRiskCustomers.explain();
```

## A small set of composable operators

1. **Select: where, pick, orderBy, take** — Filter, project, and bound one Active State's evidence. In private SDK 0.40.0.

2. **Plan & run: explain, value** — See the bounded plan, then execute it. In private SDK 0.40.0.

3. **Combine: group, union, diff, expand, hydrate** — Relate collections and resolve references to exact revisions. Planned.

4. **Aggregate: count, sum, mean, reduce** — Derive metrics that update incrementally as inputs change. Planned.

5. **Operate: materialize, watch** — Keep a result current and react when it changes. Planned.

## Planned metrics would recompute when their inputs change

This synthetic example illustrates the planned metrics model. One subscription is upgraded. The dependency graph identifies mrr, arr, businessHealth for recomputation. churnRate, dailyActiveUsers, p99Latency, supportSla read other inputs, so the design would reuse their existing values.

In this planned design, a businessHealth change would notify its subscriber. Your application would decide whether to run the executive agent; the other 4 metrics would not notify their subscribers while their inputs remain unchanged.

Synthetic example of the planned metrics model. Counts are derived nodes in this diagram (3 of 7 recomputed, found by graph reachability from the changed input), not a measured benchmark.

## Planned subscriptions would notify your application when a View changes

watch() is the planned way to start work: subscribe to a materialized view and receive the change, including the exact revisions that caused it. Your code decides what to do, such as invoking an AgentCore agent. For supported changes, this could reduce repeated polling and unnecessary agent starts. Your application would still need appropriate recovery and monitoring; the savings would depend on the workload.

Customer realtime subscriptions are not implemented. The current internal event path is bounded and maintenance-redrivable, and it is not a public subscription API.

## Authorization, work limits, and deadlines are separate controls

Today’s State queries already carry fixed work bounds. The planned general work envelope (maxReads, maxItems, maxBytes, maxDepth, maxFanout, maxRetries, deadline) extends those consumption limits to joins, aggregates and metrics.

Authorization independently restricts which data and operations the principal may access. A small unauthorized read is still unauthorized. Deadlines and retry policy determine how long the caller waits and what happens when bounded work does not finish.

The planner bounds the operation’s work. It does not establish a latency guarantee; measured latency and convergence require a declared workload.

1. **Cross-tenant access · Implemented in source** — The server resolves the authorized tenant; a caller-supplied tenant ID is not authorization.

2. **Silent mutation · Implemented in source** — Revisions are immutable. Corrections add a revision and keep the earlier one inspectable.

3. **Model output becoming truth · Implemented in source** — Only your application declares results. No model, reducer, or AgentCore call fills a missing record.

4. **Oversized reads · Implemented in source** — History pages and View membership sets have explicit limits and cursors.

5. **Unbounded traversal · Implemented in source** — View dependency membership is bounded and cycles are rejected at registration.

6. **Stale or duplicate work · Implemented in source** — Commit-time fences reject work whose lifecycle, membership, or source version has moved.

7. **Unbounded State queries · Implemented in source** — Rust admits a query plan before execution: tenant-bound, at most 16 stages, 32 pick paths, take ≤ 32 and 36 storage reads, and never a table scan.

8. **General query work limits · Planned · not available** — A general declared envelope (maxReads, maxItems, maxBytes, maxDepth, maxFanout, deadline) for joins, aggregates and metrics, checked before execution.

9. **Acting on stale State · Planned · not available** — Revalidate the exact State a decision read before a consequential external action.

## A specialized database, not a replacement

Kam is a specialized, DynamoDB-backed State database for applications built on Amazon Bedrock AgentCore. Your databases stay authoritative for their business records. Kam is authoritative for the State it accepts: its revision identities, membership, and publication history.

Store the State worth reusing, not every byte worth keeping.

Not offered, by design: general SQL, arbitrary joins, or transactions across your other data sources.

## Where to start

Evaluate the History contract and one bounded View with the SDK candidate against an authorized endpoint. Metrics, materialize and watch are shaped by those evaluations.

[Integrate one structured workload](/docs/integrate)

[Read the State contract](/docs/state)

# Integrate one structured workload

Add recorded State to an AgentCore application while your runtime keeps model calls, tools and business decisions. Use the existing SDK candidate against an authorized endpoint.

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/integrate

## In short

Keep your AgentCore runtime and record one declared result in Kam: what happened, to which record, and when. Retry the same identity, record a correction, then read both retained versions. Your application supplies the business meaning and controls external actions.

**Available today:** A private SDK candidate supports the documented operations against an authorized evaluation endpoint. No public npm release or automatic AgentCore attachment.

> Record one AgentCore workload result, then read both sides of a correction.

## Record one workload result

- **Authorize the State connection** — Use an approved evaluation endpoint and an authorized application identity.
- **Record the declared result** — Your AgentCore application supplies stable identity and result meaning.
- **Read the correction exactly** — Request both retained revisions; do not rerun the original tool to inspect them.

## Send identity, time, and a declared result

Supply ID, subject, type, occurrence time, status, category, and optional source references. Revision defaults to 1. The server resolves the authorized tenant; a supplied tenant ID is not authorization by itself.

Only success and failure are accepted. Do not convert pending, cancelled, or unknown results into failure just to fit the API. Occurrence time must be canonical UTC, not in the future, and within the working window.

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

[See the retry assertion and correction](/developers#integration)

## Choose the operation that matches your task

1. **outcome()** — Record a result, retry the exact same payload, or supply the next correction revision.

2. **allIds() → byIds()** — Browse a pinned UTC-day collection, then retrieve its exact revision references. Keep generation and cursor together.

3. **trajectory()** — Read precomputed last-ten and 30/90-day comparisons, with freshness and pending-work information.

4. **history() / why()** — Inspect accepted-revision history or a deterministic explanation of calculated values. why() is not causal investigation.

5. **deliveryStatus()** — Read metadata-only delivery counts, coverage, and oldest unfinished work. It does not return memory content.

> **Evaluation prerequisites**
> The SDK is supplied as a reviewed private artifact or through an authorized source checkout; it is not published to npm. An authorized service endpoint, principal, and tenant binding are required. No endpoint or credential is embedded in these pages.

## Bind a scope once; preserve the returned references

SDK 0.40.0 provides state({ subjectId, type }) (scope() is the same adapter) as a thin layer over the same API. It cannot override its bound subject or type and does not create a second state engine. Use the exact approved package or authorized source checkout; there is no public npm release.

### Read one bounded page using the existing SDK candidate

```javascript
// Save as a .mjs file in an authorized backend source checkout. SDK candidate 0.40.0.
// This is a read-only example, not code executed by the website.
import { createKamClient } from './server/trajectory/sdk/index.mjs';
const kam = createKamClient({
  baseUrl: process.env.KAM_API_URL,
  tenantId: process.env.KAM_TENANT_ID,
  accessToken: () => process.env.KAM_ACCESS_TOKEN,
});
const deployments = kam.scope({ subjectId: 'checkout', type: 'deployment' });
const page = await deployments.allIds({ day: '2026-10-06', limit: 16 });
if (page.status === 'ready' && page.items.length > 0) {
  const exact = await deployments.byIds({
    day: page.day,
    generation: page.generation,
    refs: page.items,
  });
  console.log(exact.records); // Keep every position and result status.
}
// A short page is not the end when nextCursor is present.
// Continue with the SAME generation and returned cursor.
```

## Keep AgentCore execution in your application

createKamApp, conversation and invocation create immutable scoped handles without I/O. Use them for the State layer of an AgentCore application. Your runtime and application create, invoke and dispose models, tools and Memory connections; Kam does not take over that lifecycle.

Component configuration is a bounded sequence of individually idempotent steps, not one atomic transaction. An acknowledged configuration does not prove that derived State has converged.

## Authorize the destination separately

A subscription does not grant access to a customer AWS account. Server-owned bindings select the approved Region, memory, strategy, and namespace. Background jobs do not retain a browser JWT.

# 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 explicitly reports that it cannot, 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 retrieval status; 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.

# How the event-driven paths fit together

Follow the separate acceptance, calculation, exact-read and optional Memory-delivery paths beside AgentCore execution.

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/event-driven-memory

## In short

AgentCore runs the agent while Kam accepts recorded results, updates derived State and serves exact History. Optional delivery to Memory is another path with its own evidence. Processing progress and delivery receipts must be inspected separately from execution.

**Available today:** These State and History paths are implemented in source. AgentCore Memory delivery is optional, off by default and locally simulated.

> Separate AgentCore execution, State processing and optional Memory delivery.

## Follow each owner across the handoff

- **Execute in AgentCore** — The runtime hosts the agent; your application controls decisions and tools.
- **Maintain State in Kam** — Accept results, reconcile supported Views and serve exact evidence.
- **Deliver only when configured** — Optional Memory delivery has its own receipts and is off by default.

## DynamoDB stores Kam's accepted History

Acceptance commits immutable revisions, day membership, and durable work together. A separate publication transaction commits the checkpoint, trajectory generation, and eligible delivery obligation. These are two transactions at different stages, not a transaction across AWS services.

[Read the write path](/docs/engineering-review#write-path)

## Rust computes supported rolling views

The worker takes saved state, accepted transitions, and an explicit time input. It performs no AWS or model I/O. last10 compares two disjoint groups of ten; utc30 and utc90 compare disjoint calendar windows and include today’s partial UTC day.

Rates use summed success and failure counts. An empty denominator is null. Deltas are percentage points. These are descriptive comparisons, not significance tests or evidence of causation.

[Inspect a chart and its source records](/?capability=workflows#trajectory)

## Queues wake workers; durable records preserve unfinished work

Bounded queue jobs and the scheduled maintenance sweep resume pending work and advance quiet histories. A delivery generation is not forgotten when enqueue fails; its durable obligation can be rediscovered after the scheduling lease.

The delivery scheduler rotates across registered scopes. Automatic recovery has explicit attempt limits and stop states; it does not imply automatic repair of every failure.

## Keep archive proposals separate

Accepted History is in DynamoDB. A source reference is not an archived copy or an atomic acceptance receipt. Automatic S3 archival and carry-forward consolidation are not implemented.

# From accepted outcome to verified retrieval

Inspect optional delivery to AgentCore Memory: acceptance, submission and verified retrieval have separate receipts and do not prove model consumption.

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/publication

## In short

Optional delivery can send an eligible Kam result to a configured AgentCore Memory destination and verify retrieval. Acceptance, submission and retrieval are separate facts. A delivery receipt does not establish that an agent recalled the record or used it in a model request.

**Available today:** Delivery is implemented and off by default, with simulated AWS transport tests. Live destination access, retrieval and consumption need separate evidence.

> Inspect AgentCore Memory delivery separately from accepted State and model use.

## Inspect the Memory delivery boundary

- **Start with accepted State** — Acceptance alone does not establish destination delivery.
- **Check submission and retrieval** — Keep the configured Memory request and verification receipts distinct.
- **Leave consumption unclaimed** — Retrieval does not prove recall or model use; live qualification is separate.

## Select an authorized destination and starting point

A prospective delivery policy names the scope, lifecycle epoch, destination binding/version, and first eligible checkpoint version. Older generations are not implicitly backfilled. Under policy v1 every eligible generation keeps its own obligation. Under policy v2 a newer generation may replace only a candidate that was never planned, dispatched or submitted; the replaced obligation is kept as SUPERSEDED with the replacing generation. Submitted or uncertain work is never coalesced.

## Read the progression and stop states

1. **AWAITING_PUBLICATION** — Durable work exists for one eligible generation. The worker plans the authorized request and records publication attempts.

2. **AWAITING_VERIFICATION** — The write has been acknowledged. A separate exact read still needs to match the expected content and lineage.

3. **VERIFIED** — The exact record matched through the approved namespace at verification time. This is not proof of semantic-search ranking or agent consumption.

4. **Explicit stops** — REJECTED, AUTHORITY_BLOCKED, and RECONCILIATION_REQUIRED remain visible. The orchestrator does not repair mismatched remote content.

5. **SUPERSEDED (policy v2)** — A never-submitted candidate replaced by a newer generation. Counted separately from unresolved work; it is neither a failure nor a delivery.

> **Current release boundary**
> Marketplace availability, production p99, and production AgentCore write-back remain qualification gates. The delivery loop is implemented, disabled by default, and tested through simulated transport. This is not live production qualification.

[See the delivery-state diagram](/architecture#delivery)

## Separate local correction from remote cleanup

Local revisions and new generations are implemented. Remote supersession, deletion, and operator reconciliation require separate work. A failed verification read does not become another create. Do not infer that publishing a newer memory automatically removes all older destination records.

## Count like with like

deliveryStatus() reports accepted/applied outcome revisions separately from local-generation delivery counts. Do not subtract verified generations from accepted revisions or chart them as one funnel.

The status read covers at most 32 scopes and 100 obligations per scope. Check coverage.complete before treating counts as complete. Counts of due or leased work overlap workflow stages; they are not extra stages to add to a total. Oldest-work reporting includes non-verified stop states.

# Retention, rolling history, and checkpoints

Plan evidence availability for AgentCore workloads. Kam History, retained inspection evidence and AgentCore Memory use separate clocks and controls.

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/retention

## In short

Choose which evidence your AgentCore application must be able to inspect later. Kam's rolling History window and retained evidence have their own limits; Memory has separate retention settings. A processing checkpoint is not a permanent copy of everything the agent has seen.

**Available today:** The rolling window and evidence limits are implemented in source. Automatic archival and lifetime summaries are not; Memory policies are separate.

> Know which State evidence an AgentCore task can still read later.

## Choose the evidence each owner retains

- **Working History** — Plan the bounded UTC-date reads your AgentCore application needs.
- **Retained State evidence** — Inspect only versions still available under retention and authority.
- **Memory recall** — AgentCore Memory policies are separate; automatic Kam archival is not built.

## A rolling window. A maintained state.

Kam advances working state as outcomes arrive and time moves forward. A recovery checkpoint keeps processing continuous; it is not a permanent summary of everything the system has seen.

1. **Rolling operational history** — The working window contains today and the previous 364 UTC dates. It advances each day, not through annual resets.

2. **Checkpointed rolling state** — Processing resumes from the persisted checkpoint and applies accepted transitions. Exact reads use published views rather than rebuilding the full history.

3. **Versioned supporting evidence** — Revisions and references support inspection until their deadlines. Supporting evidence may be retained for up to 730 days, with correction-related extensions.

> **Current reducer boundary**
> Outcomes older than the working window stop contributing to rolling state. The current reducer does not preserve their meaning in a lifetime summary or move them automatically to S3.

[See the working-window visual](/reliability#retention)

## Kam working history

365 UTC dates

Today and the preceding 364 UTC dates. The window advances daily; out-of-window contributions are removed from rolling state, not consolidated into a permanent baseline.

## Kam supporting evidence

Separate inspection limits

Supporting revisions and references may remain for up to 730 days, with direct-prior-revision extensions for corrections. Inspection ends when its evidence expires; this is not automatic cold-tier archival.

## AgentCore raw events

Configurable, up to 365 days

AWS applies this retention to raw short-term events. It is separate from Kam’s window and AgentCore long-term records.

## AgentCore long-term records

Strategy or batch-request policy

AWS supports optional record TTL of at least 31 days and explicit deletion. With no TTL configured, those records do not expire. Raw-event expiry is a separate policy.

## Carry-forward consolidation

Preserve selected historical meaning in a versioned summary baseline while older evidence follows a separate archive policy. This is a proposed extension, not the behavior of the current rolling reducer.

Summary selection, provenance, corrections, archive verification, retrieval, and deletion need their own implementation and qualification. A summary is derived context, not a replacement for exact evidence or a guarantee against context drift.

> **Proposed · not implemented**
> Automatic S3 archival, a persistent summary baseline, and AI-generated institutional knowledge are not implemented in the reviewed backend. No delivery date is committed.

## AWS documentation

The AWS sources below explain raw-event expiry fixed at write time, optional per-strategy long-term-record expiry and explicit deletion. They do not define Kam’s History retention contract.

[AWS: raw-event retention](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory-create-a-memory-store.html)

[AWS: long-term record TTL and lifecycle](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html)

## Expiry does not prove erasure

Reads enforce logical expiry before asynchronous TTL cleanup. Bounded owner export, primary-state deletion, and a restore fence are implemented in source. Live downstream erasure and restore drills remain separate release gates. A missing old reference is not rebuilt on demand or silently replaced with a newer record.

# Accepted work remains accountable

Review how Kam preserves recorded State, authority and unfinished processing when an AgentCore workload is interrupted or delivery is uncertain.

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/reliability

## In short

When an AgentCore workload is interrupted, separate the runtime's next action from Kam's unfinished State processing. Recheck authority and inspect uncertain delivery before retrying. Kam keeps uncertainty visible instead of converting an unknown effect into a successful result.

**Available today:** Source recovery and lifecycle controls exist. Live cancellation, downstream erasure, restore drills and AgentCore integration remain separate qualification gates.

> Recover recorded State alongside AgentCore work while keeping uncertain effects explicit.

## Recover State without guessing effects

- **Inspect unfinished processing** — Separate Kam obligations from AgentCore execution progress.
- **Retain the attempt evidence** — An ambiguous effect stays unknown until the relevant evidence resolves it.
- **Recheck authority** — The application must validate permission before another external action.

## Keep local processing and delivery separate

Lifecycle fencing and bounded draining are implemented candidates. Delivery additionally owns one obligation per eligible generation. Local application does not prove remote submission, and remote submission does not prove retrieval.

> **Current release boundary**
> Marketplace availability, production p99, and production AgentCore write-back remain qualification gates. The delivery loop is implemented, disabled by default, and tested through simulated transport. This is not live production qualification.

## Do not let an old job inherit new authority

An outcome keeps its acceptance epoch. Cancellation closes new acceptance and may authorize a bounded local drain. Renewal advances authority again. Delivery stops new remote attempts when the lifecycle closes or its destination binding changes; an old obligation is not silently rebound.

## Uncertain is not failed, cancelled, or complete

An ambiguous response preserves the request identity and durable receipt. Recovery waits for the relevant lease or scheduled retry boundary. Exhausted publication or verification attempts require reconciliation; they are not counted as success. A failed read does not trigger a new create.

## Implemented exit controls still need live qualification

Bounded owner export, export-bound primary deletion, and a separately retained restore fence are implemented. Marketplace reconciliation is license-scoped. Live purchase, cancellation, downstream erasure, and restore drills remain separate gates. A restored table being available does not establish that it is safe to serve.

[Read the customer lifecycle boundary](/docs/marketplace)

# What has been tested

Check the exact source, package and live evidence before evaluating Kam with AgentCore. Local tests and production authorization prove different things.

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/qualification

## In short

Before connecting an AgentCore workload, check which exact Kam package and capability the evidence covers. Source tests, local package runs, live qualification and production authorization are different stages. A deployed website or working fixture does not advance the backend's status.

**Available today:** Source and locally qualified evidence are recorded. The current release has no matched passed live qualification or production authorization.

> Check the evidence before treating an AgentCore State integration as qualified.

## Qualify the integration in stages

- **Pin the source and package** — Check exactly which Kam capability and artifact was tested.
- **Separate local and live** — A local fixture does not qualify an AgentCore connection.
- **Authorize production separately** — A passed integration check does not grant permission to serve customers.

## Six evidence levels

Every capability is shown at the highest level its recorded evidence still supports. Each level needs the one beneath it, and missing, stale, failed, or mismatched evidence lowers the shown level automatically.

1. **Planned · not available** — Design direction. No implementation is claimed.

2. **Source-implemented** — Implemented in reviewed source with source-level tests. This label does not establish package or live qualification.

3. **Locally qualified** — Exercised as a packaged or local artifact (CI, local lab, or simulated AWS transports). This does not establish live AWS qualification.

4. **Live-qualified** — A passed live qualification receipt binds this exact package to an isolated AWS deployment.

5. **Pilot only** — Live-qualified and authorized for a named, bounded pilot. Not general availability.

6. **Production-authorized** — Live-qualified and explicitly authorized for production use.

## The release combination behind these pages

Reviewed source records isolated AWS qualification attempts, including failures and cleanup. No matched passed live receipt or customer-production authorization was verified for this release combination. The older regional inventory is a historical observation, not evidence of current global absence.

Live qualification receipts recorded: 0. Live receipts are accepted only in the backend schema kam.live-agentcore-qualification-receipt.v6 with status passed, bound to the exact recorded package commit.

1. **Source the website claims were reviewed against: e16b81b4** — main through PR #267. Backend capability claims in this review refer to this checkpoint.

2. **Reviewed source, packaged and qualified in CI: e16b81b4** — main · qualification run 38541006600. Same commit and tree as the reviewed source. Service, SDK and native artifact round trips passed; simulated transports and offline consumers do not establish live qualification.

3. **Historical package candidate selected for live qualification: 284f26e5** — PR #206 candidate · merged as a215d31f · run 37605352449. Preserved from the 2026-10-07 review; this older artifact is not the current main package. No matching passed live receipt is recorded here.

4. **Native developer toolkit: e16b81b4** — merged in PR #176 (d5056454) · native artifact round trip in run 38541006600. Linux x64 only. No public distribution.

5. **History and State SDK candidate: e16b81b4** — SDK 0.40.0 · artifact round trip in run 38541006600. Not published to npm. Exact source commit, package hash and offline clean-consumer receipt are recorded in docs/content-evidence.md.

6. **Website runtime SDK: 96dff834** — vendored SDK 0.46.0 · local producer 1792452589183 attempt 1 · official offline verification 2026-10-19. Independently qualified, unpublished SDK candidate pinned for server reads. Exact archive, release receipt, SBOM and official offline verifier retain the actual local producer identity and source branch in vendor/kam-history-sdk. SDK production is separate from hosted source qualification and live authorization. Older 0.45.0, 0.43.0, 0.40.0 and 0.36.0 records remain historical. Native application builds require separate qualification.

7. **History — Locally qualified** — Package qualification is not a live deployment.

8. **Identity & membership — Locally qualified** — Covered by the same package qualification as History.

9. **Views & current State — Source-implemented** — Reviewed View and reconciliation source; no live-qualified or publicly offered hosted State service is established.

10. **State queries & Components — Source-implemented** — SDK 0.40.0 has a passed offline artifact receipt; the source claim is limited to supported bounded operations, not arbitrary payload queries or live service qualification.

11. **Metrics, materialize & watch — Planned · not available** — Design preview only.

12. **Turn Lifecycle — Locally qualified** — Merged native toolkit; reference-only local frames.

13. **Versioned Context manifests — Source-implemented** — Exact capture, ordered manifests and bounded assembly exist in source. Automatic ranking, managed runtime wiring and live model-consumption proof are not established.

14. **Operational durability — Source-implemented** — History and reconciliation progress are durable in source; no named checkpoint API.

15. **Profiler & developer toolkit — Locally qualified** — Merged; Linux x64 only; no public distribution.

16. **Optional AgentCore delivery — Locally qualified** — Default off; simulated AWS transports only.

17. **Export, deletion & restore fence — Source-implemented** — Live erasure and restore drills are qualification gates.

[See the release combination](/reliability#release)

[Open the fixture inspector](/inspect)

## Current evidence boundary

1. **Ordered, versioned ledger — Source and package tested** — Exact revisions, pinned daily pages, corrections, rolling windows, and independent 400/730-day synthetic-history checks. Synthetic time is not observed uptime.

2. **Rust State and Observations — Source and package tested** — State pointers, immutable Observations, and change evidence are conditionally persisted. The private SDK reads current Active State and retained exact Observations. Offline checks do not establish production qualification.

3. **State reconciliation — Source implemented** — Bounded View registration, acyclic reverse-dependency membership, durable cursor/task progress, and same-scope multi-source reconciliation are implemented. General cross-scope joins remain planned.

4. **State queries — Source implemented** — Private SDK 0.40.0 implements scoped State, Components, bounded evidence-reference queries, composition, and exact Context APIs (OpenAPI 1.31.0). Its clean offline artifact round trip passed on reviewed main. The SDK is not published to npm or qualified for customer production. Queries operate on admitted evidence references; general source-payload queries, managed metrics, materialize(), watch(), and managed lifecycle integration remain planned capabilities.

5. **Turn Frames and profiler — Merged · locally qualified** — The Linux x64 native toolkit qualifies reference-only local Turn Frames. Exact Context capture, manifest assembly, and a controlled request-boundary adapter also exist in source. Automatic runtime interception and managed AgentCore wiring remain planned. Model submission, completion, and business acceptance are not observed unless an injected boundary explicitly reports them.

6. **Exact Context and request boundaries — Source implemented · live unqualified** — Capture exact evidence, assemble ordered manifest references, and record hide/restore changes. A controlled injected adapter can report request stages. Automatic interception, provider-wide budgeting, and managed action barriers remain planned.

7. **Native developer toolkit — Merged · locally qualified** — Native toolkit 0.1.0 is merged into the backend (PR #176) and qualified in CI as a network-disabled Linux x64 artifact. No public binary release, macOS/Windows distribution, or live AWS connection is offered here.

8. **Customer lifecycle — Source implemented · live unqualified** — Bounded owner export, primary-state deletion, restore fences, and Marketplace entitlement reconciliation are implemented in source. Live buyer, erasure, restore, and revocation journeys remain qualification gates; no deployed completeness is claimed.

9. **AgentCore delivery — Implemented · default off** — Destination binding, per-generation obligations, scheduling, publication receipts, exact retrieval verification, and metadata-only status are implemented. Optional Memory write-back remains separately qualified with simulated AWS transports.

10. **Carry-forward consolidation — Proposed · not implemented** — A versioned long-term summary baseline and automatic S3 archival are not implemented. Checkpoint recovery does not preserve expired contributions as institutional knowledge.

11. **Real-history verification (Kam Sports) — 365-day plan · not executed** — A separate bounded closing-ATS replay passed locally with real Rust and simulated storage at an earlier source checkpoint. The full 365-UTC-date real-history plan, live season workload, process-crash recovery, and hosted compatibility remain unqualified. Kam Sports supplies grades; Kam records them.

12. **History console — Implemented in website source** — The read-only console uses configured Cognito identity and existing History reads to browse authorized workspaces, manually entered scopes, UTC days, and exact revisions. Production History configuration is absent in the reviewed web deployment, so it reads no History data.

13. **Production assurance — Not yet qualified** — Source checks and independent artifact execution do not establish deployed IAM, a Marketplace listing, production SLOs, compliance approval, or measured costs and latency.

> **Current release boundary**
> Marketplace availability, production p99, and production AgentCore write-back remain qualification gates. The delivery loop is implemented, disabled by default, and tested through simulated transport. This is not live production qualification.

## Reference workload, not enterprise semantics

NFL helped establish patterns in the separate sports project. This extracted service uses a terminal-outcome reducer; it does not import ATS grading, provider capture, or game finalization into customer workflows.

## Bounded work is not a latency measurement

Candidate limits include 32 scopes per licensed workspace, eight cumulative categories, 4,096 identities per scope/day, and up to 32 references per read. These are supported-envelope limits, not throughput or cost promises.

Live acceptance/read latency, local publication lag, AgentCore visibility, costs, and oldest-pending work still need measurement. The website charts use synthetic records and do not report production performance.

# What Kam stores, writes, reads, and proves

Review the State add-on beside AgentCore: storage authority, accepted writes, exact reads, reconciliation, recovery and their qualification limits.

Status: Implemented in source. Prelaunch; not a live service guarantee.
Describes the History contract implemented in source. Nothing here is live-qualified, and no deployment is offered from this page.

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

## In short

Review the State layer your AgentCore application would rely on: what Kam stores, what a write commits, what an exact read proves and where recovery stops. Keep DynamoDB authority, Rust semantics, runtime execution and application decisions distinct.

**Available today:** The reviewed source implements History and bounded State contracts. Package receipts are local evidence, not live AgentCore or production qualification.

> Review what the State add-on proves before wiring it into an AgentCore application.

## Review the State layer beside AgentCore

- **Storage authority** — DynamoDB holds authoritative Kam data; Rust defines admitted State changes.
- **Exact read evidence** — Keep revision, fixed membership, scope and work limits together.
- **Runtime responsibility** — AgentCore execution and application decisions are outside a State read.
- **Recovery evidence** — Inspect accepted results and unfinished processing without assuming external success.
- **Release qualification** — Match the exact artifacts; local tests do not establish live production access.

## What is stored

1. **Outcome revisions** — Immutable (id, revision) records your application declares: subject, type, occurrence time, success or failure, category, and source references. Kam does not store your system of record, model prompts, or agent transcripts.

2. **Day membership** — Ordered references naming which exact revisions belong to one scope and UTC day, published as generations.

3. **Durable work records** — Work owed to the projection worker, committed with each accepted revision (a transactional outbox).

4. **Checkpoints and projections** — Saved fold state and applied sequence, plus the trajectory comparisons derived from them.

5. **Delivery obligations and receipts** — Only when optional AgentCore delivery is enabled (default off): one obligation per eligible generation, with separate publication and verification receipts.

[Glossary: outcome revision](/docs/concepts#outcome-revision)

## The write path

1. **1. Authenticate and authorize** — API Gateway verifies the Cognito access token; the handler re-checks issuer, client and scope, takes the principal from sub, and authorizes the requested tenant. A tenant ID in the request is not permission.

2. **2. Admit** — Rust validates identity, revision, occurrence time against the working window, and budgets. A correction must be exactly the next revision and cannot move the occurrence time.

3. **3. Commit atomically** — One DynamoDB TransactWriteItems call commits the revision, its day membership, and the work record, guarded by version conditions. Identical resubmission returns duplicate with the original acceptedSequence; a different payload for the same revision is rejected.

4. **4. Wake and fold** — A best-effort wakeup starts the worker. If it fails, the committed work record is redriven. The worker folds accepted revisions in sequence order.

5. **5. Publish** — A separate transaction commits the checkpoint, the new generation, and any eligible delivery obligation. Acceptance and publication are two transactions, not one.

[Glossary: acceptance transaction](/docs/concepts#acceptance-transaction)

[Glossary: transactional outbox](/docs/concepts#outbox)

## The read path, and what each read proves

1. **trajectory()** — Proves the projection as of appliedSequence, alongside acceptedSequence. If they differ, accepted work is not yet folded.

2. **allIds()** — Proves membership: these exact revision references belong to this generation, through acceptedThroughSequence. It does not assert that every real-world event was reported (externalCompleteness: not_asserted).

3. **byIds() in generation mode** — Proves each named revision is retained and matches its content hash, in caller order, and that it belongs to the generation. Missing, expired and unresolved positions stay explicit.

4. **byIds() in direct mode** — Proves a known (id, revision) is retained. It makes no membership claim and never falls back to the latest revision.

5. **What no read proves** — That an agent consumed the record, that the external fact is true, or who authored it. A content hash is integrity, not a signature.

## Where consistency and concurrency apply

Ordering is per scope: each tenant, subject and type has its own contiguous acceptedSequence and no global commit counter. Concurrent writers use optimistic concurrency; a stale version is rejected, not merged.

Each storage read is strongly consistent. A read that spans pages is made consistent by pinning a generation and passing its cursor back with it; if the service would have to switch generations, the read fails instead.

Kam makes no linearizability, serializability, or cross-scope isolation claim, and projections are asynchronous relative to acceptance.

[Glossary: conditional write](/docs/concepts#conditional-write)

[Glossary: generation](/docs/concepts#generation)

[Glossary: strongly consistent read](/docs/concepts#consistent-read)

## How recovery works

Work is persisted before anything relies on a wakeup, so a lost message delays processing instead of losing it. Processing is at-least-once and idempotent; Kam does not claim exactly-once execution.

Ambiguous external responses stay UNKNOWN until reconciled, and lifecycle epochs stop old jobs from acting with new authority. Owner export, export-bound deletion and a restore fence are implemented in source; live restore and erasure drills are not qualified. There is no arbitrary point-in-time recovery.

[Recovery and authority](/docs/reliability)

## Retention and deletion

New outcomes are admitted for today plus the previous 364 UTC dates. Retained evidence carries its own deadline of up to 730 days. Reads report a revision past its deadline as expired immediately; DynamoDB TTL removes the item later, typically within a few days, so expiry is not proof of physical deletion.

[Glossary: logical expiry](/docs/concepts#logical-expiry)

[Retention guide](/docs/retention)

## Who is responsible for what

1. **Your application** — Business meaning of success and failure, stable IDs, idempotency of external effects, and the agent runtime.

2. **Kam** — Admission rules, per-scope ordering, immutable revisions, generations, projections, and receipts, with the limits stated above.

3. **Identity and access** — Cognito authenticates the principal. The History API decides which workspaces that principal can read. Neither the browser nor this website grants access.

4. **Deployment** — Kam is designed for deployment on AWS. No live hosted service or Marketplace listing is offered today; an evaluation needs an isolated deployment and an explicit review of identity, permissions, retries, corrections, and exit.

## What remains unqualified

Every capability below is shown at the highest level its recorded evidence supports. No capability is live-qualified, pilot-only, or production-authorized.

1. **History — Locally qualified** — Package qualification is not a live deployment.

2. **Identity & membership — Locally qualified** — Covered by the same package qualification as History.

3. **Views & current State — Source-implemented** — Reviewed View and reconciliation source; no live-qualified or publicly offered hosted State service is established.

4. **State queries & Components — Source-implemented** — SDK 0.40.0 has a passed offline artifact receipt; the source claim is limited to supported bounded operations, not arbitrary payload queries or live service qualification.

5. **Metrics, materialize & watch — Planned · not available** — Design preview only.

6. **Turn Lifecycle — Locally qualified** — Merged native toolkit; reference-only local frames.

7. **Versioned Context manifests — Source-implemented** — Exact capture, ordered manifests and bounded assembly exist in source. Automatic ranking, managed runtime wiring and live model-consumption proof are not established.

8. **Operational durability — Source-implemented** — History and reconciliation progress are durable in source; no named checkpoint API.

9. **Profiler & developer toolkit — Locally qualified** — Merged; Linux x64 only; no public distribution.

10. **Optional AgentCore delivery — Locally qualified** — Default off; simulated AWS transports only.

11. **Export, deletion & restore fence — Source-implemented** — Live erasure and restore drills are qualification gates.

[What has been tested](/docs/qualification)

## Quickstart: record, retry, correct, read both revisions

Every call below exists in SDK 0.40.0. Obtain the reviewed private package through an evaluation; the package-name import assumes that artifact has already been supplied. An authorized endpoint, principal and tenant binding are separate prerequisites. No public npm release or self-serve endpoint is offered.

The duplicate assertion checks the same retained revision and acceptance sequence. It does not deduplicate an external model or tool action.

### Assert an exact retry, then read both revisions

```javascript
// Private SDK 0.40.0. Not published to npm. Methods checked against the pinned typings.
// Run in Node 22 with the supplied evaluation package and an authorized endpoint, tenant and token.
import assert from 'node:assert/strict';
import { createKamClient } from '@kam-ai/agentcore-history-sdk';
const kam = createKamClient({
  baseUrl: process.env.KAM_API_URL,
  tenantId: process.env.KAM_TENANT_ID,
  accessToken: () => process.env.KAM_ACCESS_TOKEN,
});
const checks = kam.scope({ subjectId: 'checkout', type: 'deployment' });

// 1. Record revision 1, then resend the identical payload while its evidence is retained.
const original = { id: 'deploy-0412', occurredAt: '2026-10-06T17:00:00.000Z', status: 'success' };
const first = await checks.outcome(original);
const retry = await checks.outcome(original);
assert.equal(retry.status, 'duplicate');
assert.equal(retry.acceptedSequence, first.acceptedSequence);
assert.equal(retry.revision, first.revision); // No new accepted revision.

// 2. Correct it: the next revision, same id and occurredAt. Revision 1 is kept while retained.
const second = await checks.outcome({ id: 'deploy-0412', revision: 2, occurredAt: '2026-10-06T17:00:00.000Z', status: 'failure' });
console.log(first.acceptedSequence, second.acceptedSequence); // per-scope order

// 3. Read both exact revisions. Direct mode makes no day-membership claim.
const exact = await checks.byIds({ refs: [{ id: 'deploy-0412', revision: 1 }, { id: 'deploy-0412', revision: 2 }] });
for (const record of exact.records) console.log(record.ref.revision, record.status);
```

# Glossary: the terms these guides use

Distinguish recorded State, exact History, recall and execution when designing an AgentCore application. Each Kam term names a defined responsibility and limit.

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/concepts

## In short

Use one word for each responsibility in an AgentCore design. A revision names a saved version; membership fixes which references belong together; a View answers a declared State question. Recall, model reasoning and tool execution remain separate from those recorded facts.

**Available today:** Implemented terms cite the reviewed backend tests. Source definitions do not establish a live deployment or an execution guarantee.

> Name State, recall and execution separately in an AgentCore design.

## Name one responsibility at a time

- **Identity and membership** — Which exact State versions belong to the requested fixed list?
- **View and evidence** — Which declared question do those references answer?
- **Recall and execution** — Memory recalls context; the AgentCore application decides and acts.

## One State model, many questions

A few primitives answer most questions about agent State: identity, revision, membership, view + dependencies, authority, bounds, obligation + receipt, retention clock. A new question should first become a View, selector, reducer or lifecycle rule over them, not a new service. Questions that belong to AgentCore or to a model are labelled as such.

1. **Calendar periods · Derivable from existing primitives** — What exact History belongs to this year, month, week, day, or saved date range? The frontend calendar builds normalized yearById, monthById, weekById, dayById, and customById selectors over supplied exact History. Ordered year, month and day children share one occurrence catalogue; structural dates have unknown source coverage. One displayed year can include 366 calendar dates without widening the 365-date read or custom-range limits. Browser presets save date preferences only; cross-page collection, scheduling, and Google Calendar synchronization are not implemented.

2. **Recommended reviews · Derivable from existing primitives** — Which supplied changes and recorded readers match a declared review rule? A frontend review policy groups exact input-version differences, reported failed checks and unavailable lookups into bounded, inspectable review roots. Candidates preserve source coordinates, recorded paths, coverage and work limits. Calendar containment is separate from dependency reads. The authorized console does not supply exact dependency edges today; it cannot infer them from opaque source references. Recommendations do not certify importance, confidence, safety, or action eligibility, and do not execute work.

3. **Calendar summaries and patch notes · Derivable from existing primitives** — What changed in this period, and which exact versions have recorded readers? A bounded frontend selector summarizes supplied occurrences, compares successive exact revisions of the same State identity, and searches recorded labels, values and reader references. A prior supplied revision may sit outside the chosen dates; its boundary remains visible. Patch notes show supplied before/after evidence and name recorded readers without implying that a newer revision was consumed. Summaries use deterministic counts and templates, not model inference. Missing pages, prior revisions and dependency evidence remain unknown.

4. **Personal watchlist · Planned** — What records do I want to follow, in my order? An ordered reference collection with per-entry selectors. The public explorer has a temporary fixture preview; authorized, durable watchlist mutations are not implemented.

5. **Since my last review · Derivable from existing primitives** — What changed, and why does my declared review rule flag it? The release-verification fixture View separates endpoint differences, retained activity, and a named domain rule. Explicit review actions acknowledge displayed exact boundaries in memory only; durable reviews and notifications are not implemented.

6. **Saved calculation selection · Planned** — Which supported calculation, inputs and period produced this result? A definition selects a qualified domain calculator and pinned inputs; its result is versioned State displayed by Views. No new backend primitive or generic business calculator is claimed.

7. **Operational memory · Planned** — What work can a replacement agent recover? History and obligations are retained; an explicitly opened local SQLite host can recover accepted records and pending projection work. Managed recovery of whole agent tasks remains planned; the explorer runs no agent.

8. **Workflow coordination · Planned** — Which parent-child work is eligible? Ordered membership and explicit dependencies are separate. The explorer previews valid order; hosted customer workflow management is planned.

9. **Computation reuse · Planned** — What can be reused without mistaking stale input for a cache hit? Local comparison reuse and bounded reads exist. General calculation caching needs explicit applicability and live measurement; fixture counts are not savings.

10. **History · Implemented in source** — What exactly was recorded? allIds() names exact revision references; byIds() returns exactly those revisions.

11. **Correction · Implemented in source** — What was revised, and what did it replace? A correction is the next revision; the earlier one stays readable while retained.

12. **Snapshot · Implemented in source** — What did this collection look like when it was published? A generation fixes ordered membership; pages are read against it.

13. **Difference · Derivable from existing primitives** — What changed between two publications? Compare exact membership from two generations. The SDK also has bounded diffRevisions over two declared selected-reference arrays; it does not establish a generic generation-diff endpoint or external source completeness.

14. **Dependency · Implemented in source** — What relies on this information? Views register versioned dependencies; a reverse index finds dependents.

15. **Invalidation · Implemented in source** — Which derived State must be recomputed after this change? Reconciliation pages through affected Views and recomputes only those.

16. **Freshness · Implemented in source** — Is this current enough to act on? Active State reports current, stale, blocked or absent. Only current carries usable items; the application still decides whether to act.

17. **Authority · Implemented in source** — Who may read this, in which scope? The service resolves the principal's workspaces; a tenant in a request is not permission.

18. **Expiration · Implemented in source** — When does this evidence stop being usable? Reads report expired at the deadline, before storage cleanup.

19. **Receipt · Implemented in source** — What work is still owed, and what was acknowledged? Delivery keeps one obligation per eligible generation and separate receipts.

20. **Bounded query · Implemented in source** — Which current evidence matches, within declared work limits? explain() reports the query plan and fixed work limits; value() executes the query over one Active State’s evidence references.

21. **Context budget · Implemented in source** — Which selected exact evidence fits this context budget? An ordered, versioned Context manifest selects exact captured evidence and full, descriptor or excluded representations. Assembly enforces item and byte limits; unavailable required evidence blocks a complete package. Automatic relevance ranking and provider-token budgeting remain planned.

22. **Subscription · Planned** — Which agents should wake when this changes? watch() is planned; the internal event path is not a customer subscription.

23. **Authorized history · Needs data Kam does not record** — What was this agent allowed to see yesterday? Access is checked at read time and is not itself recorded as History.

24. **Decision · AgentCore or your runtime** — What should the agent do next? Your agents and application on AgentCore plan, decide, and call tools. Kam records the outcome and the exact State the application reported as input.

25. **Confidence · A model, not Kam** — How likely is this forecast to be right? A model computes it; Kam can retain the output and its inputs as evidence.

[See the question graph](/architecture#questions)

## How to read this glossary

Each term gives the standard concept first, then what Kam means by it, then where the guarantee stops. Evidence names a test or source file in kam-agentcore-history at e16b81b4; storage behavior links to the AWS documentation it depends on.

## Context manifest

Standard concept: An ordered, versioned selection of exact evidence references with an explicit representation for each entry.

In Kam: A consumer manifest keeps up to 16 selected evidence entries as full, descriptor or excluded. Hide and restore create new manifest versions; earlier retained selections still name their original evidence.

Limits: Capture and assembly are implemented in source. A manifest is not a model-submission receipt, automatic ranking, a universal memory record or a live-qualified managed service.

Evidence: server/trajectory/test/context-manifest-integration.test.cjs — “real Rust and SDK preserve exact capture, ordered manifests, hide/restore and recovery against simulated durable storage”.

## Bounded Context assembly

Standard concept: Construct a consumer representation from a declared selection while checking authorization, availability and fixed item and byte limits.

In Kam: assembleContext resolves at most 32 exact keys for up to 16 manifest entries and a caller budget up to 192 KiB. Required evidence that is unavailable or expired blocks a complete package; inspection does not hydrate payloads.

Limits: The budget counts captured evidence bytes, not provider tokens or a complete model request. There is no scan, semantic fallback, automatic ranking or substitution of a newer revision.

Evidence: server/trajectory/test/context-manifest-integration.test.cjs — “assembly enforces exact references, required coverage, byte limits and serving-boundary authority”.

## History inspection

Standard concept: A read-only projection of exact hydrated records that preserves request order and distinguishes recorded facts from unobserved effects.

In Kam: inspectHistory performs one byIds request and reports ready or partial entries in requested-reference order. The client explicitly supplies local, remote or unknown acceptance location; unknown is the default.

Limits: Adapter-supplied acceptance location is not independently observed delivery. Model consumption and tool effects remain not_observed; inspection invokes no models, tools or replay.

Evidence: server/trajectory/test/trajectory-inspection.test.cjs — “exact hydration, explicit partial dispositions and acceptance context do not synthesize invocation or effect evidence”.

## Outcome revision

Standard concept: An immutable, versioned record in an append-only log: a new version is added and earlier versions are never updated in place.

In Kam: An outcome is identified by (scope, id). Each accepted version is (id, revision) with revision = 1, 2, 3… A correction must be exactly the next revision and cannot move the original occurrence time.

Limits: Immutable while retained, not permanent. Retained evidence expires on its own deadline (up to 730 days). This is not WORM storage and not full event sourcing: Kam stores declared outcomes, not every domain event in your application.

Evidence: server/trajectory/test/contracts.test.cjs — “append is idempotent; conflicts and skipped revisions fail without extra work”; server/trajectory/test/history.test.cjs — “real Rust owns correction revision and immutable identity admission”; server/trajectory/test/history-integration-contract.test.cjs — “a correction cannot move the original occurrence anchor or replace the exact prior revision”.

## Accepted sequence

Standard concept: A per-partition log sequence number: a total order of accepted writes within one partition, with no order between partitions.

In Kam: Each scope assigns every accepted revision a unique, contiguous acceptedSequence. Scopes have independent counters; there is no global commit counter.

Limits: Ordering holds within one scope only. Kam makes no cross-scope ordering, linearizability, or serializability claim.

Evidence: server/trajectory/test/contracts.test.cjs — “four concurrent outcomes have unique contiguous committed sequence numbers”; server/trajectory/test/history-integration-contract.test.cjs — “independent scoped writers do not share State identity or version counters”.

## Conditional write (optimistic concurrency)

Standard concept: Optimistic concurrency control: a write succeeds only if a version attribute still holds the value the writer read; otherwise it fails with ConditionalCheckFailed and the writer re-reads.

In Kam: Every storage write states its expected version, or that the item must not exist yet (attribute_not_exists), and can add ConditionCheck guards on related items such as lifecycle state and authority epoch.

Limits: A conflict is rejected, never merged. Only recognized transient failures are classified as retryable. Permission and validation failures require investigation or correction. No storage failure is treated as proof of a duplicate submission.

Evidence: server/trajectory/src/table.cjs — “put(): ConditionCheck on version, state and authorityEpoch; Put with attribute_not_exists(PK) or #v = :v”; server/trajectory/test/contracts.test.cjs — “Dynamo throughput or mixed transaction failures are not swallowed as duplicates”.

[AWS: DynamoDB condition expressions](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.ConditionExpressions.html)

[AWS: optimistic locking with a version number](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBMapper.OptimisticLocking.html)

## Acceptance transaction

Standard concept: An all-or-nothing multi-item transaction within one database (DynamoDB TransactWriteItems): every write and condition check succeeds together, or none is applied.

In Kam: Accepting a revision commits the revision, its day membership, and a durable work record in one TransactWriteItems call (Kam caps it at 25 items). Publishing a checkpoint and generation is a separate, later transaction.

Limits: One table, one transaction at a time. There is no transaction across AWS services, and acceptance and publication are not one atomic step.

Evidence: server/trajectory/src/table.cjs — “put(): one TransactWriteCommand with ConditionCheck and Put items, at most 25”; server/trajectory/test/contracts.test.cjs — “failed wakeup retains the outcome and durable work record”.

[AWS: DynamoDB transactions](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transaction-apis.html)

[AWS: TransactWriteItems API](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactWriteItems.html)

## Durable work record (transactional outbox)

Standard concept: The transactional outbox pattern: work owed to a downstream processor is written in the same transaction as the state change, then delivered asynchronously.

In Kam: The work record commits with the accepted revision. The wakeup that follows is best effort; if it fails, the record stays and is redriven.

Limits: At-least-once processing: a worker may see the same work more than once, so processing is idempotent. Kam does not claim exactly-once execution.

Evidence: server/trajectory/test/contracts.test.cjs — “failed wakeup retains the outcome and durable work record”; server/trajectory/test/history.test.cjs — “outbox corruption is detected BEFORE reducer invocation; one corrupt scope does not block another”.

## Idempotent acceptance

Standard concept: Idempotency-key deduplication: a retried request with the same key and payload returns the original result; the same key with a different payload is rejected.

In Kam: The key is (scope, id, revision). Resubmitting an identical revision returns status duplicate with the original acceptedSequence. A different payload for the same revision fails with idempotency_payload_conflict.

Limits: Deduplication lasts while the revision is retained. It does not use the DynamoDB ClientRequestToken, whose idempotency window is 10 minutes. It covers acceptance only; it cannot stop an external payment or deployment from running twice.

Evidence: server/trajectory/test/contracts.test.cjs — “append is idempotent; conflicts and skipped revisions fail without extra work”.

[AWS: TransactWriteItems API](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactWriteItems.html)

## Generation

Standard concept: An immutable snapshot identifier: a read pinned to it sees one fixed version of a named collection, however that collection changes afterwards.

In Kam: A generation is typed. A day generation names the fixed, ordered set of exact revision references for one scope and UTC day; a trajectory generation names a separately published trajectory snapshot. Callers keep the generation returned by the API they are reading.

Limits: A day generation covers accepted outcomes through acceptedThroughSequence only. Neither generation type asserts that every real-world event happened or was reported, and neither is a database-wide point-in-time view.

Evidence: server/trajectory/test/history.test.cjs — “real HTTP/SDK reads a pinned day across split pages, late arrival, correction and retry”; server/trajectory/test/history.test.cjs — “a changed Rust generation response cannot cross its requested day or generation”.

## Exact hydration

Standard concept: A batched point read by primary key and version: return exactly the named versions, in the requested order, never the latest.

In Kam: byIds() reads up to 32 references in caller order and reports each as found, unresolved, unavailable, or expired. Generation mode also proves membership in a generation; direct mode reads a known (id, revision) with no membership claim.

Limits: A missing or expired revision stays missing; Kam never substitutes a newer one. A key DynamoDB returns as unprocessed is reported as retryable, never as missing.

Evidence: server/trajectory/test/history.test.cjs — “exact hydration preserves caller order and distinguishes unprocessed, missing and expired records”; server/trajectory/test/history.test.cjs — “known ID/revision hydrates directly without enumerating a day or following latest”.

[AWS: BatchGetItem and UnprocessedKeys](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_BatchGetItem.html)

## Strongly consistent read

Standard concept: A read that reflects every write acknowledged before it began, for a single item or query.

In Kam: History storage reads use DynamoDB strongly consistent reads (ConsistentRead: true) for get, batch get, and range queries.

Limits: Per call only. A read that spans several calls is made consistent by pinning a generation, not by a multi-call transaction. No linearizability or serializable-read claim across calls or scopes.

Evidence: server/trajectory/src/table.cjs — “get, batchGet and range issue ConsistentRead: true”.

[AWS: DynamoDB read consistency](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html)

## Projection (trajectory)

Standard concept: A materialized view maintained incrementally by a deterministic fold over an ordered log, resumed from a checkpoint.

In Kam: The trajectory (last ten results, 30- and 90-UTC-day windows) is folded from accepted revisions in sequence order. acceptedSequence and appliedSequence are both returned, so the lag between them is visible.

Limits: Asynchronous: it lags acceptance until the worker applies the work. A reader compares appliedSequence with acceptedSequence; this is not read-your-writes for the projection.

Evidence: server/trajectory/test/history.test.cjs — “real Rust admits the exact contiguous reducer work-evidence batch”; server/trajectory/test/e2e.test.cjs — “new ingress does not starve publication; accepted prefix remains visibly pending”.

## Checkpoint

Standard concept: A stream-processing checkpoint: saved fold state plus the last applied offset, used to resume.

In Kam: The saved reducer state and appliedSequence for one scope, committed with the generation it published.

Limits: A checkpoint resumes processing; it is not a lifetime summary. Carry-forward consolidation and S3 archival are not implemented.

Evidence: server/trajectory/test/lifecycle.test.cjs — “cancellation after reducer compute but before commit prevents publication”; server/trajectory/test/lifecycle.test.cjs — “deadline closing during reducer computation prevents publication and records the old checkpoint”.

## Content hash

Standard concept: A SHA-256 digest used to detect accidental or unauthorized change to stored bytes.

In Kam: Each revision reference carries the SHA-256 of its canonical content. Hydration recomputes the hash of the stored record and rejects it if either value differs.

Limits: Integrity, not authenticity: a hash is not a signature and does not identify who wrote the record. A source reference does not certify that the external fact is true.

Evidence: server/workers/rust/src/history/hydration.rs — “canonical_hash_with_javascript_numbers(record.event) must equal record.content_hash and the reference hash”; server/trajectory/test/history.test.cjs — “generation membership, namespace, corruption, time-zone and bounds cannot be bypassed”.

## Logical expiry

Standard concept: The application's decision that a record is no longer eligible or available under its contract, regardless of whether storage has deleted its bytes.

In Kam: Every retained revision has an evidenceUntil deadline. Reads report a revision past that deadline as expired immediately. DynamoDB TTL is the separate background cleanup mechanism and may delete the bytes later.

Limits: Logical expiry is not proof of physical deletion, and Kam offers no arbitrary point-in-time recovery of expired evidence.

Evidence: server/trajectory/test/history.test.cjs — “daily evidence survives the snapshot interval; expiry is logical even before TTL cleanup”.

[AWS: DynamoDB Time to Live](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html)

## Standard terms Kam does not claim

1. **Event sourcing** — Kam stores outcomes your application declares, not every domain event, and it does not rebuild your application state.

2. **CQRS framework** — Kam separates its own write path from its read models, but it does not provide command handling for your application.

3. **Linearizable or serializable reads** — Single reads are strongly consistent; multi-call reads pin a generation. There is no cross-call or cross-scope isolation claim.

4. **Exactly-once execution** — Acceptance is idempotent and processing is at-least-once. External effects need their own idempotency.

5. **Cryptographic authenticity** — Content hashes detect change; nothing is signed.

6. **Permanent immutability** — Revisions are immutable while retained and expire on explicit deadlines.

7. **Arbitrary point-in-time recovery** — Generations pin published snapshots; Kam does not restore any past instant on request.

## Delivery and comparison terms

1. **Outcome** — A completed success or failure result declared by your application.

2. **Trajectory** — Precomputed comparisons: last ten results, and 30- and 90-UTC-day windows.

3. **Delivery obligation** — Durable work owed for one eligible generation. It is not proof of a successful delivery.

4. **Verified retrieval** — An exact destination record matched at a recorded time. It is not evidence of agent consumption.

## The state-platform vocabulary

These names clarify responsibilities. They do not rename stored generation fields or make an internal capability public.

1. **Directory** — Bounded, authorized discovery of scopes and Views. A general managed Directory remains planned; the SDK has workspace discovery.

2. **View** — A versioned declaration of required or optional evidence, source identities, freshness and selection limits. A bounded owner-configured registry now exists in source.

3. **Active State** — The maintained deterministic projection and current reuse assessment over exact source versions, freshness limits and authority boundaries.

4. **ChangeSet** — The typed difference that should drive reconciliation. Exact or provenance changes are distinct from semantic, freshness, authority or assembled-request changes; the full typed model remains product direction.

5. **Observation** — An immutable structured assessment at a defined boundary. It does not establish that a model received, used, or agreed with the evidence.

6. **Snapshot** — An exact, typed published-version coordinate. Existing generation fields and historical identities are not renamed.

7. **Turn Lifecycle** — Resolve, detect, reconcile, assemble, reason, commit, and revalidate. The native toolkit prepares local references; a separate controlled adapter can record request stages. Automatic runtime interception remains planned.

8. **Turn Frame** — A local candidate artifact that binds prior-frame identity, exact assessment/input hashes, State identity and reference preparation for one diagnostic turn cycle.

9. **Operational Checkpoint** — The planned durable coordinate across History or Snapshot, View, Active State, Observation and computational versions. It should reference immutable objects rather than copy the world.

10. **ReadSet** — The planned exact dependency set a turn relied on, used to decide whether later changes require reassembling the context or revalidating an action.

11. **Action Barrier** — A planned optimistic revalidation boundary before consequential external effects. It is not implemented action authorization.

12. **Receipt** — Evidence for one named operation and stage. Acceptance, reconciliation, submission, completion and verification establish different facts.

# Install and connect Kam AI developer tools

Prepare the approved local toolkit and private SDK for an AgentCore project. Local installation does not configure a runtime, grant cloud access or qualify a deployment.

Status: Merged · local only. Prelaunch; not a live service guarantee.
Native toolkit 0.1.0 is merged into the backend (PR #176) and qualified in CI as a network-disabled Linux x64 artifact. No public binary release, macOS/Windows distribution, or live AWS connection is offered here. SDK 0.40.0 is source-implemented but not published to npm; an authorized service endpoint and tenant binding are separate prerequisites.

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

## In short

Prepare local tools for the State layer of an AgentCore application. Verify the supplied Linux x64 artifact, add the approved private SDK to an authorized backend, and give a coding agent read-only MCP access. Those steps do not attach Kam to a running agent.

**Available today:** The CLI and MCP are qualified locally for Linux x64. Private SDK 0.40.0 is unpublished; service authority and live runtime integration are separate.

> Prepare the State tools for an AgentCore project; qualify the connection separately.

## Prepare an AgentCore State project

- **Verify the local artifact** — Use the approved Linux x64 candidate and its recorded provenance.
- **Add authorized SDK access** — Local installation does not supply a service endpoint or tenant authority.
- **Keep runtime setup separate** — CLI and read-only MCP do not attach tools to AgentCore.

## Before you install

You need a Linux x64 development environment, an existing application directory, and the separately supplied Kam 0.1.0 artifact from the qualified backend CI run. Record its version, checksum, and provenance before use.

SDK use additionally requires an authorized backend source checkout, the exact approved SDK 0.40.0 package, a Kam service endpoint, and a server-authorized tenant binding. The CLI and MCP do not require AWS credentials or connect your account to the managed service.

There is no public CLI registry package, public SDK npm package, Homebrew formula, macOS build, or Windows distribution. Do not substitute similarly named packages from a public registry.

[Request candidate access](/support)

## Step 1: place the CLI on your PATH

Use the filename and checksum supplied with the approved artifact. The example keeps the binary in a user-owned directory; adapt the path to your organization’s software policy.

### Install and verify the approved candidate

```bash
mkdir -p "$HOME/.local/bin"
install -m 0755 ./kam "$HOME/.local/bin/kam"
export PATH="$HOME/.local/bin:$PATH"

kam --version
kam capabilities --json
```

> **Verify before use**
> Do not substitute an artifact from an unreviewed source. A successful version command establishes local execution only—not service access, deployed IAM, or production qualification.

## Step 2: initialize one project

Run from the application directory you want Kam to inspect. The first command prints the proposed changes. Nothing is written until you repeat it with --write.

### Plan, write, and check local setup

```bash
cd /path/to/your-application
kam init --template deployment-agent
kam init --template deployment-agent --write
kam doctor --json
kam generate --check
```

> **Local diagnostic boundary**
> kam doctor checks local configuration, declarations, and generated-file drift. It is separate from the authenticated kam-history doctor command and does not prove cloud permissions.

## Step 3: add the SDK to an authorized backend

Use the exact approved SDK source supplied for your evaluation and preserve its version with the backend that calls it. The current import is repository-local; there is no supported npm install command.

Configure endpoint, tenant, and access-token inputs through your backend’s existing secret and deployment controls. Never embed credentials in browser code, generated agent guidance, MCP configuration, or this static website.

### Create a scoped client and preserve exact references

```javascript
// Save as a .mjs file in an authorized backend source checkout. SDK candidate 0.40.0.
// This is a read-only example, not code executed by the website.
import { createKamClient } from './server/trajectory/sdk/index.mjs';
const kam = createKamClient({
  baseUrl: process.env.KAM_API_URL,
  tenantId: process.env.KAM_TENANT_ID,
  accessToken: () => process.env.KAM_ACCESS_TOKEN,
});
const deployments = kam.scope({ subjectId: 'checkout', type: 'deployment' });
const page = await deployments.allIds({ day: '2026-10-06', limit: 16 });
if (page.status === 'ready' && page.items.length > 0) {
  const exact = await deployments.byIds({
    day: page.day,
    generation: page.generation,
    refs: page.items,
  });
  console.log(exact.records); // Keep every position and result status.
}
// A short page is not the end when nextCursor is present.
// Continue with the SAME generation and returned cursor.
```

> **Service access is separate**
> Possessing the SDK does not authorize a tenant or AWS account. Validate the approved endpoint, principal, server-side tenant binding, lifecycle status, and supported scope before sending outcomes.

[Read the full SDK integration guide](/docs/integrate)

## Step 4: connect the read-only MCP server

Add the server to a coding agent that supports local stdio MCP processes. Client configuration locations differ, but the server command and arguments follow this shape. Use the absolute path returned by command -v kam.

The client starts kam mcp and communicates over stdio. Do not wrap it in a TCP listener or add shell, credential, arbitrary-path, or write capabilities.

### Generic MCP client configuration

```json
{
  "mcpServers": {
    "kam": {
      "command": "/home/you/.local/bin/kam",
      "args": ["mcp"]
    }
  }
}
```

## Step 5: verify the connection

1. **Restart or reload the MCP client** — The client should start the local stdio process itself; a separate hosted Kam endpoint is not involved.

2. **List the Kam tools** — Confirm the client exposes only the documented read-only tools, including project status, View manifest, fixture replay, reference Atlas, and bundled docs.

3. **Read project status** — Call kam_project_status in the application directory and review configuration or drift findings. This is a local filesystem assessment, not an AWS account check.

4. **Keep effects explicit** — Use the CLI with --write for reviewed generation changes. MCP remains read-only and cannot install packages, edit files, run a shell, or deploy infrastructure.

[Understand every MCP tool](/docs/agent-tooling)

[Continue with the CLI workflow](/docs/toolkit)

## Durable local State is a separate package

The private local-host source runs the existing HTTP service and real Rust worker over SQLite. Explicit open, initialize and process calls preserve accepted records and pending projection work across a restart. Your application supplies authentication; local identities do not grant cloud permissions.

This host requires Node 24.19 or later and a checksum-pinned worker for the target platform. It is separate from the Linux x64 native CLI artifact and the transport SDK. Hosted Context, account/provider delivery and offline-to-cloud write synchronization are unavailable in this local host.

> **Source and platform qualification are separate**
> The local-host package is unpublished. Source conformance and a native CLI round trip do not establish a public installer, every platform build or live AWS qualification.

## Update or remove the candidate

There is no public self-update channel for the local CLI artifact. Replace it only with a separately supplied artifact from an approved qualification run, verify the new version and checksum, then rerun kam doctor and kam generate --check.

Update the SDK only from an approved source revision and review its API and service compatibility before changing the pinned package in your backend. Do not replace the repository-local package with an unverified registry package.

To disconnect MCP, remove the kam server entry from your client and reload it. Remove the local binary or SDK package only after confirming no project, backend, or client configuration still references it.

# Develop locally with the real Rust engine

Inspect State definitions for an AgentCore project with the local Rust toolkit and synthetic evidence, before connecting an authorized service.

Status: Merged · local only. Prelaunch; not a live service guarantee.
Native toolkit 0.1.0 is merged into the backend (PR #176) and qualified in CI as a network-disabled Linux x64 artifact. No public binary release, macOS/Windows distribution, or live AWS connection is offered here.

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

## In short

Check State definitions for an AgentCore project before connecting a service. The local toolkit runs the real Rust engine against synthetic inputs and shows proposed file changes before writing them. It does not start an agent, call tools or reach AWS.

**Available today:** The merged candidate is locally qualified for Linux x64. There is no public binary download or live AgentCore connection.

> Test State semantics locally before connecting your AgentCore application.

## Inspect the State contract locally

- **Start from a project** — Use the approved toolkit with the AgentCore application's State definitions.
- **Inspect the synthetic result** — Read exact IDs, limits and missing evidence from real Rust evaluation.
- **Keep the boundary visible** — The local tool makes no AWS, model or agent-tool calls.

## Start with the distribution boundary

This guide describes the native toolkit merged into the backend in PR #176. It is not an installer you can run from a public registry: access requires a separately supplied Linux x64 artifact from the qualified backend CI run, with its exact provenance. macOS and Windows distributions are not qualified.

The website is static documentation. It does not run Rust, create files, read credentials, or attach anything to your AWS account.

[Discuss toolkit access](/support)

[Compare source checkpoints](/updates)

## Inspect the plan before writing files

Run inside an existing application directory with the approved binary on your PATH. init is read-only until --write. generate --check detects drift rather than repairing it silently.

The lab supplies synthetic storage observations and explicit fences. It exercises real Rust decisions, not AWS transactions, a cloud emulator, or an agent execution.

### Local workflow — not a public installer

```bash
# Merged toolkit, no public binary. Use an approved Linux x64 artifact.
# No public installer is available. These commands run locally.
kam init --template deployment-agent
kam init --template deployment-agent --write
kam doctor --json
kam generate --check
kam dev --json
kam replay --scenario invalidated --json
kam atlas --scenario corrected --json
kam qualify --json
```

## One namespace, explicit effects

1. **Configure** — init · config · generate · doctor · env. Plan-first local files and diagnostics. kam doctor is not the remote kam-history doctor.

2. **Exercise** — dev · state · replay · atlas · preview · qualify. Synthetic observations and the actual Rust engine. No live source calls, agent replay, or token estimates.

3. **Inspect & explain** — inspect · docs · skills · mcp · capabilities. Private local reports and read-only agent tools. No hosted console or public share link.

4. **Plan integration** — connect agentcore · promote · rollback. Reviewable connection and local channel plans only. No Gateway attachment or remote rollout.

## Local, preview, and production are not interchangeable

The strict static kam.config.json compiles into a normalized, fingerprinted manifest. Profiles contain environment-variable names rather than secret values. Preview and production cannot fall back to synthetic local execution.

kam doctor checks local config, SDK declarations, and generated-file drift. kam-history doctor is the separate existing SDK command for remote account/onboarding metadata and requires explicitly supplied credentials. Neither is proof of effective deployed IAM.

## Connection and channel commands are plans, not deployment

connect agentcore emits a bounded History read-tool plan with authentication, tenant mapping, schema acceptance, and IAM work still to qualify. AgentCore tooling remains responsible for integration infrastructure.

promote and rollback record local review-channel changes. They do not deploy a policy, restore deleted evidence, or restore revoked permissions. qualify reports local fixture checks, not source-package or live AWS release qualification.

# Treat State as current only while its evidence remains valid

Read current State for an AgentCore task only when its declared evidence is present, applicable and within bounds. The application decides what to do with the result.

Status: Implemented in source. Prelaunch; not a live service guarantee.
Versioned Views, dependencies, current State, and bounded reconciliation are implemented in reviewed source. The exact main package is locally qualified with simulated AWS transports. That does not establish customer-production use or a publicly offered hosted service.

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

## In short

Let an AgentCore task ask a defined State question, such as whether the required checks are current. Kam returns current evidence only when required inputs are present, applicable and within limits; otherwise it reports blockers. Your application decides whether work may continue.

**Available today:** Views within the same scope and current-State reads are implemented in source. They do not authorize tool execution or establish live production qualification.

> Give your AgentCore application current evidence or an explicit blocker.

## Read State for the next task

- **Declare the evidence** — Name the exact required and optional inputs for the application's View.
- **Read current State** — Kam checks applicability and fixed work limits.
- **Decide in the application** — An AgentCore task proceeds only under the application's own action rules.

## The View owns requiredness

A View declares exact source identities, required and optional dependencies, priorities, freshness windows, and selection limits. Observations report lookup results; they cannot change that policy. Current invalidation counters are supplied separately.

An omitted required observation blocks selection. Foreign sources, duplicate or missing fences, future observation times, and unexpected fields are rejected. A late read from an older fence is invalidated even when it arrives last.

## Current means reusable evidence, not approval

1. **Missing or unresolved required evidence** — State is blocked with explicit issues and no usable selection identity. Missing evidence is not silently removed.

2. **Required references exceed the budget** — State blocks instead of trimming them. Optional references follow deterministic priority with explicit budget exclusions.

3. **Current evidence describes a failure** — The result may be current and still accurately report a failed security check. Admission is not a deployment decision.

## Freshness differs from retention

A freshness deadline makes evidence stale. Its availability deadline makes it expired. A newer invalidation counter can invalidate it earlier. All deadlines are exclusive; a reuse deadline is an upper bound, not permission to ignore later changes.

Exact versions across several sources do not establish one atomic cross-source snapshot. The runtime must check current permissions and source conditions at the serving or conditional-commit boundary.

## Views are connected to durable history

The server-owned trajectory-current View is connected end to end, and owner-configured Views can depend on it within the same scope. When a View's answer changes, Kam saves the new current pointer, a frozen Observation of the assessment, and a record of what changed in one conditional write. When the answer is unchanged, Kam reuses the existing pointer and avoids an unnecessary State write.

Change notifications are queued, bounded, and re-sent by a maintenance sweep if a wakeup is lost. When a source changes, Kam pages through the Views that depend on it, up to eight at a time, and saves its cursor so it can resume safely after a crash. Dependent execution supports one or more required sources in the same scope (PR #187); cross-scope joins remain staged. The private SDK reads the result with activeState() or a Component's read().

[Read the Observation boundary](/docs/observations)

## Measure the thing being limited

Internal admission accepts 1–32 dependencies, maxItems of 1–32, and maxReferenceBytes of 2–32,768. Reference bytes mean the UTF-8 JSON selected-reference array, including its metadata and punctuation.

This does not measure rendered prompts, model tokens, total response bytes, fetched payloads, or production latency. The native candidate’s Atlas displays the reference measurement without inventing a token conversion.

# Keep the Observation when current State changes

Inspect the retained assessment behind an AgentCore application's State change. An Observation records Kam's selection, not what a model consumed.

Status: Implemented in source. Prelaunch; not a live service guarantee.
Versioned Views, dependencies, current State, and bounded reconciliation are implemented in reviewed source. The exact main package is locally qualified with simulated AWS transports. That does not establish customer-production use or a publicly offered hosted service.

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

## In short

When current State changes, inspect the retained assessment and exact sources behind the change. An AgentCore application can use that evidence for review. The Observation records what Kam selected; it does not reconstruct later prompt formatting or prove model consumption.

**Available today:** Reads of exact retained Observations are implemented in source. They are historical evidence, not permission to reason or act with stale State.

> Inspect the recorded assessment an AgentCore task could read, without claiming model consumption.

## Review a retained assessment

- **Inspect the State change** — Read the exact retained Observation and its sources.
- **Check current applicability** — Historical evidence is not automatically valid for the next AgentCore turn.
- **Keep the capture boundary clear** — The application's later prompt formatting and model use are separate facts.

## Three records with different jobs

1. **Active State pointer** — Identifies the current assessment for the server-owned View, with lifecycle and source-version conditions.

2. **Immutable Observation** — Retains the exact structured assessment, scope, View, pointer version, and candidate hash for that successor.

3. **Change evidence and delivery receipt** — Describe a particular transition and its internal queue delivery. They do not establish that a customer agent received it.

## Selection is not the final model input

An application may filter, reorder, truncate, or reformat selected evidence before calling a model. The structured Observation alone cannot reconstruct those later transformations.

A separately qualified capture boundary must record the assembled evidence or an approved immutable content reference, ordered source revisions, and transformation versions. Submission is still not proof of internal reasoning, consumption, or decision quality.

## Immutable does not mean retained forever

Observations are derived customer data with availability and deletion responsibilities. Current source export classifies them with the State pointer, change events, delivery receipts, and cursor. Retention and live erasure have their own gates.

The private SDK reads an exact retained Observation with observation(); it never substitutes the latest version and always reports usableForCurrentReasoning: false. This source contract is not live production qualification. Automatic S3 History archival and universal historical reconstruction are not implemented.

[Retention and evidence availability](/docs/retention)

[Customer exit controls](/docs/marketplace)

# One command contract across the CLI and MCP

How local CLI and MCP tools share Kam's contracts and bounded reads while AgentCore execution stays with the application runtime.

Status: Local candidate · in review. Prelaunch; not a live service guarantee.
Native toolkit 0.1.0 is merged into the backend (PR #176) and qualified in CI as a network-disabled Linux x64 artifact. No public binary release, macOS/Windows distribution, or live AWS connection is offered here.

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

## In short

Understand the local tools used to prepare an AgentCore State integration. The CLI and read-only MCP surface share command definitions and bounded file reads. Their local filesystem contract is separate from deployed runtime permissions, model calls and tool execution.

**Available today:** These internals are part of the merged local toolkit. They do not create an AgentCore Gateway connection or a deployed service.

> Share one local Kam contract while your AgentCore application owns execution.

## Keep development tools and runtime separate

- **Share the command contract** — The local CLI and MCP use one definition for the same operation.
- **Inject bounded reads** — Read handlers have no writer, credential, shell or network capability.
- **Integrate explicitly** — AgentCore tooling and application code own the deployed connection.

## The same operation has one owner

1. **One command contract** — CLI options, help, and the explicit MCP subset come from one typed Rust catalog. This avoids maintaining separate command definitions for each interface. A new CLI command is not automatically an agent tool.

2. **One application read path** — The CLI and MCP share query handlers for local configuration, diagnostics, replay, and Atlas. Only their transport envelopes differ.

3. **One bounded operation context** — Each operation shares captured immutable file buffers and a normalized View index. The next request gets a fresh capture, not a global customer-state cache.

4. **Read-only dependency injection** — Read handlers receive a bounded ProjectReader with no writer, credential, shell, or network capability. The real Rust engine remains the decision owner.

5. **Protected generation** — Writes require --write. Planning and commit share conflict rules; changed configuration or managed guidance aborts the old plan.

6. **Two independent artifacts** — The service and native toolkit are packaged separately and tested without source or network. Local evidence is not a production release or live service guarantee.

## Borrow one View; capture one operation

A ProjectSnapshot keeps one normalized manifest and an ID-to-position index beside its ordered View payloads. Handlers borrow the selected View rather than copying it into another state store.

Each ReadSession shares immutable file buffers, misses, and errors within one operation. The limits are 128 file/presence observations, 2 MiB total captured content, and 300 KiB per file. Every subsequent MCP call gets a fresh capture.

This is not an atomic cross-file snapshot, a global tenant cache, a database migration, or a constant-time historical reconstruction guarantee. Only immutable embedded SDK/OpenAPI assets are shared process-wide.

## Inject reads, not permission to do everything

ProjectReader exposes bounded reads and presence checks. It has no writer, credential, shell, or network operation. Tests inject in-memory readers with counters and failures; production uses a checked filesystem adapter.

The canonical hashes and History/State engine are not replaceable through that interface. Local writes retain their source observations, acquire a cooperating-writer lock, recheck inputs, and re-plan against current target bytes. Changed config or guidance aborts a stale plan.

These controls protect cooperating local workflows. They do not claim an atomic multi-file transaction or a sandbox against a malicious filesystem owner.

# Give coding agents the same contract as developers

Give a coding agent version-matched Kam guidance for an AgentCore project. Local read-only MCP tools do not become deployed agent tools or a Gateway integration.

Status: Merged · local only. Prelaunch; not a live service guarantee.
Native toolkit 0.1.0 is merged into the backend (PR #176) and qualified in CI as a network-disabled Linux x64 artifact. No public binary release, macOS/Windows distribution, or live AWS connection is offered here.

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

## In short

Give a coding agent the same Kam contract a developer reads when building an AgentCore application. Version-matched guides and five local read-only MCP tools explain State and its limits. Connecting those development tools does not register tools with the deployed agent.

**Available today:** Website Markdown is available. Local MCP tools are part of the merged toolkit; managed AgentCore integration and public distribution remain separate.

> Help coding agents build an AgentCore State integration using the same documented contract.

## Give the coding agent the right tools

- **Read the same contract** — Use version-matched Markdown when planning the AgentCore State integration.
- **Inspect locally** — The documented MCP tools read bounded local evidence; they do not execute agents.
- **Authorize remote reads separately** — History access needs its own approved identity and service connection.

## Five tools, not a shell proxy

The server uses stdio with initialization and bounded framing, not a public TCP endpoint. Unknown, null, cross-tool, write, shell, and arbitrary-path arguments fail before project reads.

1. **kam_project_status** — Local configuration and generated-file drift. No live account or IAM check.

2. **kam_view_manifest** — A normalized manifest and configuration fingerprint, not deployed authority.

3. **kam_replay_fixture** — Re-evaluate supplied synthetic scenarios with the real Rust engine, without executing an agent.

4. **kam_reference_atlas** — Selected-reference JSON bytes and explicit omissions, not model-token counts.

5. **kam_docs** — Bundled version-matched documentation.

## Generated instructions are reviewable local files

Generation produces versioned Markdown, llms.txt, llms-full.txt, skills, and a managed AGENTS.md block. Surrounding customer instructions are preserved. Edits to managed content and concurrent source changes are detected.

Generating guidance does not install packages, activate an agent configuration, or register a GitHub workflow. The customer reviews the proposed artifacts and explicitly chooses integration steps.

## Read these website guides as Markdown

Each public guide has a Markdown equivalent generated from the same typed content as the HTML page. The documentation manifest lists both addresses. Availability labels and reviewed source identities are included; unpublished tools are not presented as installed services.

[Agent-readable index](/llms.txt)

[All guides in one document](/llms-full.txt)

# Separate subscribing, connecting, and authorizing

Plan setup, authority and data exit for an AgentCore State add-on. Source lifecycle controls do not establish a live Marketplace offer or managed connection.

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/marketplace

## In short

Plan the ownership boundaries of an AgentCore State add-on: obtaining the package, configuring a connection and granting access are separate tasks. Kam's source lifecycle controls cover bounded export, deletion and restore fencing; they do not imply a live purchasing or hosted setup flow.

**Available today:** Export, deletion and restore fences are implemented in source. No live Marketplace listing, managed connection or qualified customer subscription is offered.

> Evaluate the AgentCore State add-on with purchasing, connection and authority kept separate.

## Separate setup from permission

- **Obtain the candidate** — There is no live Marketplace listing or purchase flow.
- **Plan the connection** — Adding the package does not configure an AgentCore workload.
- **Authorize and plan exit** — Scope access explicitly and inspect the source export/deletion boundaries.

## Inspect readiness before sending data

The SDK candidate can discover bounded visible workspaces and inspect owner-only account and scope onboarding metadata. kam-history doctor is the read-only diagnostic; quickstart is the separate documented write path.

Account status distinguishes commercial observation, authorization freshness, lifecycle, and reconciliation health. A stale background check is neither cancellation nor permission to extend an expired grant. Effective deployed behavior remains a qualification requirement.

## A bounded export is implemented

An authorized owner closes outcome ingress, waits for the captured lifecycle boundary, then requests an export session. Preserve exportId, scope, page order, pageHash, and the opaque returned cursor. Check session completion before using the export to authorize deletion.

The export is a closed-ingress operational view, not one atomic database snapshot across all pages. Source changes and authority changes have explicit behavior. The current limits are 32 registered scopes, ten records per page, and 512 KiB of page JSON.

## Export, deletion, and restoration are different controls

Primary-state deletion and a separately retained restore fence are implemented. Simulated exact AgentCore erasure is distinct from a qualified live downstream deletion journey. Export success alone proves neither physical deletion nor backup erasure.

Live purchase, renewal, cancellation, grant-refresh outages, revocation timing, remote erasure, and backup restore drills remain separate qualification boundaries.

## The purchasing channel is still planned

There is no live listing or one-click activation yet. SDK publication, public distribution of the native toolkit, support and fulfillment, commercial terms, and live production qualification are not implied by source implementation. An evaluation request does not subscribe you or grant AWS access.

[Scope an evaluation](/evaluation)

[Read qualification limits](/reliability)

# Prove one outcome all the way to an exact read

Map one declared workload result into Kam History and read it back exactly. The SDK journey qualifies those stages, not AgentCore execution or Memory consumption.

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/golden-journey

## In short

Take one declared result from an AgentCore workload through acceptance, exact retry, pinned listing and exact readback. The SDK journey records evidence for each stage it performs. It does not invoke the agent or prove Memory delivery, model use or external completion.

**Available today:** The documented SDK harness requires an authorized evaluation endpoint. Source/package runs and a live AgentCore qualification are distinct.

> Trace one result from an AgentCore workload through State recording and exact reads. Verify execution and Memory delivery separately.

## Prove the recorded result, one stage at a time

- **Submit a declared outcome** — Use approved evidence from the workload; pending or unknown is not failure.
- **Keep the list pinned** — Carry generation and cursor through bounded History pages.
- **Read exact versions** — Check returned dispositions without claiming AgentCore or Memory consumption.

## 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. **Fetch exact 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 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](/#trajectory)

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

[Explore the native candidate](/developers)

# Inspect History in the console

Inspect authorized State History from an AgentCore workload through read-only workspace, scope, UTC-day and exact-revision navigation.

Status: Implemented in source. Prelaunch; not a live service guarantee.
Implemented in website source and tested against local fixtures. Live History access requires separately verified service configuration, identity and workspace authority. Those prerequisites are not established by a website deployment.

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

## In short

Inspect the State History an AgentCore application recorded. A signed-in operator chooses an authorized workspace, scope and UTC date, then reads exact revisions from a fixed list. The console is read-only and never replaces a requested old version with a newer one.

**Available today:** The website implementation is tested with local fixtures. Live History configuration, Cognito access and deployment qualification are separate requirements.

> Read the recorded State behind an AgentCore workload without changing it.

## Inspect an AgentCore workload's History

- **Choose workspace and scope** — Use the server-authorized workspace and supplied subject and type.
- **Pin UTC day and generation** — Keep membership fixed while reading more pages.
- **Inspect the exact revision** — Read retained data and source references; the console executes no agent or tool.

## Browse History like folders

1. **Workspaces** — The History API lists the workspaces your account may read, with your role.

2. **Scope** — Enter the subject and record type supplied for your authorized workspace. The console does not invent a scope directory.

3. **UTC days** — Pick a month, then select today or one of the preceding 364 UTC dates. A date in this window is eligible for reads; its presence does not mean that the day’s records are complete.

4. **Exact records** — One page of a pinned generation is hydrated to exactly those revisions; the inspector adds timestamps, source references, and the record’s earlier revisions.

## Sign in with your Kam account

The console uses the Cognito client’s configured Amplify sign-in flow. Server settings choose email or username; they do not grant workspace access. The server reads the session, re-verifies the Cognito access token with AWS’s verifier, and calls the History API on your behalf. Which workspaces you see comes from the History API, never from the browser; a refusal is shown as access denied, never worked around.

## What the console will not do

1. **Write anything** — Only read routes are called. There is no outcome, configuration, deletion, or lifecycle action.

2. **Fall back to latest** — A changed generation or a revision that does not match the requested reference is an error, not a substitution.

3. **Read without bounds** — At most 32 references per read, only inside the 365-UTC-date window, and never a cursor without its generation.

[Try the fixture inspector](/inspect)

[Read the History contract](/docs/history)

# Exact identity + versioned membership

Keep the exact versions and ordered History membership an AgentCore application needs separate from how each view displays them.

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/primitives

## In short

Give an AgentCore application exact references it can inspect later. allIds() fixes the ordered History membership; byIds() fetches precisely those retained revisions. The graph, timeline and comparison are views over those answers, without running the original agent or tool.

**Available today:** These methods implement the bounded History contract. General collections and arbitrary payload queries are not implied.

> Give an AgentCore application fixed History membership and exact retained versions.

## Two primitives beneath the workspace

- **allIds()** — Fix the ordered History references for the application's read.
- **byIds()** — Fetch exactly the retained revisions that membership names.
- **Views** — Use graph and timeline to inspect those answers without rerunning AgentCore work.

## allIds() fixes membership

A bounded day generation names ordered exact revision references. Preserve the returned generation and cursor while paging; a late arrival belongs to a successor generation rather than silently changing the collection being read.

The broader platform reuses this normalized-state idea, but the existing allIds() API keeps its exact History contract rather than becoming a generic dependency endpoint.

## byIds() hydrates exactly what was named

Hydration restores caller order and reports found, unresolved, unavailable and expired positions explicitly. It does not replace an unavailable historical revision with the latest value.

Stable identity plus immutable revisions makes a later diff inspectable: unchanged references can be structurally shared while changed membership becomes an explicit input to reconciliation.

## Exact reads depend on the contract

The value comes from the contract: stable logical identity, immutable revision identity, ordered bounded membership, generation pinning, correction rules, authorization, retention and recovery.

That foundation can support exact checkpoints, replay, State and Context profiling and turn-to-turn change explanations without making probabilistic retrieval the source of operational truth.

[Read State reconciliation](/docs/state)

[See the exact History example](/?capability=workflows#trajectory)

# Check what changed before every agent turn

Prepare and compare bounded State evidence around an AgentCore turn. Local Turn Frames do not intercept model calls or authorize external actions.

Status: Merged · local only. Prelaunch; not a live service guarantee.
The Linux x64 native toolkit qualifies reference-only local Turn Frames. Exact Context capture, manifest assembly, and a controlled request-boundary adapter also exist in source. Automatic runtime interception and managed AgentCore wiring remain planned. Model submission, completion, and business acceptance are not observed unless an injected boundary explicitly reports them.

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

## In short

Before your application starts another AgentCore turn, compare the State evidence that changed and prepare the next selection. Local Turn Frames make that preparation inspectable. The runtime performs model and tool calls; the application owns checks before consequential actions.

**Available today:** The native toolkit has a local reference-only candidate. No live AgentCore turn interception, model submission or managed Turn Receipt is established.

> Prepare the next State selection; let the AgentCore runtime execute the turn.

## Prepare State; keep execution explicit

- **Compare local Turn Frames** — Inspect the exact evidence prepared for adjacent reasoning turns.
- **Check applicability** — Required inputs and versions must still apply, and permissions must still be valid.
- **Execute in AgentCore** — Live interception and managed Turn Receipts are planned integrations that still require qualification.

## Resolve → detect → reconcile → assemble → reason → revalidate

1. **Resolve** — Start from exact retained evidence, View definitions, source versions, freshness and authority inputs.

2. **Detect** — Identify which exact identities or fences changed. Provenance change is not automatically semantic change.

3. **Reconcile** — Incremental view maintenance: propagate through declared dependencies and recompute only supported affected State, fencing stale work with version conditions.

4. **Assemble** — Assemble required reference evidence and bounded optional context into a separate model-facing representation.

5. **Reason** — Your agent hosted on AgentCore invokes the model. The runtime and application own execution; Kam retains the admitted State evidence.

6. **Revalidate** — The future action boundary checks the relevant ReadSet before consequential external effects.

## What the native toolkit actually proves

The native toolkit, merged in PR #176, can build a local record of one turn’s preparation, called a Turn Frame (format kam.local-turn-frame.v1). Each frame links to the previous one and pins the exact State, inputs and evaluation time it used, so two turns can be compared line by line.

To avoid overstating what happened, every prepared frame says so explicitly: modelRequestReady false, modelSubmission not_observed, turnReceipt not_committed, liveAuthorization not_checked and persisted false. The candidate is diagnostic infrastructure, not live runtime interception.

## Why did this turn rebuild?

The local profiler compares definition, membership, exact provenance, reported content hash, source fences, temporal inputs and selection disposition independently. Unsupported semantic sameness, provider cache hits and inferred decision causes remain not_observed.

The long-term developer-tools direction is change diagnostics for agent State: explain the source change, affected Views, reused evidence, rebuilt representation and logical versus physical retry work.

# Choose exact evidence for each agent

Prepare a versioned evidence selection for an AgentCore task. Capture, manifests and bounded assembly are separate from Memory recall and model submission.

Status: Implemented in source. Prelaunch; not a live service guarantee.
Evidence capture, versioned manifests, hide/restore and bounded assembly are implemented in source and locally tested with simulated storage. Public hosting, managed AgentCore wiring, automatic ranking, provider-token budgeting and live model-consumption qualification are not established.

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

## In short

Prepare the exact evidence for an AgentCore task separately from Memory recall. A versioned manifest selects retained inputs and how to represent them; bounded assembly checks required evidence and enforces item and byte limits. Your application controls submission to the model.

**Available today:** Capture, manifests, hide/restore and bounded assembly are implemented in source. Managed runtime wiring, automatic ranking and qualified live model use remain separate.

> Choose exact evidence for an AgentCore task while keeping recall and submission separate.

## Prepare evidence independently of recall

- **Keep required inputs** — Select the exact evidence your AgentCore task needs.
- **Bound optional inputs** — Name omitted or missing evidence and enforce item and byte limits.
- **Own the request boundary** — Your application submits the assembled representation; managed runtime interception is planned.

## Keep the evidence and its selection separate

Your application captures the bytes received at a controlled boundary. A consumer’s manifest names exact evidence and chooses full, descriptor or excluded representation. One captured record can appear differently in separate consumers’ selections.

A manifest is an ordered, numbered version. Hide and restore create another version; earlier retained manifests still name the evidence they selected. A source digest identifies the captured bytes. It does not verify the source’s accuracy or prove that a model consumed the evidence.

## Capture, select, assemble and inspect

1. **Capture exact bytes** — captureContextEvidence retains evidence under an immutable identity and digest. Changed evidence needs a new identity.

2. **Choose a versioned selection** — configureContextManifest selects up to 16 ordered entries. hideContextEvidence and restoreContextEvidence preserve prior retained selections.

3. **Check required evidence and limits** — assembleContext reads at most 32 exact keys, with a declared budget up to 16 items and 192 KiB. Unavailable or expired required evidence blocks assembly of a complete package.

4. **Inspect without hydrating payloads** — inspectContextManifest returns metadata for the exact selection. Assemble and inspect recheck authority after asynchronous reads before serving.

## Assembly is not proof that a model used it

The default response reports submission, invocation completion and business acceptance as not_observed. A controlled request adapter can report only the actual injected submission boundary; it does not intercept calls made elsewhere.

The item and byte budget describes captured evidence, not provider tokens or a complete prompt. Automatic ranking, learned compression, provider prompt caching and managed runtime wiring remain separate future integrations. No paid model is invoked by the local qualification.

# Recover recorded State alongside your workflow

Read recorded State again when an AgentCore application resumes work. Runtime continuation and Kam's durable reconciliation have separate owners.

Status: Internal implementation. Prelaunch; not a live service guarantee.
History and reconciliation durability exist in source. A named managed operational-checkpoint API, live Turn Journal, WakePlan and persisted Turn Receipt lifecycle remain staged.

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

## In short

When an AgentCore application resumes work, read the State it needs again and recheck whether it applies. Kam retains accepted revisions and its own reconciliation progress. Runtime continuation, tool retries and the decision to act stay with the runtime and application.

**Available today:** Source History and reconciliation recover their own progress; the explicit local SQLite host also recovers accepted work. Managed operational checkpoints remain planned.

> Resume your AgentCore workload and recheck the recorded State it needs.

## Rejoin execution with recorded State

- **Resume the workload** — Your AgentCore runtime and application own continuation and tool attempts.
- **Read and revalidate State** — Kam retains admitted versions and recovers its own reconciliation progress.
- **Stop on uncertainty** — Your application must verify unknown external effects and current permissions before deciding whether to retry.

## Two timelines should remain independent

Your AgentCore application owns how execution resumes. Kam preserves accepted State and advances supported reconciliation as recorded evidence changes. On the next turn, the application must read again and check whether a previous Observation still applies.

Keep workflow continuation in the runtime and application. Kam supplies exact State references and its own recorded processing progress; neither proves that an external tool action completed.

## Use exact references for checkpoints

The planned operational checkpoint is a durable coordinate across exact Snapshot or generation, View, Active State, Observation, source fences and computational versions. Immutable referenced objects can be structurally shared across many checkpoints.

Exact references make retained versions inspectable without copying every payload. Replay does not rerun tools, prove outside actions or remove retention limits.

## Durable reconciliation preserves processing progress

Affected-View discovery persists bounded progress and can redrive lost wakeups. Conditional commits recheck lifecycle, membership and source-State versions so delayed work cannot overwrite newer authority.

The future Turn layer should carry the same discipline into model submission and effects: explicit UNKNOWN outcomes, idempotent stage receipts, and revalidation instead of blind retries.