# SG/Sentinel Interactivity And Deployment Phases: Two-Way Layer Invocation, Local-Everywhere, And Dev/Main/Prod Rules

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

---

## What This Is

The fifth brief in the SG/Sentinel security-tools series, capturing the interactivity model between the development environment and the running Sentinel, and the deployment-phase model that governs which rules run where. The central reframe: **SG/Sentinel is not a spectator sport.** It is not a fixed thing you deploy and watch; it is a set of layers you can converse with, invoke individually, trigger in sequence, run locally, test exhaustively, and develop against interactively.

Several interlocking ideas travel together here:

- **Two-way conversation with every layer**: each of Sentinel's layers is individually invocable and can be triggered in sequence from the front gate
- **The whole solution runs locally**: the same code runs in local Python, in containers, in inefficient-lambda-as-container form, and in full deployment
- **Dangerous dev-only rules**: rules too powerful or risky for production but invaluable in development (e.g. a rule that enables/disables other rules)
- **Minimal bundles**: never ship a rule to a live server that is not being invoked; the deployed code is tight and condensed
- **The dev/main/prod phase model**: rules have deployment phases; experiment in dev, lock down in main (which equals QA), and main equals production
- **The value-equation inversion**: security stops being a bolted-on thing that breaks stuff and gets its teeth removed, and becomes part of the application that the application controls

This brief covers all of these because they form one coherent model: **SG/Sentinel is developed interactively, runs everywhere identically, and promotes rules through deployment phases with first-class workflow discipline.**

## The Value-Equation Inversion

Worth starting with the framing the voice memo built toward, because it motivates everything else. **The traditional security-tool value equation is broken, and SG/Sentinel inverts it.**

The traditional pattern: a WAF or security layer gets bolted on at the end. It does not understand the application. It tries to find bad things using generic logic. It breaks legitimate functionality. The team responds by weakening it, setting rules to report-only, to `*.*` allow-all, removing its teeth, because it keeps breaking things. The security layer ends up either off or so permissive it is decorative.

The voice memo named this directly: the WAF gets **"ripped off, or set to star-star, or has its teeth removed, because it's breaking shit."** This is the universal failure mode of bolted-on security.

SG/Sentinel inverts the equation: **security is part of the application, and the application controls the security layer.** Because Sentinel understands the application (the coupling principle from the MVP brief), it does not break legitimate functionality. Because the application can control Sentinel (the interactivity this brief describes), security is not an adversarial external thing but an integrated, controllable part of the system.

The voice memo named the blind spot: **"one of the biggest blind spots I've always seen in a lot of tools is that they don't design these tools to be controllable, to be injected into the application."** SG/Sentinel is designed from the start to be controllable and injectable. That is the difference.

## Not A Spectator Sport: Two-Way Layer Invocation

The core interactivity principle: **every layer of Sentinel is individually invocable, and the layers can be triggered in sequence from the front gate.**

Recall the layers from the execution-model brief, now enumerated more precisely. The voice memo named at least four (possibly five or six) function types:

| Layer | Function Type | Characteristics |
|-------|---------------|-----------------|
| Layer 1 | Real-time, light | Super fast, sub-ms, no I/O (CloudFront Functions) |
| Layer 2 | Lambda@Edge | Has filesystem and network access |
| Layer 3a | Async, super fast | Out-of-line, no LLM, fast |
| Layer 3b | Async, light LLM | Out-of-line, Nova-class model |
| Layer 3c | Async, heavy LLM | Out-of-line, full model, deep analysis |

The interactivity requirements:

1. **Each layer is invocable individually.** You can call Layer 2 directly to test it, without going through Layer 1. You can call a Layer 3 async function directly to see what it does.
2. **Layers can be triggered in sequence from the front gate.** You can invoke from the outside (the gateway, the Sentinel front door) and have the request flow through all layers, to see the combined implications.
3. **All of this works from the outside.** The voice memo emphasised: you should be able to invoke them all from the outside, coming from the front gate, all the way down to the individual functions.

