What QCDS Freezes When a Request Is Sent

When Send Now succeeds, QCDS creates an immutable Request snapshot and SHA-256 integrity manifest. That transaction preserves the exact source, documents, fields, participants, routing, policy, message, timing, and related send-time evidence used for that Request.

Send Now Is the Transaction Boundary

Before Send Now succeeds, the streamlined Prepare & Send workflow is still preparation. After authoritative validation and request authorization pass, QCDS creates the immutable Request, freezes its snapshot and integrity manifest, records their hashes, protects the referenced document storage, activates the first routing stage, and queues the currently active signer invitations.

What the Frozen Snapshot Contains

The snapshot preserves the transaction data needed to reproduce what was actually sent, including:

  • the source Template/version identity and source snapshot information when a Template was used;
  • the exact document versions and protected storage references;
  • the builder items/fields, their geometry, properties, required state, assignments, and supported linked-field relationships;
  • the participant projection, including frozen participant/contact details, role, language/time-zone context, and whether Identity Verification was required;
  • the routing graph and stage rules;
  • request policy, branding, invitation/completion message source, variables, and timing/deadline settings; and
  • other frozen builder content such as assets, clauses, stamps, or seals when present.

Temporary access tokens, signer sessions, signatures, audit events, and completion artifacts are deliberately not part of the starting draft snapshot. Those are transaction results that accumulate after send.

How QCDS Protects the Frozen State

QCDS canonicalizes the snapshot and computes a SHA-256 snapshot hash. The integrity manifest separately hashes the Template source, each document version, every field/builder item, and projections of the participants, routing, policy, branding, message, timing, and variables. The Request stores both the snapshot hash and manifest hash.

If Identity Verification is required, QCDS also binds each required participant to the exact provider profile resolved at send time and records the Request snapshot hash and document-association hash with that verification record.

Later Edits Do Not Rewrite the Sent Request

Changing the reusable Template, a saved Contact, workspace defaults, email templates, or future provider settings does not rewrite the immutable Request snapshot. A Contact correction made after signing can update the live Contact for future work, but the participant snapshot and final values in the completed Request remain the historical evidence.

What Can Still Change After Send

Immutability does not mean the Request stops progressing. Delivery attempts, signer sessions, field values, signatures, Identity Verification results, routing events, timeline/evidence records, and completed artifacts are stored as transaction activity around the frozen snapshot. They document what happened without replacing the original send-time state.

Verify the Freeze

For a controlled test, send a Request, then change the source Template or Contact. Reopen Request Details and confirm the sent transaction still shows its original participants and document/field context. The timeline should also contain the snapshot-frozen event with the immutable snapshot and manifest hashes.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCDS feature? Visit the QC Digital Signature Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.