SG/Sentinel MVP Implementation: File-By-File Plan, Schemas, And The Parity Test
Summary
The executable plan the MVP was built from: which files, which fields, which order, which tests — in six phases, each independently green, front-loading the offline use cases and deferring the riskiest piece (live Lambda@Edge) to last. It specifies the exact Type_Safe schemas, the single-file dependency-free L1 engine with the six rules inline, the L2 actor with privacy-mode hashing, the identical sink key layout across S3 and local FS, and the parity-matrix test with its canonical six-request set. The gotchas section records where the live target bites: no environment variables on Lambda@Edge, us-east-1 authoring, numbered versions, edgelambda trust, asynchronous replica deletion.
Key concepts
- The six build phases — skeleton → L1 engine → L2 + sinks + harness → docker → deploy path → live run + parity
- The canonical request set — six requests, expected verdicts and rules — the fixture every target must decide identically
- House conventions — Type_Safe everywhere; one boto3 seam per client; in-memory doubles; no mocks, no network in unit tests
- The gotchas — CloudFront Functions and Lambda@Edge constraints, recorded so they are not learned the hard way
Key ideas
- Signal transport refinement: drop base64 — the header value is raw compact JSON, since CF Functions JSON.stringify natively and JSON contains no CR/LF.
- The JS emits snake_case keys identical to the Python schema field names so the codec maps one-to-one.
- Parity comparison normalises non-deterministic fields (timestamps, AWS request ids) — the rule decision is what must match.
- "If you find yourself wanting to add a feature from the design series that isn't in this brief, stop: it is deferred by design."
On this site
The schemas and code on the architecture and rules pages are excerpted from what this brief specified and the snapshot confirms was built.