This dual capability (individual invocation plus sequential triggering) is what makes Sentinel developable and testable. You can test a single layer in isolation, or test the whole flow end to end, or anything in between.

### Why The "Only Thing We Can Touch Is The Gateway" Scenario Matters

The voice memo named a specific deployment scenario that drives this requirement: **in isolated deployments, the only thing reachable from the outside may be the gateway itself.** Everything behind Sentinel is isolated; Sentinel is the only externally-reachable surface.

In that scenario, the ability to invoke all the layers through Sentinel's API is not a convenience, it is the only way to interact with the deployment at all. The voice memo: **"we're going to have deployments where the only thing we can touch is the outside world, the gateway, basically the Sentinel is the only thing we can actually reach, so we should be able to connect them all and access them all."**

This makes the two-way conversation API (from the MVP brief) the diagnostic and control entry point for the entire isolated deployment. Sentinel is not just the guard; it is the only door, and through that door you can reach and exercise every layer.

## The Whole Solution Runs Locally

A principle the voice memo emphasised strongly: **the whole of SG/Sentinel runs locally, identically to how it runs in production.**

The same code runs in:

| Environment | Form |
|-------------|------|
| **Local development** | Python (or whatever technology) running directly on the dev machine |
| **Local containers** | The same code in containers locally |
| **Inefficient-lambda-as-container** | Lambda functions are just containers; run them as containers locally |
| **Full deployment** | CloudFront Functions, Lambda@Edge, the real production substrate |

The voice memo: **"it's quite important that the whole solution also runs locally from Python, or whatever technology we use; it can run locally on containers, and then it can run locally on inefficient lambda functions which are just containers, or in the full deployment."**

This local-everywhere property is essential for two reasons:

**First, testing.** You cannot develop security rules safely if the only place to run them is production. Running the whole stack locally means rules can be developed, tested, and validated before they go anywhere near a live server.

**Second, the rules that go live must be created and editable locally by the application, the LLMs, or whoever is developing.** The voice memo: **"the rules for that go live need to be created and editable by the application and by the LLMs or by whoever's developing this."** Local-everywhere is what makes interactive rule development possible.

The "lambda functions are just containers" insight is the bridge: because the production Lambda functions are containers, the same containers run locally. The local environment is not a simulation of production; it is the same code in the same container form, just running on a different substrate. This is the substrate-independence principle from the principles brief, applied to make local development faithful to production.

## Dangerous Dev-Only Rules

A genuinely interesting idea the voice memo introduced: **some rules are too dangerous or powerful for production but invaluable in development.** The deployment-phase model (below) is what makes these safe to have.

The canonical example the voice memo gave: **a rule that enables or disables other rules.** In production, a rule that can turn other rules on and off is a dangerous capability (a compromised or buggy version could disable all protection). But in development, it is invaluable: you can make a request with a rule enabled, then the same request with it disabled, and confirm exactly what that rule does and whether it is causing a bug.

The voice memo's example scenario: **"there is a bug that we think might be caused by a rule. You want to make a request with the rule enabled, make a request with the rule disabled, and confirm exactly what happened."** That requires a rule that controls other rules, which is powerful enough that it should run in dev (and maybe pre-prod) but never in production.

Other dangerous-but-useful dev rules:

| Dev-Only Rule | Why Useful In Dev | Why Dangerous In Prod |
|---------------|-------------------|------------------------|
| Enable/disable other rules | Isolate which rule causes a behaviour | Could disable protection |
| Bypass all blocking | Test the app without Sentinel interference | Removes all security |
| Dump full request state | Deep debugging | Privacy/security exposure |
| Inject synthetic traffic | Test rule responses | Could be abused |
| Verbose trace every decision | Understand the full flow | Performance and information leak |

