WEB / WEB-22.02

From HTTP to a handler

Follow a public GET through edge, proxy, runtime, and a local handler; identify the owner of each response.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Origin handler

Public read plan
The client has prepared GET and its compact query; edge and runtime do not yet know this request.
Client
GET plan prepared
Edge policy/cache
No request yet
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called
Edge request arrival
The conceptual request reaches the edge; client prepared state and other receivers remain unchanged.
Client
GET plan prepared
Edge policy/cache
Public GET received
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called
Edge policy and miss
After selected maintenance=false and a cache miss the edge prepares an upstream request; this is not vendor rule execution.
Client
GET plan prepared
Edge policy/cache
Policy allow; origin request prepared
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called
Proxy request arrival
The edge upstream request reaches the balancer/proxy; the runtime has still not seen a request.
Client
GET plan prepared
Edge policy/cache
Policy allow; origin request prepared
Balancer/proxy
Proxy request received
Runtime/router
No runtime request
Public note service
Service not called
Replica and upstream
The observed a=false,b=true list selects app-b; the proxy prepares a runtime request as a separate relation.
Client
GET plan prepared
Edge policy/cache
Policy allow; origin request prepared
Balancer/proxy
app-b selected; runtime request prepared
Runtime/router
No runtime request
Public note service
Service not called
Runtime request arrival
The conceptual proxy request reaches the runtime; proxy selection grants no application permission.
Client
GET plan prepared
Edge policy/cache
Policy allow; origin request prepared
Balancer/proxy
app-b selected; runtime request prepared
Runtime/router
GET target received
Public note service
Service not called
Middleware and route
The local public-purpose gate precedes fixed method/path matching; middleware handoff is not drawn as a packet.
Client
GET plan prepared
Edge policy/cache
Policy allow; origin request prepared
Balancer/proxy
app-b selected; runtime request prepared
Runtime/router
Public gate passed; tea route matched
Public note service
Service not called
Handler result prepared
The local service prepares Tea note bytes; the bounded scene does not claim response delivery to the client.
Client
GET plan prepared
Edge policy/cache
Policy allow; origin request prepared
Balancer/proxy
app-b selected; runtime request prepared
Runtime/router
Public gate passed; tea route matched
Public note service
Tea note result prepared; client waits

Public cache hit

Public cache intent
The previously received request has a public contract; selected policy and cache source are evaluated separately.
Client
Client waiting
Edge policy/cache
Public request received
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called
Policy and cache hit
Selected policy allow and supplied age2<lifetime5 give a suitable public hit; no HTTP cache engine is claimed.
Client
Client waiting
Edge policy/cache
Public cache hit; zero upstream
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called
Cached response prepared
The stored public JSON response is prepared; origin and service owners have not been called.
Client
Client waiting
Edge policy/cache
Cached200 response prepared
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called
Client cache arrival
The conceptual cached response reaches the client; no server-side handler visit is invented.
Client
Cached JSON received
Edge policy/cache
Cached200 response prepared
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called
Public body decoded
The client projection reads public JSON id/title fields; this is not native browser parsing or document rendering.
Client
tea / Tea note public body known
Edge policy/cache
Cached200 response prepared
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called

Edge policy block

Edge policy intent
The edge received the request at a prior boundary; the selected closure policy is supplied for evaluation.
Client
Client waiting
Edge policy/cache
Public request received
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called
Maintenance closed
Supplied maintenanceClosed=true produces the selected block decision; neither cache nor origin is called.
Client
Client waiting
Edge policy/cache
Block decision; no upstream
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called
Policy response prepared
The edge403 response is prepared; the runtime still knows no request and serviceCalls remains zero.
Client
Client waiting
Edge policy/cache
403 policy response prepared
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called
Client policy arrival
The conceptual policy response reaches the client; the edge retains the same prepared state.
Client
403 edge-policy received
Edge policy/cache
403 policy response prepared
Balancer/proxy
No upstream yet
Runtime/router
No runtime request
Public note service
Service not called

No route match

