# SG/Sentinel Future Research And The Path To MVP

**version** v0.27.58
**date** 18 May 2026
**from** Human (project lead)
**to** Architect, Developer (lead), Security, @Dev
**type** Planning brief

---

## What This Is

The forward-looking companion to the consolidated addendum. Where that document captured what is settled (prior art, observations, gap resolutions), this one captures **what is deliberately parked for later, the memos worth recording to fill thinking-gaps, the prior-art deep-dives worth doing, and the recommended scope for the first MVP.**

The decision driving this document: **we have enough design to focus next on building the first MVP.** The SG/Sentinel series (fourteen briefs plus three tabletop/spec documents plus the addendum) is a comprehensive design. Further design has diminishing returns until the MVP surfaces real-world learning. This document marks the boundary: here is what we build first, here is what we defer, here is what to record when the thinking is ready.

## Part 1: Memos Worth Recording

Topics the series gestures at but has not actually captured in the project lead's own framing. These are thinking-gaps, not writing-gaps; they want to be recorded as voice memos rather than invented, because they involve genuine decisions only the project lead can make.

| Memo | Why It Matters | Priority |
|------|----------------|----------|
| **The fast-track redesign** | The tabletop fundamentally changed what fast-track means (zero-trust acceleration, never authorisation-skipping). This reconception deserves the project lead's own framing, not a retrofit. The single most important memo. | High |
| **Incident response and the after-block lifecycle** | The whole series is about detecting and blocking; almost nothing covers what happens after: investigation, false-positive unblocking, escalation to a human, the analyst workflow. The operational-response loop is missing. | High |
| **Failure modes and resilience** | Sentinel sits in front of everything; its own failure is existential. Fail-open vs fail-closed is an open question never thought through. What happens when Sentinel itself breaks? | High |
| **Product vs internal tool** | Is Sentinel internal infrastructure or an eventual product? This shapes multi-tenancy, per-customer rule isolation, pricing. The compliance brief hinted at business value but never settled this. | Medium |
| **The concrete cost model** | Cost is the founding motivation (Firehose/WAF expensive), but no doc models what Sentinel actually costs to run per-request per-layer. Closing this loop validates the founding argument. | Medium |
| **Rule retirement discipline** | The DaC lesson: the library is living infrastructure, not a trophy cabinet. How do rules get retired, and when is a control better than a rule? | Medium |
| **The unified graph** | The addendum proposes the three graphs are one. Worth a memo confirming the data model direction before the MVP commits to it. | Medium |

The fast-track memo is the most valuable to record before MVP coding, because the reconception is architectural and the MVP's identity/fast-track design depends on it.

## Part 2: Prior-Art Deep-Dives Worth Doing

The addendum surfaced three bodies of prior art. Each warrants a focused deep-dive before or during MVP, to extract concrete implementation lessons rather than just positioning.

| Deep-Dive | What To Extract |
|-----------|-----------------|
| **OPA / Rego architecture** | The PDP/PEP split in detail; how OPA bundles and distributes policy; how it handles decision logging; whether any of it is directly reusable or purely a reference |
| **Sigma / pySigma compile pipeline** | The compile-to-backend mechanism; how to express a canonical rule format that compiles to CloudFront Functions, Cloudflare Workers, etc.; the rule-testing-against-sample-logs harness |
| **Coraza integration** | From the earlier research brief: whether Coraza can be the CRS-compatible engine for deterministic rules while our native engine handles app-coupled and LLM rules; the integration surface |
| **Deception technology patterns** | Honeytoken placement strategy; how to make decoy assets production-real; how trust-revocation-on-touch is wired; the false-positive characteristics |
| **Zero-trust / BeyondCorp** | The continuous-verification model; how identity is established and re-verified; the context-aware policy model that fast-track should follow |

These are research tasks for the implementation phase, not blockers for starting the MVP. The MVP can begin with the easy wins while these deep-dives inform the harder layers.

## Part 3: What Is Deliberately Parked

To keep the MVP focused, these are explicitly deferred. They are good ideas; they are not the first slice.

| Parked | Why Deferred |
|--------|--------------|
| The unified semantic graph (full build) | The data model should assume one graph, but building the full evidence/compliance/rule graph is post-MVP |
| The compliance-as-living-graph feature | High business value, but not needed to prove the core works |
| The LLM-interpretation layer (Layer 3 full) | The hook exists in the MVP; the full async LLM analysis is post-MVP |
| Multi-CDN (Cloudflare, Fastly) | CloudFront first; the compile-to-backend model is designed for but not built |
| The full deception layer | Honeytokens resolve a real gap, but the full deception environment is post-MVP; a single honeytoken-touch-revokes-fast-track is the minimal version |
| The "what do you know about me?" full feature | Dev-only debugging version in the MVP; the user-facing privacy version is later |
| Vault-per-user evidence at scale | The evidence graph keys on fingerprint in the MVP; per-user vaults at scale are later |
| SSL termination | Explicitly later, per the execution-model brief |
| Standards-as-vaults / compliance graphs | Post-MVP; the compliance brief's vision |
| Rule retirement automation | The discipline is noted; the automation is post-MVP |

Parking these is not abandoning them; it is sequencing. The MVP proves the core; these build on a proven core.

## Part 4: The Recommended First MVP

Pulling the MVP brief, the architecture brief, the mockups, and the tabletop together, the recommended first MVP scope. This is the minimal end-to-end slice that proves the architecture and delivers immediate value (the real-time visibility the project lead wants now).

### MVP Scope: The Core Slice

