SG/Sentinel Delegation And Choke-Points: Designing Code To Run Behind The Gate
Summary
The deeper continuation of the codebase-extension brief: concentrate checks at the choke-points between trust zones instead of validating everywhere defensively; design application code knowing it runs behind Sentinel so it can delegate validation and authorisation to it; and treat any behavioural difference between QA and production as a major bug (deploy parity). The "no 404s at the API layer" signal turns the layered architecture into a self-checking system: an error deep in the stack that the gate should have caught is information about where the security model has a gap.
Key concepts
- Deploy parity — the P1 invariant, realised in the MVP as the parity matrix
- Choke-points — the checks concentrate where trust zones meet; Sentinel is the outermost
- No 404s at the API layer — deep-layer errors as signals of shallow-layer gaps
Key ideas
- Same-code-everywhere is the killer feature: the rule tested locally is byte-for-byte the rule in production, so deployment holds no surprises.
- Every request becomes a way to make the system better — checks migrate to their correct altitude as errors reveal misplacement.
- Progressive lock-down: start permissive, observe, tighten to minimal as the valid profile is learned.
On this site
Deploy parity became the parity matrix; the L1 engine being byte-identical across targets is this brief's same-code principle, moved to JS by the CloudFront constraint.