Designed on paper, broken on paper, then prototyped

SG/Sentinel's design is day 68 of an iterative brief series: 19 design briefs dated 18 May 2026, followed by the two implementation briefs on 23 May — each one a voice memo turned into a decision record. Before any code, the design was pressure-tested with tabletop simulations — requests traced through the paper architecture — which surfaced 25 gaps, seven of them major. The gaps were resolved in a consolidated addendum, and only then did the prototype exercise start. The method is part of the system — and the design, not the prototype, is what this site publishes: SG/Sentinel itself has not been built.

The shape of the series

The tabletop: 25 gaps before a line of code

Eleven simulated requests — happy paths, cache hits, probes, brute force, a fast-tracked user turning malicious, an in-profile exploit — were traced layer by layer against the behavioural spec, and every place the paper behaviour was unclear, contradictory or wrong was flagged as a numbered GAP with a proposed resolution. Part 1 (generic flows and logging) found 11; part 2 (blocking) found 14, seven major. Three of the stories are worth telling in full:

Fast-track had to be redesigned as zero-trust acceleration

The original design fast-tracked known-good fingerprints past the checks. Simulation 9 played a fast-tracked user whose session turns malicious — requesting an admin endpoint, then someone else's vault — and the naive spec fast-tracked the attack, because the user was on the allowlist. The resolution rewrote what fast-track means: it is never authorisation-skipping. Identity-verified users skip only the expensive identity-establishment cost, carried in a signed token L1 can validate without a lookup; authorisation is always enforced, per user; and trust is continuously re-verified. Fast-track became zero-trust acceleration — a BeyondCorp idea arrived at by breaking the design on paper.

Honeytokens became the intent signal

The follow-on gap: even a correctly-authorised, identity-verified session can be compromised — IAM verifies identity, it cannot confirm intent. The resolution came from deception technology: place decoy endpoints no legitimate flow ever touches. A fast-tracked fingerprint touching a honeytoken is a near-zero-false-positive compromise signal, and revokes fast-track instantly, at machine speed. The design's existing "wild goose chase" instinct turned out to be an established discipline with a mechanism that closed a real hole.

Per-IP keying died against residential proxies

Simulation 8 brute-forced a login endpoint — valid endpoint, valid request shapes, so no-invalid-request never fires. Per-IP rate limiting looked like the answer until the research brief's finding landed: roughly 4 in 10 attacking IPs are now residential or compromised home connections, so 50 attempts from 50 IPs never trips a per-source limit. The resolution: rate-limit per target (the account receiving the attempts) as well as per source, and key evidence multi-dimensionally — source, target, behavioural signature. IP reputation was demoted permanently to context, never verdict. The same simulation also surfaced a coupling requirement: Sentinel cannot see whether a login succeeded, so the application must report auth outcomes back to it — app-coupling working in reverse.

And one confirmation

Simulation 10 — a slow, patient probe from rotating IPs, one unusual request every ten minutes — is the case rate-based detection cannot catch. The allowlist doesn't care: every out-of-profile request is blocked individually, regardless of rate or rotation. The attacker can probe forever and map nothing. The tabletop's one "positive finding": no-invalid-request beats slow distributed probing by construction.

Prior art: positioned, not reinvented

A fresh research pass after the tabletop found that the design had independently converged on several established disciplines — reassuring, and useful, because each had lessons to take:

One boundary was drawn deliberately: no malware or file-hash scanning at the Sentinel layers — the zero-knowledge architecture means Sentinel never has file contents, so it does traffic, IP and behavioural intelligence only. Not a limitation to apologise for; a consequence of a core platform value.

Five cross-cutting observations

• The three graphs are one graph. The evidence graph, the compliance graph and the rule graph share nodes (a rule prevents an attack technique, satisfies a compliance requirement, is observed as evidence). The data model assumes one typed semantic graph from the start.
• Replay-from-S3 is the test corpus. Production traffic in the sink doubles as the regression corpus for new rules — "would this rule have blocked anything legitimate last week?"
• Sentinel guards its own control plane. The admin/API surface sits behind the same rule discipline as everything it protects.
• Rule retirement is real work. The library is living infrastructure, not a trophy cabinet; rules that never fire, or that a control covers better, get retired.
• The fingerprint is the spine of everything deferred — fast-track, trust revocation, evidence keying — which is why it is parked as a first-class object rather than half-built.

Why publish the method

The gaps were found on paper, not in production — that is the entire value of the exercise, and the reason the intermediate documents are published rather than summarised away. Every claim on this site traces to a brief in the documents section, captured verbatim with the raw markdown as the source of truth.