# Draft Validation & Release - Relex Partner Program

> How partners validate AI-generated drafts and tag the released version when marking delivery.

#### On this page

- [Three states](#clause-2)
- [Validation](#clause-3)
- [Release](#clause-4)
- [Why this design](#clause-5)
- [Edge cases](#clause-6)

# 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.

---

_[View this page on relex.legal](https://relex.legal/docs/partner-program/draft-validation)_