The principle: **dev-only rules exist, are version-controlled and tested like any rule, but are gated by deployment phase so they never reach production.** This is what lets us build powerful development tooling without endangering production.

## Minimal Bundles: Never Ship An Uninvoked Rule

A principle the voice memo introduced and connected to the dangerous-rules point: **the code deployed to a live server should be as small, tight, and condensed as possible. Never ship a rule to a live server that is not currently being invoked.**

The bundle that goes to production contains only the rules that production actually runs. Dev-only rules are not in the production bundle. Disabled rules are not in the production bundle. The production deployment is the minimal set of rules that production needs, and nothing else.

This has several benefits:

| Benefit | Why |
|---------|-----|
| **Security** | Code that is not deployed cannot be exploited; the dangerous dev rules are not in prod to be abused |
| **Performance** | A minimal bundle loads and runs faster; especially critical at Layer 1 |
| **Auditability** | The production bundle is exactly the active rule-set; nothing hidden |
| **Risk** | Less code in production means less to go wrong |

The bundle-building process is therefore phase-aware: it assembles, for each deployment target, exactly the rules that target should run, at exactly the versions specified, and nothing more. The dev-only rules exist in the repository, are tested, but are excluded from the production bundle by the build.

This connects to the per-rule version control from the rules-engine brief: the bundle is a manifest of rule versions for a specific deployment phase. Building a production bundle means selecting the production-phase rules at their pinned versions.

## The Dev/Main/Prod Deployment Phase Model

The voice memo worked out a deployment-phase model that governs rule promotion. The phases:

| Phase | Branch | Role | Rule Behaviour |
|-------|--------|------|----------------|
| **Dev** | dev | Experimentation | All rules available, including dangerous dev-only ones; freely changed |
| **Main** | main | QA / validation | Locked down; tested; main equals QA |
| **Prod** | (main) | Production | Main is production; what passes QA is what runs |

The voice memo's framing: **"dev, main, and prod, where dev we can lock down, then when you go to main (which is our QA), it should be locked down, then you run the tests, and main is equal to production."**

The flow:

1. **Dev**: experiment freely. All rules, including dangerous dev-only ones, are available. Rules are created, edited, tried out. This is where the LLM-assisted rule development happens. This is where the dangerous rules (enable/disable, bypass, trace) run.
2. **Lock down**: when a rule is considered right, it gets locked down, its version pinned, its behaviour fixed.
3. **Main (= QA)**: the locked-down rules go to main, which is the QA environment. Tests run here. The dangerous dev-only rules do not come to main. Main is the validation gate.
4. **Prod**: main equals production. What passes QA in main is what runs in production. There is no separate prod-promotion step that could introduce untested changes; main is production.

The "main equals production" discipline is important. It means **the thing that is tested in QA is exactly the thing that runs in production, with no further changes.** There is no gap between "what we tested" and "what we shipped." The validation in main is validation of production.

This phase model is what makes the dangerous dev-only rules safe: they live in dev, are useful in dev, and are excluded by phase from main and prod. The deployment phase is a first-class property of every rule.

## Tests That Confirm Behaviour

The voice memo emphasised that **tests are first-class: you should have tests that confirm something works.** The dangerous-rule example is also a testing example: the enable/disable-rule capability is how you write a test that confirms a specific rule causes (or does not cause) a specific behaviour.

The testing model:

- **Each rule is tested in isolation** (from the rules-engine brief).
- **The whole flow is tested end to end** (using the two-way invocation from this brief).
- **Behaviour is confirmed differentially** (request with rule enabled vs disabled, using the dangerous dev-only enable/disable rule).
- **Tests run locally** (using the local-everywhere property).
- **Tests run in main/QA before production** (using the phase model).

This is a complete testing story: rules tested in isolation, flows tested end to end, behaviour confirmed differentially, all locally and in QA before production. The interactivity (two-way invocation, local-everywhere, dangerous dev rules) is what makes this testing possible. **The interactivity is not a luxury; it is what makes the security layer trustworthy.**

