Use case ยท API infrastructure
Continuous correctness audits for API infrastructure.
For GraphQL routers, gateways, parsers, SDKs, protocol engines, and OSS infrastructure where one edge-case regression can affect many downstream users.
Apollo Router / WunderGraph / Hive style systemsParser, validation, routing, execution, federation, and SDK behavior drift silently across releases.
Founder, maintainer, CTO, platform lead, security owner.
Private reports, reproducible findings, patch verification, and public field notes only when approved.
What Proof checks
Behavior that sits between users and every request.
Inputs, directives, schema behavior, normalization, validation, and edge-case failure modes.
Planner behavior, subscription paths, federation, retries, cancellation, concurrency, and state handling.
Version-to-version behavior changes backed by reproducers and evidence that can run again.
Technical lenses
API infrastructure fails in specific ways.
GraphQL, protocol, schema, and SDK behavior compared against documented expectations.
Subgraph routing, query planning, fallback behavior, and equivalent-operation consistency.
Subscription, defer/stream, timeout, cancellation, and resource-cleanup paths.
Malformed input, invalid state, unknown directives, authorization failures, and fail-closed behavior.
Shared caches, persisted queries, request deduplication, retries, and race-sensitive state.
Recursive input, query fan-out, parser limits, resolver amplification, and memory or CPU ceilings.
Offer
Start with one package, path, or release risk.
- Scope one parser, router, planner, policy, or SDK surface.
- Build a risk model and initial evidence corpus.
- Deliver confirmed findings with reproducers where feasible.
- Set cadence for weekly, per-release, or fast-cycle review.
- Convert strong findings into disclosure-safe field notes when approved.
Engagement mechanics
How this works for OSS and API teams.
| Question | Answer |
|---|---|
| Do you need private repo access? | No, not always. Public-source reviews can start from public code, issues, docs, release notes, and tests. Private access is useful for unreleased paths and customer-specific evidence. |
| How are findings delivered? | Private report first. Public issues, advisories, field notes, or PRs happen only after approval and coordinated disclosure where applicable. |
| Who owns reproducers? | Customer-facing reproducers, regression tests, and report artifacts are inspectable and can be handed off for customer CI or internal regression suites where practical. |
| How much maintainer time? | Initial scoping, access approval, finding review, and patch/retest coordination. Proof should reduce triage load, not create another automated backlog. |
| Can a company sponsor an OSS review? | Yes. The paying company can fund the review while publication and maintainer notification remain coordinated and approval-based. |
Starting point
Bring one request path or release window.
- GraphQL gateways, API routers, SDKs, parsers, planners, and protocol engines.
- Review parser, validation, routing, execution, federation, cancellation, or concurrency behavior.
- Receive confirmed findings with reproducers and regression evidence where feasible.
- Turn critical findings into disclosure-safe field notes only after approval.
Do not submit secrets or private source code here. See Trust.