# Time As A First-Class Dimension In SG/Sentinel: Faster For The Good, Detected-Before-Damage For The Bad

**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 eighth brief in the SG/Sentinel series, treating **time as a first-class design dimension**. Time matters here in more ways than function execution speed: it is the time to execute a whole flow, the multiple timelines a decision spans, and the strategic, creative use of time to flip security from a tax into an advantage.

Two ideas anchor this brief, and both are inversions of conventional WAF thinking:

- **Making good users faster.** Because we know what good traffic looks like (the coupling principle), we can allowlist known-good users and make them faster, not just block bad ones. Security stops being a tax everyone pays and becomes a fast-track for the good and friction for the bad. The website gets faster and more protected at the same time.
- **Detect before damage, not detect instantly.** We do not have to block a malicious attacker on their first request. We have to block them before they do any damage. An attacker can make thousands of requests; we want them to make one mistake (a call none of our code ever makes), and we detect that within a period of time, not in the request's lifetime.

The unifying insight: **Sentinel ultimately makes a decision (benign or malicious, allow or block), and that decision can draw on multiple timelines, holding rich state across them.** Most WAFs are stateless or hold limited state; SG/Sentinel makes the state object as rich as possible and uses time strategically to make the right decision at the right moment.

This brief covers the multiple-timelines model, the make-good-users-faster inversion, user fingerprinting and allowlisting, resilience for known users, the detect-before-damage principle, and the success metric that follows from it.

## Sentinel Makes A Decision

Worth grounding in the fundamental purpose. Beyond all the logging, routing, and activity, **Sentinel ultimately makes a decision about every request**: is this benign or malicious? Good traffic or bad? A bug or legitimate? Should it be banned or allowed? Is it something we should not be seeing at all?

The voice memo: **"ultimately the Sentinel is making a decision, whether is this benign traffic, is this good traffic, is this malicious traffic, is this bad traffic, is it a bug, is it something that we shouldn't see, should I ban it or not?"**

The key observation about that decision: **it does not all have to be made at one instant.** The decision can draw on what happened before (rich state), what is happening now (the current request), and what happens after (subsequent analysis). Most WAFs make the decision in the request's lifetime and then forget. SG/Sentinel holds rich state and makes the decision across multiple timelines.

The voice memo named the mistake most WAFs make: **"they don't hold state afterwards, or they have limited state. I want to make the state and the object that's happening to be as rich as possible."** The richer the state, the better the decision, and the decision can be refined over time as more is known.

## The Multiple Timelines

Time in Sentinel is not one clock; it is several. The voice memo described multiple timelines, mapping onto the layered model from earlier briefs but viewed through the lens of time.

| Timeline | Timeframe | What Happens | Layer |
|----------|-----------|--------------|-------|
| **Immediate** | Sub-millisecond | Can this go through right now? The instant allow/block | Layer 1 |
| **Real-time-plus** | Milliseconds | More checks, still inline, a bit more time | Layer 2 |
| **Near-real-time** | Seconds | Async checks, more data, IP intelligence, threat analysis | Layer 3 (async) |
| **Analytical** | Seconds to minutes | LLM analysis, pattern detection, rule generation | Layer 3 (LLM, async) |
| **Historical** | Minutes to days | Long-window pattern detection across many requests | Layer 3 (analysis over stored state) |

The crucial point: **each timeline serves the others.** The voice memo: **"the job of the next layers is to make these layers more effective."** The immediate layer makes the instant decision; the slower layers analyse, learn, and feed improvements back to the immediate layer. The fast layers enforce; the slow layers think.

This is the "slow analysis, fast enforcement" pattern from the execution-model brief, now understood as a set of timelines. The immediate timeline must be fast (it is inline); the analytical and historical timelines can take their time, because their job is to make the fast timelines smarter, not to make the inline decision.

## The Inversion: Making Good Users Faster

The most important reframe in the memo, and one that flips the entire value proposition of a security layer.

Conventional security is a tax. Everyone pays it. Every request goes through the WAF, gets checked, slowed down slightly, in the name of catching the few bad requests. Security is a pain, an overhead, a cost paid by everyone to stop a minority.

SG/Sentinel inverts this: **because we know what good looks like, we can make good users faster.** The voice memo: **"the single biggest advantage we have against attackers is that we should know what good traffic looks like."** And knowing what good looks like is not just about blocking bad; it is about **allowlisting good and speeding it up.**

