Skip to content
arch v1.0.0

Use Cases — Deal Negotiation

Status: Implemented · Last updated: April 2026

These use cases have been fully implemented. The live system uses the offers → negotiations → deals domain model rather than the generic Party A / Party B abstraction described here.

reference, and domain.md for the current schema.

This document is preserved as the UC spec that drove the implementation.

Actors

ActorDescription
Party AThe inviting party; typically a brand or campaign owner
Party BThe invited party; a streamer or content creator with published minimum terms
SystemAutomated transitions, validations, and event logging

UC-01 · Publish Minimum Terms

Actor: Party B
Precondition: Party B is registered and has no active minimums, or wishes to update them.
Trigger: Party B submits their minimum required values across all term dimensions.

Main flow

  1. Party B provides values for all five term dimensions: timeframe, deliveries, min_viewers, min_duration, payment_per_stream.
  2. System validates that all values are positive numbers.
  3. System stores the TermSet as Party B.publishedMinimums.
  4. System appends an ActivityEvent of type minimums_published.

Postcondition

Party B is now discoverable and can receive invitations.

Exceptions

  • E1: Any value is zero or negative → system rejects with a validation error.

UC-02 · Send Invitation (Party A initiates)

Actor: Party A
Precondition: Party B has published publishedMinimums. Campaign exists in active status.
Trigger: Party A selects Party B from a campaign and submits an initial proposal.

Main flow

  1. Party A selects a campaign and a target streamer (Party B).
  2. System retrieves Party B's publishedMinimums and surfaces them to Party A.
  3. Party A provides proposed values for all five term dimensions.
  4. System validates that each proposed value ≥ the corresponding minimum in Party B's publishedMinimums.
  5. System creates an Invitation with status pending and the provided TermSet.
  6. System creates a Negotiation with status invited and initialises one NegotiatedTerm per dimension using the proposed values, with approvedByA = true, approvedByB = false, and version = 1.
  7. System appends an ActivityEvent of type invitation_sent.
  8. Party B receives a notification.

Postcondition

A Negotiation in status invited exists. Party A's initial values are pre-approved by A.

Exceptions

  • E1: Any proposed value < the corresponding minimum → system rejects with a per-field error.
  • E2: Campaign is not active → system blocks invitation creation.
  • E3: A Negotiation between this Party A and Party B for this campaign already exists → system blocks duplicate.

UC-03 · Accept Invitation

Actor: Party B
Precondition: A Negotiation with status invited exists and is addressed to Party B.
Trigger: Party B reviews the initial proposal and chooses to enter negotiation.

Main flow

  1. Party B views the initial proposed terms alongside their own publishedMinimums.
  2. Party B clicks "Accept invitation".
  3. System updates Invitation.status to accepted.
  4. System transitions Negotiation.status to negotiating.
  5. System appends an ActivityEvent of type invitation_accepted.

Postcondition

Negotiation is in status negotiating. Party B may now act on individual terms.

Exceptions

  • E1: Party B declines → Invitation.status = declined, negotiation does not proceed.

UC-04 · Approve a Term

Actor: Party A or Party B
Precondition: Negotiation.status = negotiating. The actor has not yet approved this term in the current version.
Trigger: The actor accepts the current proposed value for a specific term dimension.

Main flow

  1. Actor selects a NegotiatedTerm and clicks "Accept".
  2. System sets approvedByA = true or approvedByB = true on that term (per actor identity).
  3. System appends an ActivityEvent of type term_approved with the dimension in the payload.
  4. System checks whether all NegotiatedTerm records now have both approvedByA = true and approvedByB = true.
  5. If yes → system executes UC-07 Transition to Waiting for Funding.

Postcondition

The term's approval flag is set for the acting party.

Exceptions

  • E1: Actor has already approved this term at the current version → system is idempotent, no duplicate event is logged.
  • E2: Negotiation is not in negotiating status → action is blocked.

UC-05 · Counter-Propose a Term