## Workflows As First-Class Citizens

The voice memo was emphatic: **these workflows have to be first-class citizens.** The interaction with the development environment, the deployment phases, the promotion flow, the testing, all of it is core, not bolted on.

The voice memo: **"the whole interaction with the development environment has to be a lot more dynamic, and that's why you have to have this level of deployment and interactivity with the multiple engines and multiple types of deployments, to make sure that only the code we really want ends up in prod."**

The first-class workflows:

| Workflow | What It Does |
|----------|--------------|
| **Develop a rule** | Create, edit, try out a rule in dev with full interactivity |
| **Test a rule** | Confirm behaviour in isolation and in flow, locally |
| **Lock down a rule** | Pin its version; fix its behaviour |
| **Promote to main/QA** | Move locked rules to QA; run the test suite |
| **Validate in main** | Confirm the production-bound rule-set passes QA |
| **Deploy to prod** | Main equals production; what passed QA runs |
| **Differential debug** | Use dangerous dev rules to isolate behaviour |
| **Invoke any layer** | Test individual layers or the whole flow |

These workflows are the development discipline for SG/Sentinel. They are first-class because the whole value proposition (a security layer that does not break things and is trusted enough to keep its teeth) depends on them.

## How This Composes With The Series

| Brief | Relationship |
|-------|--------------|
| Principles brief | Substrate independence enables local-everywhere |
| Execution-model brief | The layers this brief makes individually invocable |
| MVP brief | The two-way conversation API this brief builds the interactivity model on |
| Rules-engine brief | The rules, versions, and bundles this brief promotes through phases |
| **This interactivity brief** | **The development and deployment lifecycle for the whole system** |

This brief ties the series together on the development side: the rules-engine brief said rules are everything; this brief says how rules are developed, tested, and promoted, with the interactivity and phase discipline that makes a security layer trustworthy rather than something you weaken until it is decorative.

## What This Asks For

Concrete next steps:

1. **Build individual layer invocation**: call any layer directly via API.
2. **Build sequential triggering from the front gate**: invoke through the whole flow from outside.
3. **Make the whole solution run locally**: Python, containers, lambda-as-container, identical to production.
4. **Build the dangerous dev-only rule mechanism**: rules gated by deployment phase.
5. **Build the enable/disable-rule capability** as the first dangerous dev rule (for differential testing).
6. **Build phase-aware bundle assembly**: production bundles contain only production rules.
7. **Implement the dev/main/prod phase model**: main equals production; dev has the dangerous rules.
8. **Build the rule promotion workflow**: develop, lock down, promote, validate, deploy.
9. **Build the differential testing capability**: confirm behaviour with rule enabled vs disabled.
10. **Make the workflows first-class**: CLI/TUI commands for the whole lifecycle.

Estimated effort: 2-3 weeks for local-everywhere, individual layer invocation, the phase model, and the dangerous-dev-rule mechanism. Builds on the MVP and rules-engine work.

## What This Does Not Try To Be

Deliberate scope limits:

- **Not a separate staging infrastructure.** The phase model uses branches and bundles, not a parallel infrastructure stack.
- **Not LLM-inline even in dev.** Dev has dangerous rules, but the no-inline-LLM principle still holds.
- **Not unlimited dev-only power in prod.** The phase gating is strict; dangerous rules never reach prod.
- **Not a replacement for the rules-engine brief's model.** This brief is the lifecycle around that model.
- **Not a full CI/CD platform.** It uses our existing CI; it adds the phase-and-promotion discipline specific to rules.

## Honest Risks

Three risks:

**Risk 1: The dangerous dev-only rules could leak into production.** If phase gating fails, a bypass-all-blocking rule in production is catastrophic. Mitigation: phase gating is enforced at bundle-build time (dangerous rules are excluded from the prod bundle by construction); audited; the build fails if a dev-only rule is in a prod manifest.

