Draft Validation & Release

Drafts in a Relex case progress through phases. Each phase produces a new draft revision (a GCS blob generation). Partners can validate any revision, and one revision can be tagged as "Released" when the partner marks the case delivered.

Three states

Every draft revision has exactly one of these badges in the version dropdown:

  • Released (green) — the canonical version the partner stands behind. Only one Released revision per draft. Set when the partner clicks Mark Delivered.
  • Validated by {N} (blue) — partners who reviewed and approved this specific revision. Multiple partners can validate the same revision.
  • Unvalidated (grey) — no partner has signed off. Newly created revisions start here.

Validation

A partner with read access to the case can validate any draft revision via the document viewer. The validation is recorded in documentValidations and denormalized onto the draft document's validatedGenerations[] array.

Validation requires:

  • Caller is an accepted partner on the case
  • The specific draft generation must still be readable in GCS (not pruned)

Release

When the partner marks delivery (POST /v1/partnerPayments/{id}/mark-delivered), the latest revision validated by that partner becomes the released version. Server-side it sets:

drafts/{draftId}.released = {
  releasedPhaseId,
  releasedDraftGeneration,
  releasedAt,
  releasedByPartnerId,
  releasedByPartnerName
}

Subsequent edits to the draft create new revisions that are automatically Unvalidated (no badge migration). The Released badge does NOT move forward unless a new partner validates a newer revision and re-marks delivery.

Why this design

  • Atomicity: a single released pointer means the case owner always knows which version "carries weight"
  • Auditability: validatedGenerations[] preserves the entire validation history with partner attribution
  • Disputes: if a dispute opens, the operator can compare the released revision to subsequent edits
  • No retroactive changes: once released, a revision's hash is locked into the validation history

Edge cases

  • Multiple partners on a case — each validates independently. The released version belongs to the partner who clicks Mark Delivered.
  • Partner deletes profile — historical validatedGenerations[] entries remain (with the displayName cached at write time), but the partner no longer appears in the directory.
  • Draft generation is pruned by GCS lifecycle — the validation history persists; the dropdown shows the badge but the body cannot be loaded.