Human Review contract limits

Check these limits when building or validating a Human Review request. They describe the v1 contract, not production capacity or service commitments.

Use approved release evidence and signed terms for throughput, retention, availability, and commercial limits.

Version and package boundary

Callback limits

Identifier and metadata limits

Most identifiers are 1–128 characters and use letters, numbers, period, underscore, colon, or hyphen. The environment is 1–32 lowercase letters, numbers, underscores, or hyphens.

The state fingerprint is 64–128 lowercase hexadecimal characters. Correlation metadata supports no more than 16 keys. Each key is 1–64 characters and each value is no more than 256 characters. Outcome reason codes support no more than 16 unique values.

Typed interaction limits

ContextProjection permits up to 64 decision facts, 32 application reference labels, and 32 unavailable-data indicators. Those are upper bounds, not a target. Start with three to six facts and show the most important five first. Application references are opaque labels and correlation handles; they are not VeriProof evidence, session-step IDs, URLs, or links.

Reviewer instructions are optional profile text, limited to 1,000 characters. They are plain text with paragraphs and line breaks; they are not HTML, Markdown, links, templates, or per-request content. Put reusable review criteria in those instructions and put the current action, proposed action, and case-specific facts in the request context.

Date fields use only YYYY-MM-DD. InteractionValidationRule.minimumDate and maximumDate are each nullable DateBoundaryRule values. A boundary is either { mode: "absolute", value: "YYYY-MM-DD" } or { mode: "relative_to_request", offsetDays: integer }. Offsets must be whole days from -3650 through 3650. The server resolves that range once when the case opens, exposes its server-owned resolvedDateBounds to the reviewer, rejects malformed or inverted ranges, and never moves the range while the review remains open.

Reviewer packet freshness

Every reviewer decision sends one presentationDigest. This applies to approve, reject, follow-up, and typed-response decisions. The value is a lowercase hexadecimal SHA-256 hash of the RFC 8785 canonical JSON of the decision presentation the reviewer was shown. VeriProof recomputes the hash when the decision arrives, so an answer can’t be applied to a different request, a changed reviewer brief, or changed evidence.

The old profileDigest, requestDigest, displayProjectionDigest, and evidenceSnapshotDigest fields are removed. A decision that includes any of them is rejected.

If the review changes before the reviewer submits, VeriProof returns HTTP 409 Conflict with the code REVIEW_CHANGED. No decision is recorded. Refresh the reviewer packet, show the current material, and submit against the new presentationDigest. Applications receive the typed response bindings they need to validate their saved request; reviewer instructions, rendered evidence, and other internal packet material are not added to the callback.

A rejection also requires a written reason. A reject decision without one is not recorded.

The 12-field limit applies to every profile version. A profile is a bounded decision surface, not a general form builder. The application-visible response may contain typed field values, permitted replacements, and permitted feedback. The reviewer identity, private review note, raw evidence, prompt history, checkpoint data, protected payload, secrets, and unrelated context are excluded from the callback.

Replacement validation also checks the registered value kind and classification, protected-payload digest, and editable-scope digest. Root replacement, unregistered or sensitive paths, executable expressions, tool-name changes, and add, remove, move, or copy are rejected.

Supported outcomes and states

Outcomes:

• approved
• rejected
• follow_up_required
• response_submitted
• cancelled
• expired

Continuation directives:

• may_resume
• must_not_resume
• remain_paused

Resume modes:

• continue_original
• resume_with_response
• route_to_revision
• none

Valid advancing combinations are approved with continue_original and response_submitted with either resume_with_response or route_to_revision. route_to_revision enters an application-owned revision path and must not execute the superseded protected payload.

Application execution states:

• resumed
• terminated
• remained_paused
• superseded
• failed

Authentication and idempotency

Application calls to VeriProof use an application API key in X-API-Key with review-continuations.write. Credentials are bound to the tenant and application and must be resolved again for every control call after a pause.

Idempotency is scoped by tenant, application, operation, and idempotency key. An exact replay returns the prior result. Reusing a key with a different request hash returns HTTP 409.

What is not defined here

This contract does not publish or promise:

• production throughput or queue depth;
• monthly uptime or response-time commitments;
• recovery time or recovery point objectives;
• retention, residency, or support entitlements;
• production callback rate limits;
• pricing or package upgrades; or
• availability for live customer data.

Use the approved release evidence and signed customer terms for those values.