Structured return file

The response carries decisions, not your artwork.

A .review.json file is a versioned text document that binds client decisions and comments to the exact project, package, asset, version, and PDF page reviewed.

What it contains

Format and schema-version markers.
Project, package, distribution, and base-revision identifiers.
A canonical manifest digest.
A response identifier and amendment revision.
Reviewer slot and optional self-entered display name.
Device-provided creation time.
Version-specific decisions and favorites.
Comments, requested actions, priorities, pins, and normalized rectangles.
A completion summary and acknowledgement state.

No source or preview image bytes belong in a response.

The normal response is small enough to return through an ordinary agreed transfer channel.

Shape of a response

{
  "format": "offline-client-review-response",
  "schemaVersion": 1,
  "projectId": "project:example",
  "packageId": "package:example",
  "distributionId": "distribution:example",
  "baseProjectRevision": 14,
  "manifestDigest": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
  "responseId": "response:example",
  "responseRevision": 1,
  "reviewer": { "slotId": null, "name": "Example reviewer", "reference": "ROUND-1" },
  "status": "draft",
  "createdAt": "2026-08-30T12:00:00.000Z",
  "updatedAt": "2026-08-30T12:00:00.000Z",
  "completedAt": null,
  "decisions": [],
  "favorites": [],
  "threads": [],
  "acknowledged": false,
  "completion": {
    "complete": false,
    "completedUnits": 0,
    "totalRequiredUnits": 1,
    "blockingIssues": ["Cover concept, page 1: choose a review decision."]
  }
}

This example has the complete version 1 field shape, valid field names and types, and a structurally valid 64-character lowercase hexadecimal digest. In a real export, manifestDigest is the SHA-256 hexadecimal digest of the canonical validated package manifest, and completion is calculated from the exact package and feedback. Copying these example values will not make a response importable.

How import protects a project

The creator app parses the entire response before changing storage. It checks data types, identifiers, character and count limits, allowed decisions, page and version relationships, annotation coordinates, prototype-pollution keys, the package manifest digest, and the calculated completion summary.

Wrong project: Rejected.
Changed manifest: Rejected as incompatible or damaged.
Exact duplicate: Idempotent no-op.
Amendment lineage: The same responseId with a higher responseRevision is compared before the creator chooses how to retain it.
Independent response: A new responseId starts separate response history, even when reviewer labels repeat.
Old version: Imported only as stale history.

Reviewer slot, name, and reference are unverified labels. They do not establish amendment identity; responseId does.

What the digest does not prove

The manifest digest detects a mismatch between the response and package it describes. It is not a digital signature, message authentication code, verified identity, trusted timestamp, or tamper-evident legal record. Anyone with the files and enough technical knowledge may alter them.

Use a separate signing workflow when legal acceptance matters.

“Approved for next step” is intentionally an informal production status.

Safe handling

Do not rename the extension to disguise another file type.
Import through the product instead of manually editing the project database.
Keep a portable .reviewproject backup file before reconciling important returns.
Treat names, comments, filenames, and times as untrusted user input.
Do not publish response files; they may contain client feedback and project metadata.