SG/Sentinel Tabletop Simulation Part 1: Generic Flows And Logging

Summary

Five simulated requests — a static-page happy path, a returning fast-tracked user, a privacy-mode logging request, a cache hit, a freshly-deployed page the profile doesn't know yet — traced layer by layer against the behavioural spec, honestly: eleven gaps found, two major. GAP 2.1 exposed that Layer 1 (no I/O) cannot check a dynamic fingerprint allowlist, pointing at signed-token fast-track; GAP 5.1 showed the symmetry principle blocking legitimate deploys, forcing the known-good profile to become an atomically-deployed artefact with observe-mode first.

Key concepts

• The tabletop method — requests traced on paper, gaps flagged with proposed resolutions, before any code
• The fingerprint storage gap — GAP 2.1 — the finding that moved fast-track to a signed token
• IP escrow — GAP 3.1 — "IP logging off" is too binary; capture-but-encrypt is the designed mode

Key ideas

• The log-finalisation owner (who writes the record, when) only became a question when a request was actually traced — exactly what the exercise is for.
• Cache-hit traffic sees only Layer 1, so Layer 1 must suffice for cached static content — a cache-policy-meets-security-policy coupling.
• Evidence-graph keying and anonymity mode must be designed together.

On this site

First half of the 25 gaps on the research page; GAP 1.1's log-finalisation answer became "L2 writes the record" in the MVP.

Read the document