Runtime route intent
The missing-path request reached the runtime at a prior boundary. The public-purpose gate has not decided yet; route matching and service invocation have not occurred.
Client
Client waiting
Edge policy/cache
Edge waiting
Balancer/proxy
Proxy waiting
Runtime/router
Missing route request received
Public note service
Service not called
Public purpose passed
The selected public gate is true; it is neither principal authentication nor private object authorization.
Client
Client waiting
Edge policy/cache
Edge waiting
Balancer/proxy
Proxy waiting
Runtime/router
Public gate true; route pending
Public note service
Service not called
No route match
The fixed allowlisted route table has no missing path; service read count0 and router404 are selected.
Client
Client waiting
Edge policy/cache
Edge waiting
Balancer/proxy
Proxy waiting
Runtime/router
Router404; zero service
Public note service
Service not called
Router response prepared
The runtime404 response is prepared for the proxy; no generic object-absence or edge-policy conclusion is invented.
Client
Client waiting
Edge policy/cache
Edge waiting
Balancer/proxy
Proxy waiting
Runtime/router
Router404 response prepared
Public note service
Service not called
Proxy404 arrival
The conceptual runtime response reaches the proxy; client and edge still wait in this bounded scene.
Client
Client waiting
Edge policy/cache
Edge waiting
Balancer/proxy
Runtime-router404 received
Runtime/router
Router404 response prepared
Public note service
Service not called

ACTORS · STATE · DATA FLOW

An HTTP request is not shared knowledge across boxes

Follow the prepared GET /notes/tea?view=compact plan from WEB-22.01. This selected read is public, has no body, and excludes #details from the server target. A request line and Host field form a readable HTTP/1.1 projection; HTTP/2 and HTTP/3 carry the same semantics using different frames and fields. A prepared client plan does not mean the edge has seen it. The first arrival changes edge knowledge only.

A CDN can supply a public representation from a suitable cache entry or prepare an upstream request on an origin miss. A WAF inspects requests against configured policy; it is not a universal owner of all application business permissions. This example uses only a supplied maintenanceClosed predicate. The edge checks that selected policy before its public cache decision. No vendor rule set, attack detector, or actual WAF result is executed.

A load balancer selects eligible targets, while a reverse proxy can create an upstream request/response relationship behind a client-facing connection. One component may hold both roles. The combined fixture chooses app-b because a is observed unready. CDN, WAF, balancer, and proxy are not four mandatory physical appliances. TLS may terminate at an edge; upstream security context needs separate policy. Success at one hop proves neither the next connection nor handler completion.

The runtime hands a received request to application decisions

Node http.Server exposes request information such as IncomingMessage method, url, and headers; it does not automatically create a router or permission policy. The runtime represents request bytes at its parser/API boundary, while application routing maps method/path to an operation. /notes/tea and view=compact are separate path/query components. The selected route carries a public note identifier and presentation choice; an upstream header alone does not verify a principal.

Middleware order changes ordinary behavior. Middleware may inspect request/response objects, add context, end a cycle, or pass control to a later handler. Express is a named example of that model; the native fixture does not execute Express. Here a public-purpose predicate runs before fixed method/path matching and service reading. Middleware control transfer is local processing rather than an HTTP packet.

The origin branch ends when the handler prepares a Tea note result; response delivery to the browser has not been shown. In the cache-hit branch, originCalls remains zero and the client parses cached public bytes only after arrival. Maintenance closure produces edge403, while an ordinary missing route produces runtime404. They have different failure owners. Request semantics, selected status, representation bytes, and completion boundary stay distinct in the ledger.

Read every scenario without motion

Cache and closure

