Data
Owner, freshness, privacy, dependency shape, authorization, failure behavior.
Quick reference · Print-friendly
Clarify, partition, assign policies, expose risks, verify.
| Move | Say or draw | What it proves |
|---|---|---|
| 1 · Clarify | Journeys, freshness, privacy, SEO, devices, traffic, failure tolerance | You design from constraints, not fashion |
| 2 · Partition | Stable/volatile, public/private, critical/optional, static/interactive | You see hybrid seams |
| 3 · Assign | Generation, cache, delivery/reveal, client execution | You do not collapse independent axes |
| 4 · Defend | Keys, invalidation, serialization, status, fallbacks, authorization | You understand correctness and operations |
| 5 · Verify | Field cohort, trace, budget, experiment, guardrails, rollback | You close with evidence |
Owner, freshness, privacy, dependency shape, authorization, failure behavior.
Key, TTL, invalidation event, stale window, scope, stampede control.
Shell, stream boundaries, fallback geometry, status commitment, abort.
Entry points, transitive graph, hydration/resume, state channel, no-JS path.
Field segment, Web Vitals path, cache/origin spans, errors, cost.
Canary, feature flag, correctness tests, alert, rollback threshold.
“Given these assumptions, I’d partition the page by freshness, privacy, criticality, and interaction. Each region gets an explicit generation, cache, delivery, and client-execution policy. The largest risks are X and Y. I’d validate them with Z field segment and correlated traces, ship behind a canary, and roll back if the correctness or latency guardrail moves.”