SG/Sentinel MVP Implementation Architecture: The sg sentinel Surface, The Three Targets, And The Signal Spine
Summary
The shortest path to understanding the system, and the document that carries the governing correction: Layer 1 never acts and never writes — it only decides and signals; Layer 2 is the sole actor and sole I/O owner. A CloudFront Function has no network and no filesystem, so it physically cannot write and by design must not enforce; blocking becomes a logged action with an enforcement side-effect. The brief fixes Schema__Sentinel__Signal as the byte-identical parity spine across three execution targets (local-direct, local-docker, live AWS), scopes the MVP to two use cases on a tiny core of six deterministic rules, places sg sentinel as a top-level peer surface composing the existing sg aws primitives, and makes the three-target parity matrix the definition of done.
Key concepts
- L1 decides + signals; L2 acts + writes — the load-bearing correction the whole MVP is built on
- The signal spine — Schema__Sentinel__Signal — one contract, byte-identical everywhere; only transport and sink swap
- The three targets — local Node, local Docker CF-env simulation, live AWS — same engine, asserted identical
- The parity matrix — identical signals, records and enforcement, or it's a P1
Key ideas
- Because L2 is a dumb actor, rules live in JS only — parity is about the envelope, not about re-running rule logic in two languages.
- The ephemeral test distribution runs cache-disabled (TTL 0) so origin-request Lambda@Edge sees literally every hit.
- Locked decisions are inherited verbatim by the implementing agent — the brief is also a decision record.
- Everything else in the design series is explicitly deferred; the point is to prove the spine on the smallest slice that delivers real value.
On this site
The backbone of the architecture page; the status language on the front page and roadmap follows its acceptance criteria.