Request Path Comparison
Live Lab
Live telemetry / measurement scope / metric definitions
The Live Lab compares two request paths under the same workload: a conventional path that activates application and database infrastructure before the provider decision, and a provider-first path that places the provider admissibility decision before downstream application activation.
The question under test is:
How much infrastructure activates before the provider can say no?
The Lab measures request ordering, provider visibility, rejection timing, pre-denial activation, database interaction, and resource behavior. It is a controlled comparison environment, not a model of every production architecture.
Paths Under Test
Conventional Path
Client → intermediary/gateway → application activation → database/context interaction → provider decision → allow/deny
The request reaches application and database infrastructure before the provider makes the admissibility decision.
Provider-First Path
Client → provider-first boundary → verifier/provider admissibility decision → application activation only if allowed → response
The provider decision occurs before downstream application activation.
Both paths were constructed specifically for this experiment. The conventional path is a representative request ordering used as the comparison baseline; it is not an instrumented third-party product or production system.
The provider-first path is likewise a test implementation. The paths are intentionally arranged differently. The experiment measures the operational consequence of placing the provider decision at different points in the request path under equivalent request intent and workload conditions.
It does not claim that all conventional or provider-first systems use these exact architectures.
Measurement Notes
Workload
Both paths use the same load-generation environment, workload patterns, request types, metrics schema, dashboard, and outcome vocabulary.
Traffic displayed by the Lab is generated by the comparison harness. Valid and invalid counters describe the workload presented to the two paths. They do not represent unsolicited Internet traffic.
Run Scope
The Live Lab was introduced after the original Live Challenge had already operated for approximately 43 days and processed more than one billion requests. Introducing the Lab required restarting the Challenge; that earlier Challenge traffic is not included in the Challenge's current cumulative counters.
The Lab experienced several resets during its initial deployment. Its current cumulative run begins after the July 14, 2026 incident, when two obsolete Path Comparison processes on the shared host generated approximately 143 GB of error logs and the Lab failed.
The Challenge's NUVL and provider processes continued operating through the incident; the Lab did not.
The obsolete processes were removed before the current Lab run. Dashboard totals apply to this post-incident run.
Deployment
The Live Lab and NUVL Live Challenge share a general-purpose DigitalOcean droplet.
CPU, RAM, throughput, latency, and availability measurements characterize this shared deployment. They are not dedicated-host performance benchmarks.
Telemetry
Request-path measurements are generated by the instrumented services. Container CPU and memory measurements are collected by the host sampler.
The dashboard retains compact rolling telemetry. Full per-request payloads are not retained by the dashboard.
System State
- Conventional Path
- Current operating status of the conventional request path.
- Provider-First Path
- Current operating status of the provider-first request path.
- Verifier
- Current operating status of the service responsible for the provider admissibility decision.
- Database
- Current operating status of the database/context service used by the comparison environment.
Service health indicates whether the measured components are operating. It does not establish that request ordering or decision behavior is correct.
Throughput
- Current RPS
- Recent aggregate request rate observed by the comparison environment.
- Total Requests
- Total requests accounted for during the current Lab run.
- Conventional
- Requests processed through the conventional path.
- Provider-First
- Requests processed through the provider-first path.
- Valid
- Requests generated with workload conditions intended to satisfy the comparison's admissibility requirements.
- Invalid
- Requests generated with workload conditions intended to be denied.
The current workload can be intentionally denial-heavy or entirely invalid. These counters describe generated comparison traffic, not unsolicited attack volume.
Provider Timing
- Conventional Provider Seen At
- Elapsed time before the provider/verifier is reached through the conventional path.
- Provider-First Provider Seen At
- Elapsed time before the provider/verifier is reached through the provider-first path.
- Conventional Rejection Time
- Elapsed request time before denial completes on the conventional path.
- Provider-First Rejection Time
- Elapsed request time before denial completes on the provider-first path.
Provider-seen timing measures when the provider decision point becomes involved. Rejection timing measures when the denial completes.
These are separate measurements. Reaching the provider does not mean the request has completed.
Database Activation
- Conventional DB Before Denial
- Whether the conventional path reaches the database/context service before provider denial.
- Provider-First DB Before Denial
- Whether the provider-first path reaches the database/context service before provider denial.
- Conventional DB Count
- Cumulative measured conventional requests that reached the database before denial.
- Provider-First DB Count
- Cumulative measured provider-first requests that reached the database before denial.
A database touch means the database/context service was activated before denial. It does not, by itself, mean data was returned, disclosed, or exfiltrated.
This panel reports whether pre-denial database activation occurred and the cumulative number of measured occurrences.
Path Comparison
The latency panel compares rejection-time distributions for the two request paths.
- Average
- Arithmetic mean of measured rejection times.
- p50
- Median rejection time.
- p95
- 95th-percentile rejection time.
- p99
- 99th-percentile rejection time.
These measurements characterize this workload, implementation, and deployment. They are not generalized latency guarantees for NUVL, provider-first architectures, or conventional systems.
Denial Behavior
- Conventional Denials
- Requests denied through the conventional path.
- Provider-First Denials
- Requests denied through the provider-first path.
- Conventional Timeouts
- Conventional-path requests that did not complete within the test timeout.
- Provider-First Timeouts
- Provider-first requests that did not complete within the test timeout.
Equal denial outcomes do not imply equivalent execution paths.
A request can produce the same final denial on both paths while activating different infrastructure before that result is established.
Pre-Denial Activation
- Conventional DB Touches Before Denial
- Conventional-path denials for which database/context interaction occurred before rejection.
- Provider-First DB Touches Before Denial
- Provider-first denials for which database/context interaction occurred before rejection.
This panel presents database activation specifically as a side-by-side comparison outcome. The Database Activation panel above reports the corresponding path state and cumulative counts.
Did downstream infrastructure become involved before the provider established that the request was admissible?
Container Telemetry
- Conventional CPU / RAM
- Resource use attributed to the conventional-path container.
- Provider-First CPU / RAM
- Resource use attributed to the provider-first-path container.
- Shared CPU / RAM
- Resource use attributed to services shared by the comparison environment.
- Total CPU / RAM
- Combined resource measurement reported for the monitored comparison environment.
Container telemetry is collected by the host sampler. It is operational telemetry, not an authorization result.
Because the Live Lab shares its host with the Live Challenge and supporting processes, these measurements characterize this deployment rather than isolated component performance.
Scope
The Live Lab is an observability surface for an instrumented request-path comparison.
Within this environment it records:
- when the provider/verifier becomes involved;
- when denial completes;
- whether database/context infrastructure activates before denial;
- the number of pre-denial database interactions;
- rejection-time distributions;
- timeout behavior; and
- container resource behavior.
The comparison does not establish:
- that every conventional architecture performs work in this order;
- that every provider-first implementation will produce the same measurements;
- that database activation constitutes disclosure or exfiltration of data;
- generalized performance outside this workload and deployment;
- endpoint-local enforcement;
- physical actuation;
- durable replay protection or persistent bounded-authority consumption; or
- resistance to compromise of the provider or its signing material.
Those properties require separate tests and, where applicable, separate enforcement and observation points.
Source and Reproduction
The Live Lab is an observation surface. The implementation and reproduction material are published.
Do not infer the result from the dashboard labels. Inspect the paths. Inspect the instrumentation. Reproduce the comparison.