FAQ for teams, operators, and institutions.

Receiz is a verification primitive with one authoritative artifact: the file. A verify link (/v) is optional public convenience for that same file. Verification is public and deterministic.

Both. The file is the source of truth. Verify links (/v) are optional public convenience for that same file.

The file is the sealed file carrying embedded verification material. It can be a claim record, document/media artifact, or package file depending on flow.

Share the file (or package ZIP). That is what verifies. Share the verify links (/v) only when optional public convenience is needed.

Offline Studio is the standalone on-device runtime for Record, Seal, and Verify. It generates verifiable artifacts locally and preserves original file format behavior for sealing flows.

Yes. Record, Seal, and Verify are all offline-capable. Verification remains deterministic from file bytes, and does not require a network call.

No. Account access is optional and not required for offline Record, Seal, or Verify.

Accounts add authenticated authorship, custody surfaces (Archive and Received), profile publishing, messaging, team collaboration, and ownership workflows.

Trusted signing material is provisioned to the device. Once provisioned, the offline runtime can keep issuing trusted offline Record and Seal outputs on that device.

Use the Offline Verifier HTML. It is the canonical offline verification reference and runs locally without account access.

Use Record Moment (/record) for moment claims, or Seal File (/seal) for files/folders. Keep returned file bytes unchanged.

Yes. Receiz supports common document/media formats, generic binaries, and package/folder flows.

Verify from file bytes, online or offline. Matching files verify; altered copies fail.

Screenshots fail. Originals verify. A screenshot does not carry embedded verification material.

Verification checks whether embedded proof data still matches the file bytes and record fields. If anything changes, verification fails.

Tampering breaks bindings. Verification rejects because the file no longer matches the issued record.

Yes. Verify runs fully offline. The offline verifier checks integrity locally with no network calls and enforces the same deterministic bundle checks.

Yes. Record, Seal, and Verify all run offline. No account is required for offline operation.

No. Account access is optional. It adds custody, profile publishing, messaging, and billing surfaces, but is not required for offline Record, Seal, or Verify.

Trusted verification requires signatureV4 because it verifies canonical payload hash, root-key policy, device certificate chain, certificate validity window, and final payload signature. This hard-fail path blocks unsigned, out-of-policy, expired-cert, or tampered bundles.

No. Verification is public and free. Plans unlock authorship, custody, and operational controls.

No account required for Record, Seal, or Verify. Accounts add authenticated authorship, Dashboard custody (Archive and Received), profile publishing, chat/messages, team collaboration, and ownership workflows.

Sealed files in custody surfaces: Archive for your records, Received for opened external records with context.

Authorship + custody controls: signatures, co-signers, claim threads, visibility controls, and AssetSeal custody workflows.

AssetSeal issues one verifiable origin record, then appends custody/authorship events without rewriting origin.

Existing records remain valid and verifiable. Verification is never gated by plan.

Receiz ID is passwordless account access. Passkey (WebAuthn) is default, and email magic-link is fallback or alternate login method. Both methods resolve to one account identity.

No. If a user is new, Receiz automatically creates the account on first successful passkey or magic-link login.

Yes. Passkey-only onboarding is supported. Email can be added later, and magic-link will then resolve to the same Receiz account.

They sign in to the same account. Passkey and email do not create separate users.

Yes. Once email is linked to that profile, future magic-link sign-ins route to the same Receiz identity.

Receiz signs the recipient in via magic-link. If the recipient is new, Receiz creates the account during that flow. After signing, they can use passkey or email to access the same account.

Map local users by OIDC `sub` (stable subject). Treat email as mutable profile data. This prevents identity split when users switch between passkey and email.

Create and manage OIDC clients in Receiz Connect, then implement Authorization Code flow with PKCE using discovery metadata.

WireProof is the Pro operations rail for payment proofs: sealed file plus verifier URL/QR.

API/webhooks, structured claims, batch issuance, delegated issuers, and org archive/export. Verification remains public.

No. Signing is optional and used when workflows require human-origin witness attestations.

Yes. Unsigned demo flows are available. Signed/operational controls require account + plan entitlement.

Use Standards for canonical schema boundaries, trusted signature v4 profile requirements, error contracts, and conformance vectors.

Use Developers for endpoint contracts, offline record/seal/verify integration patterns, and trusted signature v4 verification policy details.

Use Trust for policy posture and route links, then Status for live operational reliability.

Use Status for live route health and incident visibility.