The control boundary should be as reviewable as the output.

Source, reviewers, and final decision remain separate.

• The operator identifies whether the source is AI-generated or human-authored.
• An AI source includes its model and vendor; a human source includes the originating team or role.
• An AI source vendor is excluded before reviewers are assigned.
• Four required lenses complete across at least three model vendors.
• Findings retain their producing lens, vendor, model, and policy version.
• No model resolves or dismisses the findings.
• A person dispositions every finding and makes the final decision.

Strict schemas recheck the applicable source-separation rule and diversity floor after the model calls return. A missing or malformed required lens fails the complete review rather than producing a partial success.

What happens to review content.

1. The browser sends the question, answer, context, and source provenance to /api/review.
2. The server validates the request and rejects detected client identifiers.
3. Vercel executes the request and OpenRouter routes each lens to the assigned model provider.
4. The request sets OpenRouter's per-request ZDR and data-collection-deny controls. OpenRouter documents those controls as routing only to endpoints covered by its Zero Data Retention policy and providers that do not collect user data; handling remains governed by OpenRouter's terms.
5. On the standard workbench path, the completed structured review and an integrity token return to the browser without account storage.
6. On a credit-backed Review path, Neon stores the account-scoped prepared packet, execution and provider metadata, integrity material, and issued findings needed to operate and retrieve the Review.
7. The browser sends the review, dispositions, reviewer fields, and final decision to the attestation endpoint.
8. A firm archive record is stored only when an authenticated firm archive session exists; otherwise the attested record is returned without firm archive storage.

Model providers necessarily receive the review prompt assigned to them. These are OpenRouter routing-policy controls, not a statement that Teranode operates the provider infrastructure.

Who participates in the Service path.

The active reviewer vendors and returned model identifiers are disclosed on each review record. Routing permits only a configured non-PRC provider allowlist and rejects an unrecognized or cross-maker returned model.

Two different integrity checks serve different purposes.

Before attestation, the server verifies an HMAC integrity token over the canonical review payload. This rejects a browser-submitted review that no longer matches the server-issued result.

After attestation, the record carries a SHA-256 fingerprint over its canonical contents. That value supports content comparison. It is not a digital signature, trusted timestamp, or authentication method. It does not prevent later modification or establish who made a change. Check a record.

What the controls do not establish.

• Cross-vendor routing does not prove statistical independence.
• A completed review does not prove that every issue was found.
• A finding does not establish a violation, breach, materiality, best-interest, or compliance conclusion.
• A “No exceptions” result does not approve the source answer for use.
• A record does not determine what a firm must retain or file.
• Identifier detection does not transfer submission responsibility away from the operator or firm.

Evidence available now, assurance not claimed.

Teranode publishes the implemented method, model provenance, security posture, privacy notice, and product limitations. SOC 2 Type II is planned and not yet engaged. No outside assurance report currently covers the Teranode Review service.