Public GET plan
The request is GET /notes/tea?view=compact with bodyBytes 0 and fragmentSent false. H1Projection is explanatory notation, not a network capture.
Request/result ledger
Public GET / no body / no fragment
Policy and execution gate
Not yet evaluated
Owner outcome
Not yet evaluated
Cache fast path
cacheHit has policyAllowed/publicContract true and supplied age 2 below lifetime 5. Its callOrder contains policy/cache-hit only, with zero origin and service calls.
Request/result ledger
Public GET / no body / no fragment
Policy and execution gate
Cache hit / origin0 / service0
Owner outcome
Not yet evaluated
Do not count 200 as a handler call
Cached 200 comes from edge-cache. Adding handler or database reads invents events for the fast path; public caching proves no private-object authority.
Request/result ledger
Public GET / no body / no fragment
Policy and execution gate
Cache hit / origin0 / service0
Owner outcome
Cached200 / no handler evidence
Maintenance gate
The closed branch runs only policy and returns 403 with forwarding false. This selected edge-policy outcome is not labelled application authorization denial.
Request/result ledger
Policy closure /403 / service0
Policy and execution gate
Cache hit / origin0 / service0
Owner outcome
Cached200 / no handler evidence
Ordering scope
This adapter evaluates policy before cache. Other vendors are not assigned this ordering, and the normal public cache contract remains explicit.
Request/result ledger
Policy closure /403 / service0
Policy and execution gate
Selected policy ordering / not universal
Owner outcome
Cached200 / no handler evidence
Retain the authority owner
Edge allowance carries normal public purpose, not a principal or note-level grant. Source and serviceCalls are read together; status alone proves neither authority nor execution.
Request/result ledger
Policy closure /403 / service0
Policy and execution gate
Selected policy ordering / not universal
Owner outcome
Status + source + calls / authority separate

Route boundary

Ready app-b selection
Normal miss has app-a false and app-b true, selecting app-b. Public purpose and route matching follow selection; receiver knowledge is not equated with the prior plan.
Request/result ledger
app-b selected / route gate follows
Policy and execution gate
Not yet evaluated
Owner outcome
Not yet evaluated
Service-result preparation
Normal callOrder ends in service-read with one call and a 31-byte JSON body. Handler-result preparation does not imply delivery to the client.
Request/result ledger
app-b selected / route gate follows
Policy and execution gate
Service1 / result prepared / client not shown
Owner outcome
Not yet evaluated
Route miss is another branch
The missing path yields runtime-router 404 and serviceCalls 0. The route decision is not an independent claim about object absence or private permission.
Request/result ledger
app-b selected / route gate follows
Policy and execution gate
Service1 / result prepared / client not shown
Owner outcome
Route404 / no service read
In-process-hop boundary
Middleware, router and service can be local operations in one adapter. Separate names do not prove separate sockets, TLS hops or database packets.
Request/result ledger
Local calls ≠ remote protocol hops
Policy and execution gate
Service1 / result prepared / client not shown
Owner outcome
Route404 / no service read
Retain failure scope
Edge403, cached200 and route404 have different result sources. Adding normal service-read to missing traces hides failure boundaries.
Request/result ledger
Local calls ≠ remote protocol hops
Policy and execution gate
Edge/cache/router owners distinct
Owner outcome
Route404 / no service read
Prepared-result boundary
This example is public reading without persistence commit or client rendering. Gateway success does not become proof of write commit or TLS verification.
Request/result ledger
Local calls ≠ remote protocol hops
Policy and execution gate
Edge/cache/router owners distinct
Owner outcome
Public result only / commit and render separate

ASSUMPTION · BOUNDARY · CONTROL

Edge acceptance is not object permission

The normal purpose is to carry a public request to a suitable upstream. The necessary control is a decision by the correct policy owner for that request purpose and application operation. Treating WAF allow as an authenticated principal or note-level authorization shifts a trust boundary. Every successful representation here is explicitly public; edge caching is not claimed to authorize private object access. Private policy stays with WEB-15 and the next capstone.

The control states which operation may use the public cache path, checks the maintenance predicate separately even on a normal hit, and limits upstream identity assumptions to trusted endpoint context. That order is selected fixture policy, not a universal vendor execution guarantee. Incorrect cache classification can affect representation scope; this example neither shares a private response nor probes a real site.

Do not invent handler evidence before handoff

A cache hit has zero service reads. Adding a runtime log or database read anyway invents an event in the observation chain. Maintenance closure also stops at the edge; its selected403 is not the same evidence as an application authorization denial. An ordinary missing route reaches the runtime but does not call the service. Status alone cannot distinguish these branches for detection or debugging.

The control separates prepared upstream requests from receiver arrival: proxy state cannot announce that a runtime has seen a request in advance. In-process routing and middleware calls do not become extra network hops. Failure scope stays attached to route match, policy closure, or cache source. This prevents labeling every transient error compromise, every404 object absence, or gateway success persistence commit.