The voice memo's framing of the inversion: **"this is not just about adding more security layers; this is also about removing security layers. If I know for sure that this IP address, this traffic, is a valid user, it has logged in, it has all the signals, then it should go faster."**

The mechanism:

| Traditional WAF | SG/Sentinel |
|-----------------|-------------|
| Every request checked equally | Known-good requests fast-tracked |
| Security slows everyone | Security speeds the good, slows the bad |
| A tax everyone pays | A fast-track for the known-good |
| Adds latency | Can remove latency for known users |
| Negative (pain, overhead) | Positive (faster, more protected) |

The core principle the voice memo named: **"we want to make sure the overhead for good users is as little as possible. In fact, can we speed things up? Can we make it better for known users?"** This transforms security from a negative (the tax we pay) into a positive (the website is faster for legitimate users and more protected at the same time).

The voice memo's summary of the flip: **"we flip the model to say no, we're making the good users faster, we're making the website faster, we are protecting the website, we're making sure the website always works for benign users."** Security and performance, usually in tension, become aligned. The same knowledge of what good looks like that protects against attackers also accelerates legitimate users.

## User Fingerprinting And Allowlisting

The mechanism behind making good users faster: **fingerprint the user, and allowlist the fingerprint.**

The voice memo: **"we can fingerprint the user based on a whole bunch of stuff, including IP address, stuff that we know won't change at that moment in time."** A user's fingerprint is the combination of signals that identify them: IP address, authentication state, session signals, and other characteristics that are stable for the duration of their session.

Once a user is fingerprinted and validated:

- The fingerprint goes on an allowlist
- Subsequent requests matching the fingerprint are fast-tracked
- The expensive checks are skipped for the known-good fingerprint
- The user experiences a faster site

The voice memo: **"we should be allowlisting the person, allowlisting the IP address, allowing that particular IP address or that particular user, or that combination, that signature of the user."** The signature (the fingerprint) is what gets allowlisted, not just a raw IP, so it is precise.

This is the allowlist side of the no-invalid-request principle. The earlier briefs focused on dropping invalid requests; this brief adds the complement: **fast-tracking valid ones via their fingerprint.** Both come from knowing what good looks like. Drop the bad; accelerate the good.

The fingerprint is time-bounded: it is valid for the period during which the identifying signals are stable (a session, a known-stable IP window). When the signals change, the fingerprint is re-validated. This keeps the allowlist precise and current.

## Resilience For Known Users

A consequence of the fingerprint allowlist the voice memo highlighted: **if something breaks, it should only affect a small part of the website, and known-good users should be insulated.**

The voice memo's example: **"if there's a problem with your login stuff, or something goes wrong, that should only affect a small part of the website. If we already know the user is logged in, if the user is already allowed, then we shouldn't put any restrictions on it."**

This is a resilience benefit that falls out of the fingerprint model. A user who is already validated and allowlisted does not get caught by a problem in, say, the login system, because they are already past that check. Their fingerprint says they are good; a failure in a check they have already passed does not affect them.

This means:

- A bug in one part of the system affects only users hitting that part
- Already-validated users continue working through unrelated failures
- The blast radius of a problem is contained to users who have not yet been validated against the affected check
- Known-good users get a more resilient experience

This is another way the make-good-users-faster inversion pays off: it also makes good users more resilient. The fingerprint is not just a speed optimisation; it is an insulation against failures in checks the user has already passed.

The brief connects this to the graph idea the voice memo mentioned: **certain files or actions should follow a particular sequence of events.** Sentinel can enforce sequence rules (this action only after that one), which both prevents certain attacks (out-of-sequence requests are suspicious) and structures the resilience (a user who has completed a sequence is past those checks). The sequence graph is part of knowing what good looks like.

## Detect Before Damage, Not Detect Instantly

The deepest timing insight in the memo, and one that reframes the entire detection problem: **we do not have to block a malicious attacker on their first request. We have to block them before they do any damage.**

The voice memo: **"we don't have to block the requests of a malicious attacker in the first moment; we just have to block it before it does any damage."**

This is liberating because it changes the time budget for detection entirely. An attacker probing the system makes many requests: **5, 10, 20, 30, 50, 100, thousands of requests.** We do not have to catch the first one. We have to catch them before they do damage. And critically: **we want the attacker to make one mistake.**

