01 — APPLICATION AUTHORIZATION
The application protects access.
In the authorization scene, application rules deny Alice's unauthorized read or export. C is not invoked in this scene.
OODA-HTTP / Engine & lab
Architecture
Follow the responsibilities of the application, C assessment process, and reporting recipient.
Architecture
Separate the responsibilities.
Connect the evidence.
A decision, permission to execute it, an actual effect, and a report about that effect are different claims. The demonstration examines application authorization, completed evidence and advisory reporting as separate responsibilities.
02 — POST-REQUEST ASSESSMENT
C examines completed evidence.
In a separate routing scene, a pinned Python controller projects evidence into a frozen C subprocess through stdin/stdout. It assesses agreement, disagreement or uncertainty.
03 — OPTIONAL REPORTING
A recipient records the selection.
A later local mTLS/HTTP exchange can carry an advisory token. The CLI recipient parses and records it; no executor applies a control.
These are separate demonstration tracks. The reporting exchange does not feed the application's authorization check. C is a local subprocess, not an HTTP gateway.
Where does the OODA loop fit?
Observe collects evidence; Orient provides context; Decide selects an assessment or response; Act requires an authorized execution path. Memory, adjustment, and cooperation extend the design. Their presence in a design does not establish that every path is implemented or validated.
Purpose-based comparison
Compare roles.
Then compare evidence.
These approaches can coexist. This is a conceptual map of primary roles, not a product benchmark or a claim of superior attack coverage.
| Approach | Primary role | Relationship to this project |
|---|---|---|
| WAF | Inspect web traffic and apply configured protections. | A potential control point whose decisions and effects need observation. |
| SIEM | Aggregate and correlate security telemetry for investigation. | A potential consumer of evidence and reported signals. |
| SOAR | Coordinate response workflows and integrated actions. | A possible execution integration, subject to explicit authority. |
| Application authorization | Decide whether an actor may perform a specific operation. | The source of the access denials in the demonstration application flow. |
| OODA Engine | Explore contextual decision and evidence assessment. | A research prototype evaluated through bounded cases and explicit evidence. |
| Enforcement-Action | Report an advisory action through an HTTP response field. | A signaling proposal, not an engine or security product. |