Read every scenario without motion

Source controls

Normal-order record
Normal order is policy, cache-miss, select app-b, public-purpose, route-match and service-read. Each local gate is associated with the same public request.
Call/result ledger
Normal six-stage adapter order
Execution comparison
Not yet evaluated
Coverage outcome
Not yet evaluated
JSON-byte verification
The application/json result carries id tea and title Tea note, with UTF-8 count 31. Decoding and byte length are distinct checks; Content-Type does not guarantee parsing.
Call/result ledger
Normal six-stage adapter order
Execution comparison
id tea / title Tea note /31 byte
Coverage outcome
Not yet evaluated
Zero-call controls
Cache hit has policy/cache-hit, closed only policy, and route miss public-purpose/route-miss. All record zero service calls with different sources and statuses.
Call/result ledger
Normal six-stage adapter order
Execution comparison
id tea / title Tea note /31 byte
Coverage outcome
Recorded zero calls / distinct causes
Recipient-scope record
Origin result is prepared at the handler; edge cache holds another owner representation. Client delivery, framework runtime and real HTTP capture are not added to adapter records.
Call/result ledger
Prepared handler result / client outside scope
Execution comparison
id tea / title Tea note /31 byte
Coverage outcome
Recorded zero calls / distinct causes
Selector contradiction
The selector detects edge-cache with serviceCalls above zero. Normal hit gives zero and an inconsistent control one; missing-record zero cannot establish healthy execution.
Call/result ledger
Prepared handler result / client outside scope
Execution comparison
Zero-match needs coverage / positive control retained
Coverage outcome
Recorded zero calls / distinct causes
Persistent review question
Public cache contract, middleware order and result source are retained together, separating correct public body, execution owner and delivery stage behind a 200.
Call/result ledger
Prepared handler result / client outside scope
Execution comparison
Zero-match needs coverage / positive control retained
Coverage outcome
Body/owner/delivery evidence distinct

Call evidence gap

Status200-only view
The review knows only status 200 without source or callOrder. Cache and service can return the same status, so handler execution cannot be inferred.
Call/result ledger
200 known / source/calls missing
Execution comparison
Not yet evaluated
Coverage outcome
Not yet evaluated
Zero versus missing
Recorded serviceCalls 0 is a known result, not missing data. Writing either zero or one into an incomplete event invents execution evidence.
Call/result ledger
200 known / source/calls missing
Execution comparison
Missing count ≠ verified zero
Coverage outcome
Not yet evaluated
Leave owner outcome unknown
Response source, service count and client receipt remain UNKNOWN. Even a correct status does not establish body correctness or application-policy results.
Call/result ledger
200 known / source/calls missing
Execution comparison
Missing count ≠ verified zero
Coverage outcome
Source/calls/client receipt UNKNOWN
Required call context
Method/target, cache source, selected app, route result and safe call counts are needed. Request correlation binds these owners without raw credentials.
Call/result ledger
Needed: request/source/target/route/calls
Execution comparison
Missing count ≠ verified zero
Coverage outcome
Source/calls/client receipt UNKNOWN
Separate body evidence
Expected Tea note JSON is not the body of a missing event. Title success requires separate representation receipt, decoding and content checking.
Call/result ledger
Needed: request/source/target/route/calls
Execution comparison
Expected JSON ≠ observed body
Coverage outcome
Source/calls/client receipt UNKNOWN
Boundary of new evidence
New evidence must identify the status owner and executed work. This event retains only 200, adding no handler, database or client-success claim.
Call/result ledger
Needed: request/source/target/route/calls
Execution comparison
Expected JSON ≠ observed body
Coverage outcome
Retain200 / collect scoped execution evidence

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Verify the operation chain through receiver knowledge

Carry method, target, and public purpose from the client plan to edge knowledge only on arrival. Record edge policy, cache source, selected application, and runtime route matching separately. A diagnostic correlation alias is not a credential; select output-safe operation fields instead of raw headers or session values. The ordinary baseline uses the same public note and bounded compact query, not arbitrary target or route discovery.