| Component | MVP Scope |
|-----------|-----------|
| **Layer 1 (CloudFront Function)** | Logging (every hit, clean, to S3) + easy-win blocks (banned IPs, /etc/passwd, WordPress-on-static, /.env, obvious-bad) |
| **Layer 2 (Lambda@Edge)** | Known-good-profile validation (the no-invalid-request core) for one or two real endpoints; observe-mode first |
| **Layer 3 (async)** | The hook only: a stub that receives flagged events; full analysis is post-MVP |
| **S3 logging** | The first use case: real-time, clean logs to S3, replacing Firehose; existing code consumes |
| **Blocking** | The second use case: easy-win deterministic blocks with reasons logged |
| **The fingerprint** | Specified and built as a first-class object (signed-token-based, per the resolution) |
| **Deployment** | CLI create/destroy/teardown; extends existing SG/Compute CloudFront plumbing |
| **TUI** | The four priority surfaces: live traffic, blocks, logs+S3, rules (the mockups) |
| **TUI API** | Chatbot-friendly from the start (the TUI API foundation) |
| **Rule engine** | The tiny core + deterministic rules; the fractal graph; rules-as-vault; the rich metadata schema |
| **Dev environment** | Local-everywhere (lambda-as-container); dev/main/prod phases; deploy parity |

### What The MVP Proves

The MVP proves the architecture works end to end on the two first use cases:

1. **Real-time visibility** (the founding pain): logs flow cleanly to S3 in real time, visible in the TUI, replacing the expensive Firehose pipeline.
2. **Blocking obvious-bad** (the founding security need): the easy-win deterministic rules block the obvious attacks, with reasons logged.
3. **The core principles hold**: no-invalid-request (for the validated endpoints), the tiny-core-engine, rules-as-everything, local-everywhere, deploy-parity.
4. **The debugging goals are met**: clone traffic, too-many-requests, mobile load (the MVP brief's acceptance test).

### What The MVP Defers (Per Part 3)

The full Layer 3 LLM analysis, the unified graph, compliance, multi-CDN, full deception, the user-facing privacy feature. The MVP leaves hooks for these but does not build them.

### The MVP Sequence

A suggested build order:

1. **Layer 1 logging to S3** (the first use case; immediate value; lowest risk).
2. **The TUI live-traffic and logs surfaces** (the visibility the project lead wants now).
3. **Layer 1 easy-win blocks** (the second use case; high-value, low-risk).
4. **The TUI blocks surface**.
5. **The fingerprint object** (foundational for everything that follows).
6. **The rule engine core + fractal graph + rules-as-vault** (the structural foundation).
7. **The TUI rules surface + TUI API chatbot-friendliness**.
8. **Layer 2 known-good validation** (observe-mode first) **for one or two endpoints**.
9. **Deployment CLI + local-everywhere + phases**.
10. **The Layer 3 hook** (stub for post-MVP).

This sequence front-loads the immediate value (visibility, then blocking) and builds the foundation (fingerprint, rule engine) before the harder layer (Layer 2 validation).

## Part 5: The Gaps That Must Be Resolved Before Their Dependent MVP Steps

From the tabletop, the gaps that gate specific MVP steps:

| MVP Step | Gated By | Resolution (from the addendum) |
|----------|----------|--------------------------------|
| The fingerprint object (step 5) | GAP 2.1/9.1/9.2 | Signed-token, zero-trust acceleration, authorisation always enforced |
| Layer 2 validation (step 8) | GAP 5.1/5.2 | Known-good profile as a deploy artefact; observe-mode first |
| Blocking (step 3) | GAP 6.1 | Block actions defined at HTTP level |
| Logging (step 1) | GAP 1.1/3.1 | Log-finalisation owner; IP-escrow mode |

These resolutions are in the addendum; they should be applied as the corresponding MVP steps are built. The fast-track memo (Part 1) should be recorded before step 5.

## Part 6: Definition Of Done For The First MVP

The MVP is done when:

1. Real-time logs flow to S3, cleanly formatted, replacing Firehose, visible in the TUI.
2. Easy-win deterministic blocks work, with reasons logged.
3. The fingerprint object exists, signed-token-based.
4. The rule engine core runs the fractal rule graph; rules are a versioned vault.
5. Layer 2 validates one or two endpoints against a known-good profile (observe-mode proven, then enforce).
6. The four TUI surfaces work and are chatbot-friendly.
7. Deployment (create/destroy/teardown) works via CLI; local-everywhere holds; deploy-parity verified.
8. The debugging goals are met (clone traffic, too-many-requests, mobile load visible).
9. The Layer 3 hook exists for post-MVP.
10. The cost is measured and lower than the Firehose + WAF baseline.

When these hold, the architecture is proven, the founding pain is addressed, and the post-MVP work (Layer 3 LLM, the unified graph, compliance, deception, multi-CDN) builds on a working core.

## What This Document Establishes

The design phase is sufficient; the next focus is the MVP. This document marks the boundary: the memos to record (fast-track first), the prior-art deep-dives to do during implementation, what is parked, and the recommended MVP scope, sequence, and definition of done. **We have enough to build.**

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 18 May | `v0.27.58__addendum__sg-sentinel-prior-art-observations-gap-resolutions.md` | The settled companion; this is the forward-looking one |
| 18 May | `v0.27.58__dev-brief__edge-layer-mvp-visibility-blocking-deployment.md` | The MVP this scopes concretely |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-architecture-and-data-flows.md` | The architecture the MVP implements |
| 18 May | `v0.27.58__dev-brief__sg-sentinel-tui-mockups.md` | The TUI surfaces the MVP builds |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-tabletop-simulation-2-blocking.md` | The gaps that gate MVP steps |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-rules-of-the-game-behavioural-spec.md` | The behavioural spec (with resolutions applied) the MVP tests against |

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).