C.W.K.
Stream
Lesson 04 of 05 · published

The Digest Contract

~11 min · cross-app, digest, federation, asymmetric-privacy

Level 0Cold Iron
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"The body hikes in one app, mumbles in another, and talks in a third. Context can flip a reading — so Forge needs sibling context without a warehouse to leak it."

Why Cross-App Context at All

The motivating case is a real one: at the end of a return flight, a sudden forefoot ache. In isolation it might lean one way. But with the trip's heavy hiking in view — context that lives in a different app — overuse becomes the more natural question to raise. Context flipped which question was worth asking. The body is inherently cross-app: it hikes in the travel engine, mumbles in the diary, and converses in cwkPippa. Forge is the first consumer that structurally needs to see across those boundaries.

A Survey Engine, Not a Warehouse

The wrong answer is a central "crumb of crumbs" — one store everything syncs into. That would break canonical ownership, open a permanent sync swamp, and pour the most sensitive data in the family into a second database. So the crumb-of-crumbs is a contract, not a DB. Stage one: each engine exposes a digest endpoint over its own data, returning deterministic one-liners for a date window — no model inference at query time. Stage two: the trailing ID on each line is a pointer into the owning engine's API, followed only when judgment decides that line matters. Federated, derived, and rebuildable — never a second source of record.

A survey engine, not a warehouse: federated per-owner digests, judgment-gated fan-out, asymmetric privacy. Fan-out is not automatic — Pippa reaches for the digest when a question smells cross-domain, or Dad invokes it. Privacy is one-way: Forge may read sibling digests, but Forge's health digests flow outward only on Dad's explicit in-conversation request. Write-back is proposal-first — Pippa may offer to file a health moment born elsewhere, never auto-write it.

The Line the Contract Protects

Notice how carefully the foot-pain case is stated. Context did not let the app declare overuse; it let Pippa raise a better-aimed question — and that reasoning happened in Dad-initiated Ask Pippa, not a Forge-generated surface. So even the payoff of cross-app context obeys Track 2: more context yields a sharper question, never a verdict. The digest contract makes the body's cross-app nature usable without a warehouse to secure, without automatic surveillance of every turn, and without health data leaking outward by default. Reuse across the family, with the boundary intact.

Code

The digest contract: two stages, no warehouse·text
STAGE 1 - each engine's digest endpoint, deterministic one-liners
  over a date window (prose truncates deterministically;
  conversations reuse cached titles - no model at query time):

    2026-07-15 | waystone | crumb | hiking First->Bachalpsee 4h | ws:01J8..
    2026-07-17 | pippa    | conv  | forefoot pain consult        | conv:a3f2..

STAGE 2 - follow the thread
  the trailing id is a POINTER into the owner's API; deep-read
  through the owner only when judgment says the line matters.

RULES:
  - fan-out is judgment-gated (no per-turn survey)
  - privacy asymmetric: Forge reads siblings; siblings read Forge
    only on Dad's explicit in-conversation request
  - write-back is proposal-first (offer to file, never auto-write)
  - the digest is derived, rebuildable, never a second record

External links

Exercise

Given that Forge holds the most sensitive data in the family, explain why a central 'crumb of crumbs' warehouse that every app syncs into is the wrong design for cross-app context. Then name two things the federated digest contract buys that the warehouse cannot.
Hint
A warehouse breaks canonical ownership, needs constant sync, and copies health data into a second store to secure. The federated digest keeps each owner canonical, computes on demand with no standing copy, and lets privacy stay asymmetric — Forge reads out, health stays in by default.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.