PUBLIC RELEASE EVIDENCE / VERSION 1.0.4
Your team can examine the software before buying maintenance. Version 1.0.4 publishes reviewable evidence alongside the exact distributed artifacts.
01 / CycloneDX + SPDX
Check which components and versions are included in the package or image you intend to run, including recorded licenses and inventory coverage.
What this does not prove: An SBOM is an inventory, not a vulnerability assessment or a compliance certificate.
02 / Vulnerability assessments
Read the scanner and database dates, assessed artifact, known findings, reviewed dispositions and recommended fixes. Later assessments should remain linked to the same artifact.
What this does not prove: A scan is a point-in-time assessment. Zero reported findings does not mean zero vulnerabilities.
03 / Fuzzing + correctness tests
Inspect the tested targets, sanitizer configuration, execution duration, outcomes and known coverage gaps. Distinguish newly executed tests from reused evidence.
What this does not prove: Test coverage reduces uncertainty; it cannot establish that every input or execution path is safe.
04 / Soak + RSS + descriptors
Compare absolute memory use and growth, file-descriptor trends, process identity and restart count alongside workload, duration and error rate.
What this does not prove: Flat RSS in one soak does not establish unlimited capacity or leak-free behavior for every workload.
05 / Overload + recovery
Review which failures were injected, what clients observed, how recovery was checked and which upgrade or rollback paths were exercised.
What this does not prove: Results apply to the tested scenario. Not every change is restart-free or reversible.
06 / Digests + provenance
Match the distributed package or image to its digest, source and build identity, and verify publication signatures against a trusted publisher policy.
What this does not prove: A valid signature authenticates an issuer and binds bytes; it does not prove that software or a report is correct.
POST-RELEASE REPLAY / STAGES A-G
Each stage answers a customer question. The story starts with the operational risk, shows what was tested, reports what happened and explains why the retained evidence deserves scrutiny rather than blind trust.
STAGE A / Release identity and installation
Customer outcome: Anonymous retrieval and fresh installation worked across the published Gateway, OCI and Console paths without requiring a RouteSphere account.
The 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.
What we tested: 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.
What happened: 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.
Why this is trustworthy: 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 / Functional replay
Customer outcome: The exact release was exercised as a gateway, policy enforcement point and immutable configuration target rather than accepted from documentation alone.
The risk: Feature lists can hide untested negative paths, policy interactions and configuration transitions that only fail after traffic reaches production.
What we tested: 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.
What happened: 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.
Why this is trustworthy: 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 / Matched operating behavior
Customer outcome: The important observation was not only successful traffic. It was whether correctness, tail latency and resource gates remained stable across repetitions.
The 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.
What we tested: 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.
What happened: 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.
Why this is trustworthy: 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 / Policy cost
Customer 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.
The risk: Authentication and protection features are valuable only if teams understand their latency, CPU and memory cost before they size or expose a service.
What we tested: 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.
What happened: 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.
Why this is trustworthy: 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 / Protocol lifecycles
Customer outcome: Protocol support was tested as a lifecycle: success, metadata or frames, cancellation, deadlines, cleanup and same-process recovery.
The 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.
What we tested: 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.
What happened: 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.
Why this is trustworthy: 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 / Failure, overload and recovery
Customer outcome: The replay verified bounded upstream failure, explicit overload shedding, same-process recovery and configuration rejection without partial activation.
The 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.
What we tested: 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.
What happened: 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.
Why this is trustworthy: 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 / Observability failure isolation
Customer outcome: Prometheus and OpenTelemetry failure paths were exercised to verify bounded loss, privacy decisions, queue behavior and recovery without changing the gateway process.
The risk: A slow, absent or rejecting telemetry collector should not silently block application traffic, leak request data into labels or leave exporters permanently wedged.
What we tested: 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.
What happened: 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.
Why this is trustworthy: 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.
Vendor-produced, checksum-bound and release-matched evidence. Read each stage boundary before using a result.
KUBERNETES LIFECYCLE SUPPLEMENT / NOVEMBER 5, 2026
The public main source completed all six disposable lifecycle phases, with 54 / 54 focused tests passing.
What we tested: A clean-source installation, two-replica baseline, zero-unavailable configuration upgrade, malformed-candidate rejection, exact rollback, and complete teardown.
What happened: A malformed configuration candidate was rejected while both healthy replicas and service traffic remained available. The deployment then returned to the exact baseline revision and the disposable environment was removed.
Why this is trustworthy: The replay started from an anonymous clone of the exact public main commit, built controlled local images from that clean source, pinned kind and its Kubernetes node image, and checked behavior after every transition.
Boundary: Source-built lifecycle evidence on disposable kind with Ubuntu 24.04 AMD64. It is not a tagged-artifact installation result, benchmark, capacity result, multi-node availability claim, or release-admission record.
READ THE RESULT IN CONTEXT
A useful record names the package or image digest, platform, source/build identity, tool versions, execution date, tested workload and known limits.
For load and soak tests, read successful traffic, errors, CPU, absolute RSS, resource growth and duration together. A small memory increase alone does not establish a small memory footprint.
Passed, failed, not run, reused, not applicable and execution error are different outcomes. Publication approval is a separate decision from a passing individual test.
Historical benchmarks remain dated comparisons, not automatic claims about a newer binary. Security assessments can change after release as new information becomes available.
PUBLIC TRUST / OPTIONAL MAINTENANCE
Generic artifact verification, dependency inventories, public advisories and reviewed test summaries ship with the public release. The US$10,000/year Assurance subscription adds continuing supported-line maintenance, eligible remediation and direct notices under a direct-agreement model. Supported programmatic management and its API documentation are a separate Enterprise capability. Sales enquiries are open; contracting scope and terms are confirmed in writing.
It does not purchase a security guarantee, unlimited capacity, regulatory approval or a human incident-response SLA.
Understand Release Assurance