Study selected-action visibility at named HTTP observation points.
Compare an implicit decision, an explicit response signal, and a signal removed at a boundary. Report the observation point with every result.
| Question | Measurement lens | Why it matters |
|---|---|---|
| Can a component see it? | Decision visibility | Distinguishes a hidden decision from a received signal. |
| Can the decision be recovered? | Reconstructability and ambiguity | Measures what observations reveal about the underlying decision. |
| Do components resolve the same token? | Consistency | Separates token agreement from interpretation or correctness. |
| What does signaling cost? | Bytes and latency | Evaluates benefit together with overhead. |
The experiment asks whether a component can recover an already-selected action from its local HTTP observations. It evaluates visibility, not whether the action was correct or a security control was effective.
Methodology source: Rachid Bouziane’s OODA-HTTP D1 Measurement Protocol work, July 2026. This public overview was published on 25 October 2026; it is a summary of the project’s experimental method, not a versioned reproduction package or an IETF-endorsed methodology.
A traffic generator sends requests through an edge and a gateway to a Python decision application. The application records the selected action as ground truth. Gateway and edge observations are evaluated separately.
The experimental vocabulary is allow, monitor, throttle and filter. Responses use 200 OK to isolate the field’s contribution to visibility. This experimental control is not deployment guidance.
Application, gateway and edge logs are joined by request ID. Counts, duplicates, missing observations and ground-truth matches must be accounted for before aggregation.
| Mode | Application | Gateway and edge |
|---|---|---|
| Implicit | Records the selection without emitting the field. | No selected-action token is provided through this field. |
| Explicit | Emits the selected-action field. | The field is preserved for observation at both points. |
| Strip | Emits the selected-action field. | The gateway observes it; the field is removed before reaching the edge. Correct removal is checked against logs. |
Decision visibility: the proportion of evaluated requests with a valid selected-action token visible at a named observation point. Each result must state its denominator and treatment of missing records.
Reconstructability: the proportion of evaluated requests for which the declared reconstruction rule recovers the application’s recorded selection. A result of zero under a token-only rule is not proof that every possible inference method must fail.
Candidate set and ambiguity: |C(R)| counts the actions compatible with the declared observation model. This overview uses A(r) = |C(R)| − 1. Earlier analysis labelled candidate-set size itself as A; the definitions must be reconciled before comparing numbers.
Uncertainty: four equally likely candidates correspond to 2 bits; a single candidate to 0 bits. These are model-based values under a uniform assumption, not automatically empirical conditional entropy estimates. Knowledge of the path, policy or workload can change the candidate set.
Token consistency: compare resolved tokens, including unknown values, for correlated requests at different components. Agreement does not establish decision correctness. A difference caused by intentional stripping is reported with its boundary context.
Overhead: compare response-byte counts and latency under stated conditions. Body-length counters do not measure response-header overhead. Timing conclusions require repeated observations and accounting for connection setup and other confounding factors.
The project uses backend_decisions.log, nginx2_gateway.log and nginx1_edge.log, with an analysis script identified as analyze_logs.py. A reproducible result needs the matching log snapshot, analyzer version, mode counts, join rules and calculation definitions.
A 150-request experiment has been reported in the project’s earlier work. A separate preliminary document records three requests, one per mode. These are distinct experimental records. Numerical results will be presented with their run-specific scope once the source summaries and metric definitions have been reconciled.
This page publishes the methodology overview. It does not distribute the internal review documents or claim that the complete dataset has been independently reproduced.