Bounded execution.
Visible uncertainty.

Start / Boundaries of hosted GET checks

Existing accounts can use Contract checks; new registrations remain paused. An organization Owner supplies OpenAPI 3.0 JSON, selects up to ten supported public unauthenticated GET requests, provides required inputs and explicitly authorizes the frozen checks. Follow the hosted quickstart.

The target requires an exact expiring DNS TXT proof. Domain control is separate from legal permission to test and from execution isolation. Changed inputs, target or proof require renewed review. Current session and organization permissions are checked before admission and target requests; a visible control is not authorization.

These checks use trusted code through the private gateway, not generated code or model tools. Target requests are limited to the reviewed HTTPS requests, with public DNS address checks, connection pinning, blocked redirects and finite time and response-size limits. Unsupported requests fail closed; they are not silently included.

Reports omit response bodies, concrete request paths and supplied values. Schema failures may name a field from the pinned document, without showing its value. Missing schemas, missing evidence and unexercised success paths remain explicit. This does not establish comprehensive sensitive-data classification or semantic completeness.

The flow sends GET requests only and provides no write or cleanup workflow. A server can still attach side effects to a GET endpoint; domain proof and a passing result do not establish reversibility. Use only targets and requests you are authorized to exercise.

01 / Generated output stays untrusted

Configuration and test-writing roles have separate inputs and output contracts. Trusted code freezes the configuration, derives integrity hashes, type-checks and compiles the pack, and verifies it against an independently constructed documentation simulator before promotion.

The simulator receives the normalized documentation contract, not test assertions or customer credentials. Passing it is rehearsal evidence only. Assertions that require actual target behavior remain explicitly deferred.

The worker retains the model-provider key. Generated code uses logical actor names and does not receive raw stored credential bindings. Local generation tools and unsafe development execution are not production containment.

02 / Authority belongs outside the test

Execution approval identifies the exact generated revision, target and policy. Review shows allowed operations and actors, possible writes, request limits, timeouts and the cleanup plan. New or changed authority requires review; generated output cannot grant itself permission.

Target requests pass through a private per-run gateway that enforces the compiled target, method and endpoint allowlist and request ceiling. The gateway resolves stored actor credentials in trusted code. There is no direct customer-network route from the qualified execution sandbox.

Revocation blocks new test traffic while permitting cleanup of already recorded resources. Credentials and approval snapshots preserve the authority the run started with. Execution approval is separate from account authentication and proof of target ownership.

03 / Report effects, including unresolved ones

Known resource creations are recorded in a durable ledger outside the test process. Cleanup is attempted in reverse creation order, including after failure or cancellation, and its outcome is reported separately from test success.

An uncertain write, missing resource identity, failed deletion or unresolved containment issue requires attention. The system does not blindly replay uncertain writes. Human reconciliation is recorded as operator testimony, distinct from an observed successful removal.

Safe creation-to-cleanup mappings must be explicitly supported and reviewed. This does not guarantee zero leftover resources, reversibility of every API effect or detection of every sensitive value.

04 / Current release and customer-execution gates

Firebase owns Google/email-password identity. The API exchanges a recent verified identity token for an HttpOnly, host-only session cookie, Secure in production. Tokens are held in client memory during sign-in; session registrations are hashed in PostgreSQL.

Organizations own product records. The API checks current membership, roles, ownership and revocation, scopes idempotency keys by organization and route, and requires exact trusted origins for mutations. A visible UI control or a cookie-presence check is not an authorization boundary.

Firebase mode is the default and fails closed if unconfigured. Explicit local fixture authentication is non-production only. Neither that operator API mode nor the local inspector may be publicly exposed.

Rootless Podman has a locally qualified Linux execution profile. It shares the host kernel and is not production-qualified. The explicit local-process provider has no isolation and is only for trusted fixture development; it must never run customer workloads.

Protected configuration-owned assertions and hosted shared artifact storage are implemented, including expiring DNS domain-control verification. Before public self-service generated-code customer execution, the release still needs policy editing, comprehensive sensitive-data redaction and production isolation qualification. Credential provisioning, key rotation and backup/restore qualification remain deployment requirements.

Saved local bindings are encrypted using a checkout-local installation key. Losing that key makes those bindings unreadable. Hosted services require separately provisioned durable key material and shared artifact storage; a deployment alone does not prove key rotation or backup recovery. Reports and transcripts can contain request data, so keep them private and redact evidence before sharing.

These are current release requirements, not permission to bypass them by widening an allowlist. Read the hosted GET-check quickstart for the supported account flow, or the local quickstart for generated-pack evaluation within the owned fixture boundary.