SG/Sentinel Architecture And Data Flows: How It All Fits Together

Summary

The component map and the two founding use cases, end to end. Logging: Layer 1 captures every hit, the data is cleaned and structured, and Sentinel's job ends when the record lands in S3 — existing downstream code picks up from there, a deliberately tight boundary. Blocking: easy wins deterministic at Layer 1, app-coupled validation at Layer 2, async feedback from Layer 3 updating the fast layers. Together with the TUI mockups it was written to be the acceptance criteria the dev team implements against.

Key concepts

• The component map — layers, S3, evidence, rule-set, TUI, CLI — the full picture the MVP narrowed
• Sentinel's logging ends at S3 — the boundary that kept use case 1 scoped and achievable
• Two use cases as the proving slice — logging and blocking exercise the core of everything

Key ideas

• The two use cases were chosen because they are the minimal end-to-end slice that proves the architecture.
• Every block has a logged reason — an acceptance criterion here, a schema field in the built system.
• The honest risks section flags scope creep as a named enemy of the MVP.

On this site

The architecture page is this document plus the v0.27.59 correction (L1 no longer blocks inline — it signals).

Read the document