The owned adapter observes actual call order: policy, cache decision, replica selection, fixed routing, and service reading. The cached branch uses only policy and cache. Independently decoded public JSON verifies id/title; representation length counts UTF-8 bytes. These are direct adapter results. Proxy buffering, sockets, TLS, HTTP2 frames, and framework middleware execution need separate observations before becoming evidence.

Zero calls differ from missing observations

An explicitly observed serviceCalls0 identifies a no-handler branch. Absence of a log record does not support the same conclusion. Preserve result source for selected403, cached200, and route404; WEB-21.02 supplies the related no-ready upstream case. Availability, edge policy, and application semantics then avoid one generic failure box. Unchanged application state is verified only for this selected ordinary read fixture.

An XPath over own XML selects source=edge-cache with serviceCalls>0. A benign hit matches zero, a deliberately inconsistent record matches one, and absence remains insufficient evidence. Durable control binds the public cache contract to an operation, makes middleware order observable, and states handler side-effect boundaries. Avoiding an equation between response completion and business commit is the bridge to the next lesson.

NOW APPLY IT TO THE CASE

Does a 200 or 403 prove the handler ran?

For the same public note, a cache hit returns 200 with serviceCalls 0. Maintenance closes at the edge with 403, while a route miss returns runtime 404. A normal miss selects ready app-b and prepares a 31-byte JSON result; client delivery is beyond this example.

Which cache owner supplies the case representation? Evaluate key scope, freshness and viewer context together; a hit does not establish the correct viewer.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Public request handoff ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "request": {
    "method": "GET",
    "target": "/notes/tea?view=compact",
    "host": "public.example.invalid",
    "publicPurpose": true,
    "bodyBytes": 0,
    "fragmentSent": false,
    "h1Projection": "GET /notes/tea?view=compact HTTP/1.1\r\nHost: public.example.invalid\r\nAccept: application/json\r\n\r\n",
    "projectionNotCapture": true
  },
  "origin": {
    "policyAllowed": true,
    "cacheHit": false,
    "ready": [
      {
        "id": "app-a",
        "ready": false
      },
      {
        "id": "app-b",
        "ready": true
      }
    ],
    "selected": "app-b",
    "callOrder": [
      "policy",
      "cache-miss",
      "select:app-b",
      "public-purpose",
      "route-match",
      "service-read"
    ],
    "serviceCalls": 1,
    "result": {
      "status": 200,
      "mediaType": "application/json",
      "body": "{\"id\":\"tea\",\"title\":\"Tea note\"}",
      "bodyBytes": 31,
      "source": "service"
    },
    "endsAt": "handler result prepared; client response not shown"
  },
  "cacheHit": {
    "policyAllowed": true,
    "publicContract": true,
    "currentAge": 2,
    "freshnessLifetime": 5,
    "callOrder": [
      "policy",
      "cache-hit"
    ],
    "serviceCalls": 0,
    "originCalls": 0,
    "result": {
      "status": 200,
      "body": "{\"id\":\"tea\",\"title\":\"Tea note\"}",
      "source": "edge-cache"
    },
    "ageIsSupplied": true
  },
  "closed": {
    "maintenanceClosed": true,
    "callOrder": [
      "policy"
    ],
    "status": 403,
    "source": "edge-policy",
    "forwarded": false,
    "serviceCalls": 0,
    "policyNotVendorRule": true
  },
  "routeMiss": {
    "method": "GET",
    "target": "/notes/missing?view=compact",
    "callOrder": [
      "public-purpose",
      "route-miss"
    ],
    "status": 404,
    "source": "runtime-router",
    "serviceCalls": 0
  },
  "limits": {
    "realHttp": false,
    "realCdn": false,
    "realWaf": false,
    "realLoadBalancerProxy": false,
    "expressRuntime": false,
    "tlsHopVerified": false,
    "privateAuthorizationVerified": false
  },
  "selector": {
    "language": "XPath",
    "xml": "<audit><response source=\"edge-cache\" serviceCalls=\"0\"/></audit>",
    "xpath": "count(/audit/response[@source='edge-cache' and number(@serviceCalls)>0])",
    "expected": 0,
    "positiveFixtureXml": "<audit><response source=\"edge-cache\" serviceCalls=\"1\"/></audit>",
    "positiveExpected": 1,
    "scope": "Own inert decision observations, not real vendor logs.",
    "missingFieldBehavior": "Missing observation is insufficient evidence, not a proven healthy or authorized result."
  }
}

