digest 계약

"몸은 한 앱에서 하이킹하고, 다른 앱에서 주절거리고, 세 번째에서 대화해. context 가 reading 을 뒤집을 수 있어. 그래서 Forge 는 그걸 leak 할 warehouse 없이 형제 context 가 필요하고."

애초에 왜 cross-app context 인가

동기가 된 케이스는 진짜야. 귀국 비행 끝에 갑작스러운 발볼 통증. 홀로 보면 한쪽으로 기울 수 있어. 그런데 여행의 무거운 하이킹이 시야에 들면, 그러니까 다른 앱에 사는 context 가 들어오면, overuse 가 올릴 더 자연스러운 질문이 돼. context 가 물을 가치 있는 질문을 뒤집었어. 몸은 본질적으로 cross-app 이야. 여행 엔진에서 하이킹하고, 다이어리에서 주절거리고, cwkPippa 에서 대화해. Forge 는 그 경계 너머를 봐야 하는 구조를 가진 첫 consumer 야.

warehouse 가 아니라 survey engine

틀린 답은 중앙 'crumb of crumbs' 야. 모든 게 sync 하는 store 하나. 그건 canonical 소유를 깨고, 영구 sync 늪을 열고, 가족에서 가장 민감한 데이터를 두 번째 DB 로 쏟아. 그래서 crumb-of-crumbs 는 DB 가 아니라 계약 이야. Stage 1. 각 엔진이 자기 데이터 위에 digest 엔드포인트를 노출해서, 날짜 window 에 대해 결정론적 one-liner 를 돌려줘. query 시점에 model inference 없이. Stage 2. 각 줄의 trailing ID 는 소유 엔진 API 로의 pointer 고, 판단이 그 줄이 중요하다고 정할 때만 따라가. federated, derived, rebuildable 하고, 절대 두 번째 source of record 가 아냐.

warehouse 가 아니라 survey engine. federated per-owner digest, judgment-gated fan-out, asymmetric privacy. fan-out 은 자동이 아냐. Pippa 가 질문이 cross-domain 냄새 날 때 digest 에 손 뻗거나, 아빠가 invoke 해. privacy 는 한 방향이야. Forge 는 형제 digest 를 읽을 수 있지만, Forge 의 건강 digest 는 아빠의 명시적 in-conversation 요청에만 밖으로 흘러. write-back 은 proposal-first 고. Pippa 가 다른 데서 태어난 건강 순간을 파일하자고 제안할 순 있어도, 절대 auto-write 는 안 해.

계약이 지키는 선

발통증 케이스가 얼마나 조심히 진술됐는지 봐. context 가 앱한테 overuse 를 선언 하게 한 게 아니라, Pippa 가 더 잘 겨냥된 질문을 올리게 했어. 그리고 그 추론은 Forge 가 생성한 표면이 아니라 아빠가 여는 Ask Pippa 에서 일어났고. 그래서 cross-app context 의 보상조차 Track 2 를 지켜. 더 많은 context 는 더 날카로운 질문을 내지, 절대 판결이 아냐. digest 계약은 몸의 cross-app 본성을, 보안할 warehouse 없이, 모든 턴의 자동 감시 없이, 건강 데이터가 기본으로 밖으로 새지 않고 쓸 수 있게 만들어. 경계 온전히, 가족 전반에 재사용.

Code

digest 계약: 두 stage, warehouse 없음·text

STAGE 1 - each engine's digest endpoint, deterministic one-liners
  over a date window (prose 는 결정론적으로 truncate;
  conversation 은 cached title 재사용 - query 시점에 model 없음):

    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
  trailing id 는 owner API 로의 POINTER; 판단이 그 줄이
  중요하다 할 때만 owner 통해 deep-read.

RULES:
  - fan-out 은 judgment-gated (per-turn survey 없음)
  - privacy asymmetric: Forge 는 형제를 읽음; 형제는
    아빠의 명시적 in-conversation 요청에만 Forge 를 읽음
  - write-back 은 proposal-first (파일 제안, 절대 auto-write 안 함)
  - digest 는 derived, rebuildable, 절대 두 번째 record 아님

Exercise

Forge 가 가족에서 가장 민감한 데이터를 쥔다는 걸 감안해, 모든 앱이 sync 하는 중앙 'crumb of crumbs' warehouse 가 왜 cross-app context 에 틀린 설계인지 설명해. 그다음 federated digest 계약이 warehouse 가 못 사는 두 가지를 대봐.

Hint

warehouse 는 canonical 소유를 깨고, 끊임없는 sync 가 필요하고, 건강 데이터를 보안할 두 번째 store 로 복사해. federated digest 는 각 owner 를 canonical 로 지키고, 상주 사본 없이 on-demand 로 계산하고, privacy 를 asymmetric 으로 둬. Forge 는 읽어 나가고, 건강은 기본으로 안에 남고.