Campaign / Gig Lifecycle

The state machine every gig moves through, from posting to payout. This is the backbone the data model, notifications, and payment triggers all hang off of.

States

DRAFT
  │  (hirer saves brief but hasn't published)
  ▼
OPEN
  │  (published; visible in marketplace; accepting pitches, or a direct offer sent)
  ▼
PITCHED / OFFER_SENT
  │  (creator has applied, or hirer sent a direct offer)
  ▼
NEGOTIATING            (optional loop: counter-offers on rate/scope/timeline)
  │
  ▼
HIRED / ACCEPTED
  │  (both sides agreed; escrow funded — see 08-payments-escrow.md)
  ▼
IN_PROGRESS
  │  (creator working; milestone checkpoints if applicable)
  ▼
SUBMITTED
  │  (creator delivers; hirer review window starts)
  ├──► REVISION_REQUESTED ──► (back to IN_PROGRESS, within revision cap) ──► SUBMITTED
  ├──► DISPUTED ──► (admin mediation — see 07-trust-safety.md) ──► resolved into APPROVED or REFUNDED
  ▼
APPROVED
  │  (hirer approves, or auto-approve timeout elapses — see below)
  ▼
COMPLETED
  │  (escrow released to creator, minus platform commission)
  ▼
[REVIEWED]  (both sides leave reviews — can happen any time after COMPLETED, doesn't block payout)

Terminal/exception states: CANCELLED (before HIRED, no funds moved), REFUNDED (dispute resolved in hirer's favor, funds returned minus any dispute-resolution fee policy), EXPIRED (gig posted but never received a pitch/offer within its listed window).

Key rules and edge cases

• Auto-approval window: if a hirer doesn't explicitly approve or dispute within N days (recommend: 5–7 days) of SUBMITTED, the gig auto-transitions to APPROVED and funds release. Protects creators from hirers going silent post-delivery — one of the most common real-world complaints from creators.
• Revision cap: the brief specifies how many revision rounds are included (default suggestion: 1). Requesting a revision beyond the cap requires a mutually agreed scope/rate amendment, not a unilateral hirer demand — this is enforced at the product level, not just a policy statement, to actually prevent scope creep.
• Milestone gigs: larger engagements can split HIRED → COMPLETED into multiple milestone sub-cycles, each with its own escrow-funded amount and its own submit/approve/dispute loop. A milestone gig is "COMPLETED" only when all milestones are.
• Multi-creator campaigns: one campaign can spawn multiple independent gig instances (one per hired creator), each running its own lifecycle, rolled up under a shared campaign view for the hirer.
• Cancellation policy: cancelling before HIRED is free. Cancelling after HIRED but before work has meaningfully started may involve a partial cancellation fee to compensate the creator's committed time (specific policy TBD with legal/ops — flagged here as a required decision, not fully speced).
• No-show/non-response handling: if a creator accepts a gig (HIRED) but goes unresponsive past the brief's timeline with no delivery, the hirer can cancel and reclaim escrowed funds after a defined grace period, and the creator's reliability score takes a reputation hit.

Notification triggers (non-exhaustive, informs features docs)

Every state transition above should fire a notification to the relevant party: new pitch received, offer sent, offer accepted, deliverable submitted, revision requested, approval/payment released, dispute opened, deadline approaching (T-24h reminder), auto-approval window closing soon.