Outcome workflow
How Backend Data Becomes a Better Outcome
8 min read
Kam AI
Product and research
5th Grade Summary
Kam AI should not write a blog from a blank page, and it should not sell itself as cheaper generic AI.
It should start with the same safe backend answer object that powers chat.
That object says what Kam checked, how fresh the sources are, what evidence was used, what is still uncertain, and what the user can do next.
The blog turns that receipt into a clear lesson about outcomes.
That is the moat: Kam does not only answer a question. It teaches users how a better read can become a better decision loop.
The simple architecture
The backend should produce a safe article input:
Kam AI turn envelope
-> validated source context
-> freshness and caveat
-> public receipt
-> structured blog blocks
-> MDX article page
React Native and web should both trust the same contract.
React Native uses it to render chat, saved reads, source receipts, and workspace actions.
Next.js uses it to render articles that explain how Kam works, why the read matters, and what outcome the user can get from the workspace.
That outcome is process quality: understand faster, avoid stale confidence, save the reason, and review the decision later.
Blog primitive contract
What every generated Kam article should prove
Visible
Source basis
The reader can see what kind of context powered the article.
Explicit
Freshness
Stale or missing data must be shown before confidence.
Required
Caveat
The article should teach limits, not hide them.
Actionable
Outcome
Track, save, compare, open receipts, review, wait, or pass.
0
Raw debug data
No public article should leak trace payloads.
Typed
Reusable blocks
The article uses React primitives instead of arbitrary HTML.
Takeaway: The blog should look rich because the backend object is rich, and the reader should leave with a clearer next step.
What this unlocks
This lets Kam publish educational articles from real product behavior:
- how a line move becomes a saved read
- how a prediction-market signal should be used carefully
- how freshness changes confidence
- how a user can track a spot instead of chasing action
- how postgame review improves the next read
The blog becomes a teaching surface for the workspace.
The user sees the outcome Kam can achieve before they ever open a dense workflow: a faster path to a grounded read and a cleaner way to learn from the result.
Next action
For production generation, the backend should send a validated article source pack, not a finished HTML page.
The web app should map that source pack into primitives.
Then the weekly blog eval should decide whether the draft teaches the outcome clearly enough to publish.
Research question
How does Kam turn backend data into a better outcome?
It takes the same safe answer envelope used by chat, removes raw internals, and renders the parts a user can act on: evidence, freshness, caveats, sources, next actions, and review receipts.
Kam AI backend signal
What the article is allowed to teach from
3
Evidence items
Facts or context objects loaded before prose.
3
Source refs
Named sources the reader can understand.
3/3
Fresh sources
Fresh or delayed source states.
3
Next actions
Workspace outcomes, not generic CTAs.
1
Memory cards
Only surfaced when the turn used memory.
0
Raw traces
Public article blocks do not render debug data.
Takeaway: The moat is the reusable receipt: the same backend answer can teach, guide, and be reviewed.
The Kam Read becomes the thesis
Backend read: Kam checked materialized read models, source freshness, and workspace context before turning the answer into a reviewable next step.
Reader value: the blog should slow this down into a repeatable method. It should show what the system checked, what is still missing, and what outcome the workspace makes easier.
How the backend data maps to article confidence
Freshness state
Fresh
Evidence coverage
3 evidence objects
Source visibility
3 source refs
Action clarity
Track the spot, Save the read, Open source receipts
Takeaway: The article earns the polished look after the backend proves what can be shown.
Backend data to article primitive
- Backend field
- route and profile
- Blog primitive
- Source receipt
- Why the reader cares
- Shows what kind of answer this was
- Backend field
- evidence
- Blog primitive
- Stats, table, cards
- Why the reader cares
- Turns raw context into teachable proof
- Backend field
- freshnessState
- Blog primitive
- Callout and confidence bar
- Why the reader cares
- Prevents stale confidence
- Backend field
- nextActions
- Blog primitive
- Workspace outcome list
- Why the reader cares
- Teaches what Kam helps users do next
- Backend field
- traceReceipt
- Blog primitive
- Trust receipt
- Why the reader cares
- Makes review possible without exposing internals
Takeaway: The UI primitive is the moat because it turns backend structure into repeatable user education.
The outcome loops the article should teach
Track the spot
This becomes a concrete user outcome in the workspace: track the spot, save the read, compare context, open receipts, or review the result later.
Save the read
This becomes a concrete user outcome in the workspace: track the spot, save the read, compare context, open receipts, or review the result later.
Open source receipts
This becomes a concrete user outcome in the workspace: track the spot, save the read, compare context, open receipts, or review the result later.
Takeaway: Good Kam content should make the next useful product action obvious without sounding like a pick feed.
Read next