First-party case study · Built and operated by Kam AI
Start a timer without signing up. Keep the history in your browser. Choose an account when you need to save it across devices.
The problem
We built Fasting Free to make a small state problem tangible: the timer is simple, but the history still needs to survive reloads, retries, corrections, and account changes.
The display counts time locally. Start, end, and edit actions change records; the ticking timer does not send a write every second.
Fasting Free
Save a session ID and start time locally. A page reload reconstructs the timer from that timestamp.
User · Cognito · application
Sign in, enable cloud storage, and explicitly import the browser history. Login alone does not upload it.
Application adapter · Kam Rust
The adapter validates the request and invokes the pinned kernel with an exact-revision reference and content fingerprint.
Fasting Free API · DynamoDB
Conditionally write the state and retry receipt together. Kernel admission is not itself a completed database write.
Fasting Free
Confirm the imported records through a separate read. Only then clear the unchanged guest copy.
The backend runs an unmodified, hash-pinned evaluateState executable. The adapter supplies a bounded observation and verifies the returned tenant identity, snapshot revision, generation, and content fingerprint before committing.
The application owns timer rules, local storage, pending writes, account authorization, import, conflict handling, rolling summaries, and the DynamoDB transaction. Cognito handles authentication; SES delivers account emails.
This app reuses Kam’s Rust kernel. It does not use the hosted Kam History service, run agents on Amazon Bedrock AgentCore, or send fasting records to an AI model.
The app keeps ordered session IDs in allIds and session records in byId. Each record has a revision. These are application data structures, not calls to Kam’s generation-pinned History allIds()/byIds() API.
Current snapshots, record revisions, deletion markers, and short-lived retry receipts are implemented. This app is not a full immutable History browser.
Keep the pending operation and retry with the same mutation ID. A retained receipt identifies the duplicate; it does not add another session.
Reject the stale expected revision. Preserve unconfirmed local work for review instead of silently replacing the newer record.
A deletion marker rejects the old create. Clearing cloud history changes the reset generation, so an earlier queue cannot restore it.
Source tests cover timer rules, retries, import, and revision conflicts. Browser tests use synthetic data. Separate disposable-account API checks exercise cloud persistence and account isolation.
Real-inbox verification through the complete signup-to-import journey remains an outstanding acceptance check. These checks are not a published uptime, latency, cost, or customer-adoption benchmark.
Up to 500 sessions per account; summaries show 7, 30, or 90 days. A summary window does not delete older records. Browser storage can be cleared and is not a guaranteed backup.
Guest history stays on the device until import is chosen. Marketing email is a separate opt-in; fasting records are not used in that marketing export.
For AgentCore builders, the useful pattern is the responsibility split: your application supplies meaning and identity; admission checks a proposed state; a conditional commit makes the write authoritative. Agent execution is outside this example.
Reviewed implementation: bf889148
Kam kernel source: 99bac97f
One application. One workflow.
Bring a correction or retry. Agree the scope, evidence, and success check before starting.