**Risk 2: Local-everywhere could diverge from production.** If local and production drift, local testing becomes unreliable. Mitigation: the lambda-as-container insight keeps them identical; the same containers run locally and in production; test the equivalence regularly.

**Risk 3: Main-equals-production is unforgiving.** If main is production, a bad merge to main is a bad production deploy. Mitigation: the QA gate on main; main is locked down and tested before it is production; the promotion workflow requires passing tests.

## Open Questions

| Question | Notes |
|----------|-------|
| How many function types exactly: four, five, or six? | At least four; the LLM-heavy async may split into more |
| How is phase gating enforced at bundle build? | Dangerous rules excluded by manifest; build fails if violated |
| Does main-equals-production need a brief lock window? | Probably; a short validation window in main before it is live |
| How faithful is lambda-as-container locally? | Should be identical; test the equivalence |
| Where do dev-only rules live in version control? | Same repo, tagged dev-only; excluded from prod bundles |
| Can pre-prod run some dangerous rules? | Possibly; a pre-prod phase between main and prod for some cases |
| How do we audit that prod contains only intended rules? | The prod bundle manifest is the audit; compare to expected |
| Differential testing: automated or manual? | Both; automated in the test suite, manual for debugging |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 18 May | `v0.27.58__arch-brief__sg-sentinel-rules-engine.md` | The rules and versions this brief promotes through phases |
| 18 May | `v0.27.58__dev-brief__edge-layer-mvp-visibility-blocking-deployment.md` | The two-way conversation API this brief's interactivity builds on |
| 18 May | `v0.27.58__arch-brief__edge-layer-execution-model-layered-responders.md` | The layers this brief makes individually invocable |
| 18 May | `v0.27.58__arch-brief__edge-security-and-logging-layer-principles.md` | Substrate independence enables local-everywhere |
| 17 May | `v0.27.55__arch-brief__tui-api-extensions-iam-memfs-orientation.md` | The IAM and orientation patterns apply to layer invocation |
| 17 May | `v0.27.55__dev-brief__sg-labs-admin-interface.md` | The dev/main/prod and lifecycle patterns echo the labs admin model |
| 16 May | `v0.27.45__arch-brief__vault-testing-framework.md` | The testing discipline this brief applies to rules |
| 16 May | `v0.27.45__strategy-brief__sg-compute-as-serverless-environment.md` | The substrate that runs locally and in production identically |
| 14 May | `v0.27.41__arch-brief__vaults-of-vaults-self-contained-mini-apps.md` | The rule-set-as-vault and bundle model |
| 13 May | `v0.27.40__arch-brief__cli-first-agent-architecture.md` | The CLI-first workflows this brief makes first-class |

---

## Acceptance Criteria

| # | Criterion | Verification |
|---|-----------|-------------|
| 1 | Each Sentinel layer is individually invocable via API | Direct invocation works |
| 2 | Layers can be triggered in sequence from the front gate | End-to-end flow invocation works |
| 3 | The whole solution runs locally (Python, containers, lambda-as-container) | Identical to production |
| 4 | Dangerous dev-only rules exist and are phase-gated | Cannot reach production |
| 5 | The enable/disable-rule capability works for differential testing | Behaviour confirmed with rule on vs off |
| 6 | Production bundles contain only production rules | No dev-only or uninvoked rules in prod |
| 7 | The dev/main/prod phase model works | Rules promote through phases |
| 8 | Main equals production; QA validates the production rule-set | No gap between tested and shipped |
| 9 | The rule promotion workflow (develop, lock, promote, validate, deploy) works | Full lifecycle |
| 10 | Differential testing confirms rule behaviour | Tests use enable/disable |
| 11 | The workflows are first-class (CLI/TUI commands) | Lifecycle is operable |
| 12 | Phase gating is enforced at bundle build (build fails on violation) | Dangerous rules cannot leak |

---

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