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

Actor	Description
Party A	The inviting party; typically a brand or campaign owner
Party B	The invited party; a streamer or content creator with published minimum terms
System	Automated 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

Party B provides values for all five term dimensions: timeframe, deliveries, min_viewers, min_duration, payment_per_stream.
System validates that all values are positive numbers.
System stores the TermSet as Party B.publishedMinimums.
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

Party A selects a campaign and a target streamer (Party B).
System retrieves Party B's publishedMinimums and surfaces them to Party A.
Party A provides proposed values for all five term dimensions.
System validates that each proposed value ≥ the corresponding minimum in Party B's publishedMinimums.
System creates an Invitation with status pending and the provided TermSet.
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.
System appends an ActivityEvent of type invitation_sent.
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

Party B views the initial proposed terms alongside their own publishedMinimums.
Party B clicks "Accept invitation".
System updates Invitation.status to accepted.
System transitions Negotiation.status to negotiating.
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

Actor selects a NegotiatedTerm and clicks "Accept".
System sets approvedByA = true or approvedByB = true on that term (per actor identity).
System appends an ActivityEvent of type term_approved with the dimension in the payload.
System checks whether all NegotiatedTerm records now have both approvedByA = true and approvedByB = true.
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

Actor selects a NegotiatedTerm and opens the counter-proposal form.
System displays the current value and the minimum floor (NegotiatedTerm.minimumValue).
Actor enters a new proposed value and submits.
System validates: new value ≥ minimumValue.
System updates NegotiatedTerm.proposedValue to the new value.
System sets approvedByA = false and approvedByB = false on this term only.
System sets proposedBy to the acting party's role.
System increments Negotiation.currentVersion by 1.
System appends an ActivityEvent of type term_countered with dimension, old value, and new value in the payload.
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

System retrieves the Negotiation including all NegotiatedTerm records and ActivityEvent history.
System resolves which terms are approved, pending, or countered.
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

System transitions Negotiation.status from negotiating to waiting_for_funding.
System appends an ActivityEvent of type all_terms_agreed.
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

Party B clicks "Fund the deal".
System requests confirmation from Party B.
Party B confirms.
System records Negotiation.fundedAt = now().
System transitions Negotiation.status to agreed.
System appends an ActivityEvent of type deal_agreed.
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

System retrieves all ActivityEvent records for the negotiation in reverse-chronological order.
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 status	Party A can	Party B can
`invited`	—	Accept invitation, Decline invitation
`negotiating`	Approve unapproved terms, Counter-propose terms	Approve unapproved terms, Counter-propose terms
`waiting_for_funding`	View only	Fund the deal
`agreed`	View only	View only

Use Cases — Deal Negotiation ​

Actors ​

UC-01 · Publish Minimum Terms ​

Main flow ​

Postcondition ​

Exceptions ​

UC-02 · Send Invitation (Party A initiates) ​

Main flow ​

Postcondition ​

Exceptions ​

UC-03 · Accept Invitation ​

Main flow ​

Postcondition ​

Exceptions ​

UC-04 · Approve a Term ​

Main flow ​

Postcondition ​

Exceptions ​

UC-05 · Counter-Propose a Term ​

Main flow ​

Postcondition ​

Exceptions ​

UC-06 · View Negotiation State ​

Main flow ​

Postcondition ​

UC-07 · Transition to Waiting for Funding ​

Main flow ​

Postcondition ​

UC-08 · Fund the Deal ​

Main flow ​

Postcondition ​

Exceptions ​

UC-09 · View Activity Log ​

Main flow ​

Postcondition ​

Use Case Dependency Map ​

Status × Actor × Available Actions ​

Use Cases — Deal Negotiation

Actors

UC-01 · Publish Minimum Terms

Main flow

Postcondition

Exceptions

UC-02 · Send Invitation (Party A initiates)

Main flow

Postcondition

Exceptions

UC-03 · Accept Invitation

Main flow

Postcondition

Exceptions

UC-04 · Approve a Term

Main flow

Postcondition

Exceptions

UC-05 · Counter-Propose a Term

Main flow

Postcondition

Exceptions

UC-06 · View Negotiation State

Main flow

Postcondition

UC-07 · Transition to Waiting for Funding

Main flow

Postcondition

UC-08 · Fund the Deal

Main flow

Postcondition

Exceptions

UC-09 · View Activity Log

Main flow

Postcondition

Use Case Dependency Map

Status × Actor × Available Actions