{
  "schemaVersion": 1,
  "source": {
    "release": "v1.0.4",
    "sourceCommit": "9c252fcc583641341b44ba5ca8b7434a6ff0a165",
    "completed": "2026-11-04",
    "reproductionGuide": "https://docs.routesphere.global/how-to/reproduce-bounded-benchmark/",
    "claimBoundary": "Vendor-produced, checksum-bound and release-matched evidence. Read each stage boundary before using a result."
  },
  "stages": [
    {
      "stage": "A",
      "label": "Release identity and installation",
      "title": "Can an operator verify and install the exact public release?",
      "risk": "A gateway cannot create value if an evaluator cannot identify the right bytes, verify their publisher or complete a clean installation without hidden account dependencies.",
      "test": "We downloaded the public assets anonymously, verified their recorded identities and signatures, then followed the Debian, OCI and Console installation paths on fresh Ubuntu 24.04 AMD64 hosts.",
      "outcome": "Anonymous retrieval and fresh installation worked across the published Gateway, OCI and Console paths without requiring a RouteSphere account.",
      "proof": "16/16 public assets verified. Stage A passed 18/18 contract tests and 4/4 native phases on Ubuntu 24.04 AMD64. Debian and OCI paths served traffic; Console Free completed first-administrator bootstrap and local HTTPS login.",
      "trust": "The tests pinned exact SHA-256 identities, used disposable hosts, retained failed attempts and verified the final service state instead of treating a successful installer exit as proof.",
      "boundary": "This proves the named installation paths and artifact identities. It is not formal requalification of every future package, platform or operating environment."
    },
    {
      "stage": "B",
      "label": "Functional replay",
      "title": "Does v1.0.4 perform the functions claimed by the release?",
      "risk": "Feature lists can hide untested negative paths, policy interactions and configuration transitions that only fail after traffic reaches production.",
      "test": "We drove positive and negative traffic through the exact release, exercised its routing and policy surface, and completed a validate-preview-apply-ACK/NACK-rollback lifecycle while checking what the data plane actually served.",
      "outcome": "The exact release was exercised as a gateway, policy enforcement point and immutable configuration target rather than accepted from documentation alone.",
      "proof": "17/17 cases passed: HTTP/1.1, HTTP/2, routing, load balancing, health, admission, overload, API key, JWT, source IP, CORS, content policy, transformations, rewrite, redirect, retry/circuit behavior and validate-preview-apply-ACK/NACK-rollback.",
      "trust": "Every case had an exact expected status, body, header or lifecycle outcome. Release, snapshot and fixture identities were checksum-bound, and rejected configuration was required to leave the last-known-good state active.",
      "boundary": "Functional qualification does not establish maximum throughput, every protocol extension or correctness for configurations outside the tested contracts."
    },
    {
      "stage": "C",
      "label": "Matched operating behavior",
      "title": "What happens as offered traffic approaches the tested envelope?",
      "risk": "A gateway may return every request and still violate the latency budget that protects a customer experience, especially as queues form near a workload boundary.",
      "test": "We ran one active product at a time on the same 24-CPU allowance, used eight client lanes and two controlled upstreams, rotated product order, and repeated fixed offered rates with identical TLS, payload and transformation intent.",
      "outcome": "The important observation was not only successful traffic. It was whether correctness, tail latency and resource gates remained stable across repetitions.",
      "proof": "At 480K offered RPS, BonVoyage and NGINX each passed 3/3 C03 repetitions. At the supplemental 600K point, all 216 million measured requests succeeded; BonVoyage passed the p99 gate 3/3 and NGINX 1/3.",
      "trust": "Acceptance required correct semantics, zero unexpected errors or timeouts, reconciled counts, bounded resources and both p95 and p99 at or below 500 ms. Returning HTTP 200 alone could not turn a rejected tail into a pass.",
      "boundary": "Shared-EC2 directional evidence at fixed offered rates. It is not maximum capacity, dedicated-host sizing, universal superiority or infrastructure-cost proof."
    },
    {
      "stage": "D",
      "label": "Policy cost",
      "title": "What does security and policy enforcement cost before production?",
      "risk": "Authentication and protection features are valuable only if teams understand their latency, CPU and memory cost before they size or expose a service.",
      "test": "We measured API-key, RS256 JWT and a realistic twelve-component policy path against payload-matched controls at fixed rates, while also checking the exact allow and reject semantics.",
      "outcome": "API-key, JWT and composed-policy paths were measured against matched controls so operators can see latency, CPU and memory increments rather than assume them.",
      "proof": "D01-D03 retain 18 accepted measurements. D03 completed 3/3 control and 3/3 twelve-component policy repetitions, all six semantic cases, 8.64 million measured requests, zero unexpected errors and zero gateway restarts.",
      "trust": "The controls used the same transport and payload, all repetitions had to reconcile, and the actual composed path was measured directly. Independent API-key and JWT costs were not added together to manufacture a result.",
      "boundary": "Fixed-rate BonVoyage feature-cost evidence. D03 is not a comparator, saturation test or global cross-node quota qualification."
    },
    {
      "stage": "E",
      "label": "Protocol lifecycles",
      "title": "Do long-lived and multiplexed protocols clean up correctly?",
      "risk": "A protocol checkbox can prove only that a connection opens. Production risk appears in metadata, frames, cancellation, deadlines, slow consumers and resources that fail to drain.",
      "test": "We treated unary gRPC, WebSocket and SSE as complete lifecycles, covering success, malformed input, metadata or frames, concurrency, cancellation, deadlines, timeout and recovery over their supported transports.",
      "outcome": "Protocol support was tested as a lifecycle: success, metadata or frames, cancellation, deadlines, cleanup and same-process recovery.",
      "proof": "Unary gRPC passed 11/11 cases, WebSocket passed 8/8 semantic groups, and SSE passed 12/12 HTTP/1.1 and HTTP/2 cases. Final active gauges drained to zero with no gateway restart.",
      "trust": "Each contract pinned the release binary and fixtures, required the same process before and after, bounded retained RSS and descriptors, verified final active gauges at zero and independently checked the evidence manifest.",
      "boundary": "Unary gRPC only, not streaming gRPC. These are bounded functional and lifecycle results, not multi-shard protocol capacity or universal production-scale evidence."
    },
    {
      "stage": "F",
      "label": "Failure, overload and recovery",
      "title": "Does the gateway fail deliberately and recover without hiding the transition?",
      "risk": "Upstream faults, overload and rejected configuration can create retry amplification, transport errors, stale resources or mixed state that is worse than a deliberate bounded rejection.",
      "test": "We injected a dropped upstream response, drove intentional admission overload, verified same-process recovery, and replayed the NACK, exact rollback and corrected-activation sequence under retained traffic checkpoints.",
      "outcome": "The replay verified bounded upstream failure, explicit overload shedding, same-process recovery and configuration rejection without partial activation.",
      "proof": "F01 bounded attempts and recovered the same BonVoyage, NGINX and Envoy processes. F02/F03 returned 399 HTTP 200 plus 401 bounded HTTP 503 responses during intentional overload, then 80/80 successes after recovery for each system. F04 verified all 67 retained files and the NACK, exact rollback and corrected activation sequence.",
      "trust": "The runner retained rejected attempts, forbade transport failure and restart, reconciled BonVoyage rejection counters with client-visible HTTP 503s, and independently rechecked every file in the configuration-lifecycle evidence.",
      "boundary": "The admission mechanisms differ and are not equivalent. The tests do not establish global quotas, continuous availability, multi-node atomicity or a universal recovery ranking."
    },
    {
      "stage": "G",
      "label": "Observability failure isolation",
      "title": "Does telemetry trouble become traffic trouble?",
      "risk": "A slow, absent or rejecting telemetry collector should not silently block application traffic, leak request data into labels or leave exporters permanently wedged.",
      "test": "We exercised Prometheus scrape decisions and privacy, collector loss with 24 slow readers, tenant-isolated canary failure, and OpenTelemetry rejection, queue overflow, propagation and recovery.",
      "outcome": "Prometheus and OpenTelemetry failure paths were exercised to verify bounded loss, privacy decisions, queue behavior and recovery without changing the gateway process.",
      "proof": "G01 verified scrape decisions, rules and label privacy. G02 retained healthy traffic during Prometheus loss and 24 slow readers. G03 accounted for collector rejections, queue overflow, dropped/exported spans and recovery to zero queue depth without a gateway restart.",
      "trust": "The three captures are tied to the exact v1.0.4 image and clean harness source, every embedded manifest verifies, privacy markers were checked at the collector, and recovery required the same gateway process.",
      "boundary": "Supplemental local-engineering evidence only. It does not authorize a performance, production SLO, billing-grade telemetry or universal collector-compatibility claim."
    }
  ]
}