Proof at the execution boundary
Live governed traffic, mixed allow and deny decisions, freshness-window replay enforcement, and recovery under pressure.
This page summarizes completed hosted proof captures against the live boundary without expanding the claim beyond what the runs proved.
This page shows measured behavior of the PFC execution boundary under real hosted traffic.
PFC is a request governance layer that sits between a system and an AI provider, enforcing allow or deny policy at the execution boundary before execution commits.
This page provides live proof of AI governance at the execution boundary, including replay protection, policy enforcement, and measured behavior under load.
Hosted Proof Summary
Runs captured: April 3-5, 2026
PFC was tested live at the hosted execution boundary under normal governed traffic, mixed allow and deny traffic, duplicate-nonce and stale-timestamp replay probes, and stress with recovery. The hosted boundary remained stable under load, deny behavior stayed consistent, stale timestamps were rejected, duplicate x-pfc-nonce reuse was rejected within the enforced gateway replay scope at /v1/evaluate, and the system recovered after peak pressure.
These captures hit the live hosted /v1/evaluate route and are limited to the currently hosted execution boundary.
A live hosted baseline using governed traffic only, where governed traffic means requests evaluated against policy at the execution boundary before execution commits. This established normal latency and throughput without mixing in replay probes or malformed traffic.
A live hosted run that mixed likely-allow and likely-deny governed requests, meaning inputs intended to exercise both sides of the policy decision surface, to confirm deny behavior stayed stable and no unexpected permissiveness appeared under load.
A low-risk replay-related probe that intentionally used stale timestamps to verify the freshness-window boundary on the hosted route, alongside a controlled duplicate-nonce validation within the same hosted /v1/evaluate scope.
A higher-pressure hosted run with a controlled recovery phase to measure tail latency under pressure and whether the system returned toward baseline afterward.
x-pfc-nonce reuse was rejected within the enforced gateway replay scope./v1/evaluate.x-pfc-nonce rejection within the enforced gateway replay scope.The hosted pfc-api.fly.dev boundary requires replay-protection headers, rejects stale timestamps outside the allowed freshness window, and rejects duplicate x-pfc-nonce reuse within the enforced gateway replay scope at /v1/evaluate.
Largest p99 values here reflect tail latency under saturation conditions already discussed in the disclosure.
Baseline Governed Load
Mixed Governed Load
Replay Freshness Probe
Stress With Recovery
The baseline run had 9 timeouts at 50 concurrency over 120 seconds. The baseline run also had a long p99 latency tail, and the stress run had a much larger p99 tail under peak pressure. These latency tails occurred under load saturation and did not result in incorrect accepts, control bypass, or loss of replay enforcement. Recovery returned cleanly after the stress phase. Replay wording on this page is intentionally narrow and exact because the hosted proof captures support stale-timestamp rejection and duplicate x-pfc-nonce rejection within the enforced gateway replay scope, but do not support broader duplicate request ID or exact transport replay claims.
All requests hit the real hosted /v1/evaluate route. The harness used real governed traffic modes, including a mixed lane with likely-allow and likely-deny requests plus controlled stale-timestamp and duplicate-nonce probes. No broader hosted replay claim is made here beyond stale-timestamp rejection and duplicate x-pfc-nonce rejection within the enforced gateway replay scope.
/v1/evaluate scope, stale timestamps and duplicate x-pfc-nonce reuse were rejected.This page reflects the currently hosted boundary and is intended to show exact measured behavior, not a broader future-state claim.