Actor: Party A or Party B
Precondition: Negotiation.status = negotiating. The proposed value has not been jointly approved yet.
Trigger: The actor disagrees with the current value and submits a new one.

Main flow

  1. Actor selects a NegotiatedTerm and opens the counter-proposal form.
  2. System displays the current value and the minimum floor (NegotiatedTerm.minimumValue).
  3. Actor enters a new proposed value and submits.
  4. System validates: new value ≥ minimumValue.
  5. System updates NegotiatedTerm.proposedValue to the new value.
  6. System sets approvedByA = false and approvedByB = false on this term only.
  7. System sets proposedBy to the acting party's role.
  8. System increments Negotiation.currentVersion by 1.
  9. System appends an ActivityEvent of type term_countered with dimension, old value, and new value in the payload.
  10. The other party receives a notification that a counter has been proposed.

Postcondition

The term's approval state is reset. Both parties must re-approve this term at the new value.

Exceptions

  • E1: New value < minimumValue → system rejects with validation error.
  • E2: New value equals the current proposed value → system rejects as a no-op.

UC-06 · View Negotiation State

Actor: Party A or Party B
Precondition: A Negotiation exists and the actor is a party to it.
Trigger: Actor opens the negotiation view.

Main flow

  1. System retrieves the Negotiation including all NegotiatedTerm records and ActivityEvent history.
  2. System resolves which terms are approved, pending, or countered.
  3. System surfaces:
    • Current status and version.
    • Per-term proposed value, minimum, and approval state for both parties.
    • Which actions are available to the current actor (approve, counter, or none).
    • Chronological activity log.

Postcondition

Actor has a current view of the negotiation without mutation.


UC-07 · Transition to Waiting for Funding

Actor: System (triggered by UC-04)
Precondition: Every NegotiatedTerm in the negotiation has approvedByA = true AND approvedByB = true.

Main flow

  1. System transitions Negotiation.status from negotiating to waiting_for_funding.
  2. System appends an ActivityEvent of type all_terms_agreed.
  3. System notifies Party B that the deal is ready to fund.

Postcondition

No further counter-proposals or approvals can be submitted. Only the funding action is available to Party B.


UC-08 · Fund the Deal

Actor: Party B
Precondition: Negotiation.status = waiting_for_funding.
Trigger: Party B initiates the funding action.

Main flow

  1. Party B clicks "Fund the deal".
  2. System requests confirmation from Party B.
  3. Party B confirms.
  4. System records Negotiation.fundedAt = now().
  5. System transitions Negotiation.status to agreed.
  6. System appends an ActivityEvent of type deal_agreed.
  7. System notifies Party A that the deal is live.

Postcondition

Negotiation.status = agreed. The deal is binding. Campaign delivery obligations begin.

Exceptions

  • E1: Actor is Party A → system blocks; only Party B may fund.
  • E2: Status is not waiting_for_funding → action is blocked.

UC-09 · View Activity Log

Actor: Party A or Party B
Precondition: A Negotiation exists and the actor is a party to it.
Trigger: Actor opens the activity log panel.

Main flow

  1. System retrieves all ActivityEvent records for the negotiation in reverse-chronological order.
  2. System renders each event with actor identity, event type, affected term (if applicable), and timestamp.

Postcondition

No mutation; read-only audit view.


Use Case Dependency Map

UC-01 Publish Minimums
    └── enables UC-02 Send Invitation
            └── creates Negotiation → UC-03 Accept Invitation
                    └── status: negotiating
                            ├── UC-04 Approve Term ──────────────┐
                            ├── UC-05 Counter-Propose Term       │ all terms approved
                            └── UC-06 View Negotiation State     │

                                                         UC-07 Transition to Waiting for Funding


                                                         UC-08 Fund the Deal


                                                            status: agreed

Status × Actor × Available Actions

Negotiation statusParty A canParty B can
invitedAccept invitation, Decline invitation
negotiatingApprove unapproved terms, Counter-propose termsApprove unapproved terms, Counter-propose terms
waiting_for_fundingView onlyFund the deal
agreedView onlyView only

Verifluence Documentation