request: H1 semantics projection, not an actual capture.
origin.callOrder: Observed ordinary control order in an owned adapter.
cacheHit: Public stored representation and selected freshness predicate.
closed / routeMiss: Edge policy and runtime routing have different failure owners.

Fixed synthetic example; protocol edges are conceptual, and local execution evidence has a separate scope.

Two reality checks

WAF allow or gateway200 establishes application permission.

Request filtering and routing do not replace private object authorization.

Every successful request reaches a handler and database.

A suitable public cache hit may skip the origin; invoked components require separate evidence.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

A public cache candidate has currentAge=2 and freshnessLifetime=5. Is the service handler called on this cache-hit branch?

Yes. Cache hit is only a log label; the service always runs.
No. serviceCalls=0 and originCalls=0.

Read the explained answer

No. serviceCalls=0 and originCalls=0. — After policy evaluation, the fresh public cache hit prepares an edge-cache response without reaching the handler.

Which application is selected after a cache miss, and does this trace also show the client receiving the body?

Selected lesson artifact fields; teaching example

origin.ready: [{"id":"app-a","ready":false},{"id":"app-b","ready":true}]
origin.selected: app-b
origin.callOrder: ["policy","cache-miss","select:app-b","public-purpose","route-match","service-read"]
origin.endsAt: handler result prepared; client response not shown

app-b is selected; the trace ends at a prepared handler result.
app-a is selected; a prepared 200 guarantees delivery to all clients.

Read the explained answer

app-b is selected; the trace ends at a prepared handler result. — app-a has ready=false and app-b ready=true. The service result is prepared, but client response delivery is not shown.

Maintenance 403 and route-miss 404 both have serviceCalls=0. Why are they neither the same rejection boundary nor a private-authorization test?

Read the explained answer

Maintenance stops forwarding at edge-policy, while route-miss finds no match at the application router. Neither calls the service, but different owners make the decision. This is a public-purpose request, not verified private subject/object authorization. The HTTP/1.1 text is a representation rather than a packet capture, and no real CDN/WAF/framework runs.

□ I distinguished the owners producing 403 and 404.

□ I did not treat public routing as private-authorization evidence.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RFC 9110 — HTTP Semantics3.3. Connections, Clients, and Servers · 3.7. Intermediaries · 7.1. Determining the Target Resource · 9.3.1. GET
AWS CloudFront — delivery roleHow CloudFront delivers content to your users
AWS WAF — named request-policy exampleWhat is AWS WAF?
NGINX — proxy module, current docsproxy_pass
Node.js v26.11.1 — HTTPClass: http.IncomingMessage · message.url · message.method
Express — Using middleware (framework example only)Using middleware · Application-level middleware · Router-level middleware
RFC 9111 — HTTP Caching4. Constructing Responses from Caches · 5.2.2.9. public
RFC 9113 — HTTP/2 frames4.1. Frame Format
RFC 9114 — HTTP/32. HTTP/3 Protocol Overview
OWASP — AuthorizationIntroduction

YOUR NOTES / THIS BROWSER

From HTTP to a handler

1. Core · Mechanism

Origin handler

Public cache hit

Edge policy block

No route match

An HTTP request is not shared knowledge across boxes

The runtime hands a received request to application decisions

2. Red · Trust & Impact

Cache and closure

Route boundary

Edge acceptance is not object permission

Do not invent handler evidence before handoff

3. Blue · Secure development & defense

Source controls

Call evidence gap

Verify the operation chain through receiver knowledge

Zero calls differ from missing observations

Does a 200 or 403 prove the handler ran?

Two reality checks

A public cache candidate has currentAge=2 and freshnessLifetime=5. Is the service handler called on this cache-hit branch?

Which application is selected after a cache miss, and does this trace also show the client receiving the body?

Maintenance 403 and route-miss 404 both have serviceCalls=0. Why are they neither the same rejection boundary nor a private-authorization test?

Sources and scope