The voice memo: **"what we want the attacker to do is one mistake. We want the attacker to do a call that none of our CLI, none of our APIs, none of our code currently does. The moment it does that, we will detect it."** Because we know exactly what valid traffic looks like (the coupling principle), any request outside that profile is a tell. The attacker, probing, will eventually make a request that no legitimate client ever makes. That request is the mistake, and it reveals them.

And the detection does not have to be instant: **"we don't have to detect it in real time; we just have to detect it within a period of time."** The voice memo worked through the time budget: **"if we can detect an attacker within 30 seconds, or a minute, or an hour, or a day, what's the side effect? In most cases you'll find that if we can detect an attacker within 20 minutes or an hour or even 10 minutes, that's more than good enough."**

The reasoning: an attacker probing the system is not doing damage in the first 10 minutes of probing. They are mapping, testing, looking for a way in. The damage comes later, if they find a vulnerability. **If we detect them during the probing phase (which their out-of-profile requests reveal) and block them before they find anything, no damage is done.** The detection window is the probing window, which is generous.

This inverts the panic of real-time detection. We do not need a sub-millisecond verdict on every request's malice. We need to observe the pattern over a window, spot the out-of-profile request that reveals the attacker, and block them before they progress to damage. **The fast layers enforce known decisions; the slow layers detect attackers over a window; the combination stops attackers before damage without needing instant malice-detection.**

## The Success Metric

The voice memo named the measure of success clearly, and it follows from detect-before-damage: **can we stop an attacker before they do any damage, access any sensitive data, or impact any other user or the platform?**

The voice memo: **"our measurement of success is can we stop an attacker before it does any damage or access any sensitive data or impacts any other user. Can we stop an attacker before he has any impact on the platform, and the users, and the data?"**

This is a better success metric than the conventional WAF metric of "requests blocked" or "attacks detected." It measures the thing that actually matters:

| Conventional Metric | SG/Sentinel Metric |
|---------------------|--------------------|
| Requests blocked | Damage prevented |
| Attacks detected | Attackers stopped before impact |
| Rules triggered | Sensitive data protected |
| False-positive rate | Legitimate users unaffected |

The success metric is outcome-focused: not how much we blocked, but whether any harm occurred. An attacker who probes for an hour and is blocked before finding anything is a success, even though we did not block their first request. An attacker who is blocked on their first request but a legitimate user was also blocked is a worse outcome.

This metric aligns with the make-good-users-faster inversion. Success is: good users are fast and unaffected; attackers are stopped before impact. Both halves matter, and both come from knowing what good looks like.

## How Time Ties The Series Together

Time is the dimension that makes the layered model coherent. Each earlier brief contributes:

| Brief | Time Contribution |
|-------|-------------------|
| Execution-model | The layers, now understood as timelines |
| Rules-engine | Rules of different types run on different timelines |
| Interactivity | Local-everywhere lets us test timing behaviour |
| MVP | The visibility to measure timing (hot data) |
| Codebase-extension | Type-safe checks at the right altitude (and the right time) |
| Delegation | The detect-before-damage principle deepened |
| **This timing brief** | **Time as the strategic dimension: faster for good, detected-before-damage for bad** |

The timing model is what makes the whole architecture work as a system rather than a stack of checks. Fast enforcement on the immediate timeline; learning and detection on the slower timelines; the slow making the fast smarter; good users accelerated; attackers detected over a window before they do damage.

## What This Asks For

Concrete next steps:

1. **Build the rich-state model** so decisions can draw on history, not just the current request.
2. **Implement the multiple-timelines architecture** (immediate, real-time-plus, near-real-time, analytical, historical).
3. **Build user fingerprinting** (IP plus stable signals plus auth state).
4. **Build the fingerprint allowlist** so known-good users are fast-tracked.
5. **Measure the overhead for good users** and minimise it (the make-good-users-faster goal).
6. **Build the sequence-graph enforcement** (certain actions only after others).
7. **Build the resilience insulation** so validated users are unaffected by failures in checks they passed.
8. **Implement detect-before-damage** (observe over a window; spot the out-of-profile mistake; block before progression).
9. **Define the detection time budget** (how long is acceptable; probably minutes, not milliseconds).
10. **Adopt the success metric** (damage prevented, not requests blocked).
11. **Measure timing end to end** (deployment speed, rule speed, execution speed; the hot data).

Estimated effort: 2-3 weeks for the fingerprint allowlist, the multiple-timelines model, and detect-before-damage, building on the rules engine and the layered model.

## What This Does Not Try To Be

Deliberate scope limits:

