Account-free review

A deterministic file goes out. A much smaller file comes back.

The application replaces scattered email wording with a portable package and a response tied to exact versions. Transfer still happens through a channel chosen by the creator.

The seven-step loop

Author the brief.
The creator defines context, reviewer lanes, selection rules, and preview settings.
Prepare inert previews.
Supported inputs are inspected and rasterized or re-encoded locally. Originals remain untouched.
Export a recipient package.
Small sets can use one self-contained HTML file. Larger sets use a .reviewpack, which requires the separate Reader page. Generate one exact distribution per reviewer while keeping them in the same round.
Transfer it yourself.
Use an agreed file-transfer method. The product does not email, host, or revoke packages.
The recipient reviews.
Self-contained HTML can run directly after transfer. A .reviewpack can run offline only after Reader and its bundled assets were first loaded and cached over HTTPS or localhost. Decisions, favorites, comments, pins, and rectangles remain in the active browser session until saved.
The recipient returns .review.json.
The compact response has no source or preview image bytes.
The creator reconciles and iterates.
Valid returns are retained as response lanes and old-version bindings remain exact stale history. Open tasks and unresolved reviewer threads shape the follow-up package.

What each file is for

File	Created by	Purpose	Persistence
`.reviewproject`	Creator app	Versioned project backup with generated derivatives and checksums.	Portable, checksum-verified backup file; restore requires an intact file and compatible app release.
`.html`	Creator app	Bounded single-file recipient review.	Portable, but cannot be revoked.
`.reviewpack`	Creator app	Larger recipient data package selected in the separately available Reader.	Portable data, but not standalone, encrypted, or revocable.
`.review.json`	Reader/client package	Draft or completed structured feedback.	Explicit response record; not authenticated.

Why separate packages help attribution

Each export receives a distribution identifier. Separate exports make reviewer handoffs easier to attribute. Within a distribution, the same responseId with a higher responseRevision is an amendment; a new responseId starts independent response history. The round selector reconciles all exact distributions in one round. Report bundles keep a separate folder and checksum set for each distribution and normally use one ZIP, but bounded exports may produce numbered ZIP parts. Sending one copy to a group still works, but attribution becomes ambiguous because there is no account or identity service.

Labels are not identities.

Reviewer slot, display name, reference, and device time are self-entered or device-provided. They do not establish amendment lineage; responseId does. The manifest digest detects mismatch or corruption, not who authored a response.

Versions never inherit approval

Every decision binds to the exact version, recorded source filename, and page included in the package. The filename is recorded after NFC Unicode normalization and outer-whitespace trimming. When a creator replaces an asset, prior decisions remain old-version response data and cannot become current approval. The follow-up builder includes assets with open tasks or unresolved reviewer threads and warns before resending a version that has not changed.

Choose a sensible transfer channel

The application does not assess whether email, a removable drive, a general file-transfer service, or an existing client portal is appropriate for a project. Exported packages are not encrypted or access-controlled by this product and can be copied. Follow the confidentiality arrangements applicable to your work.