- **Not instant malice detection.** Detect-before-damage means a window, not the request's lifetime.
- **Not a removal of fast blocking.** Known-bad is still blocked instantly at Layer 1; the window is for detecting unknown attackers.
- **Not fingerprinting for tracking.** The fingerprint is for fast-tracking known-good in-session, not cross-session user tracking.
- **Not a guarantee against zero-day instant damage.** If an attacker finds instant damage on request one, the window does not help; defence in depth and the no-invalid-request allowlist mitigate this.
- **Not a replacement for the layered model.** It is the time dimension of that model.

## Honest Risks

Three risks:

**Risk 1: Detect-before-damage fails if damage can happen on the first request.** Some attacks (a single exploit request) do damage instantly. Mitigation: the no-invalid-request allowlist blocks unknown request shapes at the gate (Layer 1), so the first damaging request must be in-profile to get through; defence in depth for the most sensitive operations; the window is for detecting probing, not the only defence.

**Risk 2: Fingerprint allowlisting could be spoofed.** If an attacker forges a known-good fingerprint, they get fast-tracked. Mitigation: the fingerprint includes signals that are hard to forge (auth state, session tokens); fingerprints are time-bounded and re-validated; anomalies in an allowlisted fingerprint's behaviour trigger re-checks.

**Risk 3: Rich state could become a performance or storage burden.** Holding rich state for every request at scale is costly. Mitigation: state richness is tiered (more for suspicious traffic, less for fast-tracked known-good); the historical timeline uses efficient storage; measure the cost.

## Open Questions

| Question | Notes |
|----------|-------|
| What signals make up the user fingerprint? | IP, auth state, session, stable headers; precise set TBD |
| How time-bounded is a fingerprint allowlist entry? | Session-length or a stable-signal window; re-validate on change |
| What is the acceptable detection window? | Probably minutes; depends on what damage is possible in-profile |
| How rich should the per-request state be? | Tiered; rich for suspicious, light for fast-tracked |
| Where does the historical-timeline state live? | Efficient storage; connect to the logging architecture |
| How is the sequence graph defined? | Per-application; certain actions only after others |
| How do we prevent fingerprint spoofing? | Hard-to-forge signals; re-validation; behavioural anomaly checks |
| What is the side-effect analysis for each detection window? | Per-endpoint; what damage is possible before detection |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 18 May | `v0.27.58__arch-brief__sg-sentinel-delegation-and-choke-points.md` | The detect-before-damage principle this brief deepens |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-as-codebase-extension.md` | Knowing-what-good-looks-like, the basis for fingerprint allowlisting |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-rules-engine.md` | Rules of different types run on different timelines |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-interactivity-and-deployment-phases.md` | Local-everywhere to test timing behaviour |
| 18 May | `v0.27.58__dev-brief__edge-layer-mvp-visibility-blocking-deployment.md` | The visibility to measure timing (hot data) |
| 18 May | `v0.27.58__arch-brief__edge-layer-execution-model-layered-responders.md` | The layers, now understood as timelines |
| 18 May | `v0.27.58__arch-brief__edge-security-and-logging-layer-principles.md` | The make-the-site-hostile and know-what-good-looks-like principles |
| 16 May | `v0.27.45__dev-brief__nova-and-agentcore-poc-fastapi.md` | Nova for the analytical-timeline LLM analysis |
| 15 May | `v0.27.43__arch-brief__unified-observability-session.md` | Where the timing hot data is observed |

---

## Acceptance Criteria

| # | Criterion | Verification |
|---|-----------|-------------|
| 1 | Rich per-request state is held, not discarded after the decision | State persists for analysis |
| 2 | The multiple-timelines architecture works (immediate to historical) | Each timeline operates |
| 3 | User fingerprinting works (IP plus stable signals plus auth) | Users are fingerprinted |
| 4 | The fingerprint allowlist fast-tracks known-good users | Good users are measurably faster |
| 5 | Overhead for good users is minimised | Measured; low |
| 6 | Sequence-graph enforcement works | Out-of-sequence requests flagged |
| 7 | Validated users are insulated from failures in checks they passed | Resilience verified |
| 8 | Detect-before-damage works (window detection of out-of-profile requests) | Attacker detected before damage |
| 9 | The detection time budget is defined and met | Within the acceptable window |
| 10 | The success metric (damage prevented) is adopted and measured | Outcome-focused measurement |
| 11 | Timing is measured end to end (deployment, rule, execution speed) | Hot data available |

---

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