MISChaufen/prevouch
0
0
Fork 0
Code Issues 9 Pull requests Projects Releases Packages Wiki Activity Actions

Define ticket-request allocation and fulfillment #5

New issue
Closed
opened 2026-10-20 21:29:34 +00:00 by phg · 4 comments
phg commented 2026-10-20 21:29:34 +00:00
Owner
Copy link

Part of #1

Question

What is the precise lifecycle of one ticket request, from entry through allocation to fulfillment, under the selected allocation policy and purchase mode?

Compose the contracts from Define allocation policies and organizer-triggered shuffling, Define central-purchase workflow and fulfillment, and Define upfront-payment tracking and refunds for central purchases. All three allocation policies and both purchase modes are required. Strict first come, first served is one policy rather than a universal invariant; the two shuffled policies use an organizer-triggered initial shuffle of grouped or individual entries respectively when distribution or purchasing begins. The resulting order stays fixed; new entries join the end, and later voucher arrivals do not reshuffle it.

Fixed requirements: self +n means n+1 ticket requests; multiple usable vouchers can be allocated concurrently, including an initial batch of eight. In self-purchase mode a person may receive several vouchers at once. In central-purchase mode members never receive voucher codes: the Orga-team buys tickets on their behalf, with funding eligibility supplied by the upfront-payment decision.

Settle the composite states and transitions for waiting, funding eligibility, assignment/reservation, self-purchase delivery or organizer purchase, fulfillment, withdrawal, and recovery. Scope the earlier agreement that receiving-mail-server acceptance fulfills a request to self-purchase only; use the central-purchase decision for that mode's fulfillment evidence. Keep upfront bank receipt, seller order/payment, ticket delivery, and successor arrival distinct.

Settle quantity reductions, cancellation before and after assignment or organizer purchase, rejoining, simultaneous joins/arrivals, event eligibility, and exclusive active assignments that prevent one voucher or request being served twice. Preserve the selected policy rather than silently forcing FCFS, round-robin, or an extra redraw. Apply the funding decision's rules for unpaid and partially paid requests rather than inventing them here.

Work through concrete examples with Alice, Bob, and Cara, mixed +n quantities, eight initial vouchers, and later successors under all three policies and both purchase modes. Cover partial group success and exhausted stock without treating a missing successor as evidence of payment or admission.

Apply the Congress research: distinguish group vouchers, initial angel vouchers, and non-replicating angel successors. All three are accepted inputs when explicitly classified and suitable for the event's eligible pool; administrators identify a missing class rather than guessing. Account for inventory/phase limits and the Friends Ticket exception.

Record domain terms as they settle. Resolution is one agreed composite state model and worked examples in a resolution comment; detailed selection, central-workflow, and financial decisions stay in their own tickets. Earlier self-purchase agreements are a checkpoint, not a resolution of this expanded question.

Settled funding and refund input

Use the agreed resolution in Define upfront-payment tracking and refunds for central purchases. Compose its per-request funding/reservations, temporary skips and restored positions, qualified group-turn continuity, per-holder ticket tiers/required details, and withdrawal/finalization consequences into the composite lifecycle. The financial rules remain in that decision.

Part of #1 ## Question What is the precise lifecycle of one ticket request, from entry through allocation to fulfillment, under the selected allocation policy and purchase mode? Compose the contracts from [Define allocation policies and organizer-triggered shuffling](https://git.s1q.dev/MISChaufen/prevouch/issues/14), [Define central-purchase workflow and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/15), and [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16). All three allocation policies and both purchase modes are required. Strict first come, first served is one policy rather than a universal invariant; the two shuffled policies use an organizer-triggered initial shuffle of grouped or individual entries respectively when distribution or purchasing begins. The resulting order stays fixed; new entries join the end, and later voucher arrivals do not reshuffle it. Fixed requirements: self +n means n+1 ticket requests; multiple usable vouchers can be allocated concurrently, including an initial batch of eight. In self-purchase mode a person may receive several vouchers at once. In central-purchase mode members never receive voucher codes: the Orga-team buys tickets on their behalf, with funding eligibility supplied by the upfront-payment decision. Settle the composite states and transitions for waiting, funding eligibility, assignment/reservation, self-purchase delivery or organizer purchase, fulfillment, withdrawal, and recovery. Scope the earlier agreement that receiving-mail-server acceptance fulfills a request to self-purchase only; use the central-purchase decision for that mode's fulfillment evidence. Keep upfront bank receipt, seller order/payment, ticket delivery, and successor arrival distinct. Settle quantity reductions, cancellation before and after assignment or organizer purchase, rejoining, simultaneous joins/arrivals, event eligibility, and exclusive active assignments that prevent one voucher or request being served twice. Preserve the selected policy rather than silently forcing FCFS, round-robin, or an extra redraw. Apply the funding decision's rules for unpaid and partially paid requests rather than inventing them here. Work through concrete examples with Alice, Bob, and Cara, mixed +n quantities, eight initial vouchers, and later successors under all three policies and both purchase modes. Cover partial group success and exhausted stock without treating a missing successor as evidence of payment or admission. Apply the Congress research: distinguish group vouchers, initial angel vouchers, and non-replicating angel successors. All three are accepted inputs when explicitly classified and suitable for the event's eligible pool; administrators identify a missing class rather than guessing. Account for inventory/phase limits and the Friends Ticket exception. Record domain terms as they settle. Resolution is one agreed composite state model and worked examples in a resolution comment; detailed selection, central-workflow, and financial decisions stay in their own tickets. Earlier self-purchase agreements are a checkpoint, not a resolution of this expanded question. ## Settled funding and refund input Use the agreed resolution in [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16). Compose its per-request funding/reservations, temporary skips and restored positions, qualified group-turn continuity, per-holder ticket tiers/required details, and withdrawal/finalization consequences into the composite lifecycle. The financial rules remain in that decision.
phg self-assigned this 2026-10-22 08:47:08 +00:00
phg commented 2026-10-22 09:13:21 +00:00
Author
Owner
Copy link

Planning checkpoint — expanded scope, not a resolution

The human agreed to the earlier questions, then added three required allocation policies and a central-purchase option before confirming the final composite model. This ticket remains open; the earlier proposal is not a final resolution.

Retained self-purchase inputs

  • Several requests from one person may hold vouchers concurrently. Under FCFS, Alice requesting three before Bob's two and Cara's four receives three of an initial eight vouchers, Bob two, and Cara three; Cara's fourth request is next.
  • Self-purchase fulfillment is voucher email acceptance by the recipient's mail server. Local queuing or outgoing-provider acceptance alone is insufficient; this does not establish seller order, payment, or admission.
  • Group vouchers, initial angel vouchers, and non-replicating angel successors are accepted when explicitly classified and suitable for the event's eligible pool. An administrator determines a missing class; incompatible stock is held rather than silently bypassing earlier requests.
  • A waiting self-purchase request may be withdrawn. Quantity reductions remove newest waiting requests first. Rejoining creates new demand; joining the back applies to FCFS, while shuffled ordering now belongs to the allocation-policy decision.
  • Before disclosure and delivery start, an assigned self-purchase request may be cancelled and its voucher safely released. Once disclosure or delivery may have occurred, retain the assignment and use recovery rather than automatically reusing the code.
  • Each voucher and request has at most one active assignment. Delivery retries reuse that assignment; safely released assignments may remain in history.
  • Missing successors leave remaining demand waiting for usable stock. Accepted successors join the event pool; non-replicating vouchers fulfill self-purchase requests normally. Successor arrival alone does not establish payment or admission.

New required scope and decision ownership

  • Define allocation policies and voucher-arrival shuffling specifies FCFS, Shuffled (grouped, keeping +n together), and Shuffled (everyone, shuffling +n individually). Shuffling happens on voucher arrival. Group identity, batch/arrival semantics, partial groups, and policy-change rules still need the human's decision.
  • Define central-purchase workflow and fulfillment defines Orga-team purchases on behalf of members. In this mode members never receive voucher codes, so voucher delivery cannot be its fulfillment criterion. Mode scope, organizer responsibilities, purchase/ticket evidence, and partial group success remain open.
  • Define upfront-payment tracking and refunds for central purchases defines upfront bank-payment tracking and return of unused funds when tickets cannot be bought, including payment matching, eligibility, partial amounts, and refund evidence. Manual tracking, bank integration, and initiating transfers are not yet chosen.

After those decisions, this ticket composes the lifecycle across the three allocation policies and two purchase modes. The map and downstream integration, recovery, notification, administration, architecture, and prototype questions are updated to match. No ticket is being resolved by this checkpoint.

## Planning checkpoint — expanded scope, not a resolution The human agreed to the earlier questions, then added three required allocation policies and a central-purchase option before confirming the final composite model. This ticket remains open; the earlier proposal is not a final resolution. ### Retained self-purchase inputs - Several requests from one person may hold vouchers concurrently. Under FCFS, Alice requesting three before Bob's two and Cara's four receives three of an initial eight vouchers, Bob two, and Cara three; Cara's fourth request is next. - Self-purchase fulfillment is voucher email acceptance by the recipient's mail server. Local queuing or outgoing-provider acceptance alone is insufficient; this does not establish seller order, payment, or admission. - Group vouchers, initial angel vouchers, and non-replicating angel successors are accepted when explicitly classified and suitable for the event's eligible pool. An administrator determines a missing class; incompatible stock is held rather than silently bypassing earlier requests. - A waiting self-purchase request may be withdrawn. Quantity reductions remove newest waiting requests first. Rejoining creates new demand; joining the back applies to FCFS, while shuffled ordering now belongs to the allocation-policy decision. - Before disclosure and delivery start, an assigned self-purchase request may be cancelled and its voucher safely released. Once disclosure or delivery may have occurred, retain the assignment and use recovery rather than automatically reusing the code. - Each voucher and request has at most one active assignment. Delivery retries reuse that assignment; safely released assignments may remain in history. - Missing successors leave remaining demand waiting for usable stock. Accepted successors join the event pool; non-replicating vouchers fulfill self-purchase requests normally. Successor arrival alone does not establish payment or admission. ### New required scope and decision ownership - [Define allocation policies and voucher-arrival shuffling](https://git.s1q.dev/MISChaufen/prevouch/issues/14) specifies FCFS, Shuffled (grouped, keeping +n together), and Shuffled (everyone, shuffling +n individually). Shuffling happens on voucher arrival. Group identity, batch/arrival semantics, partial groups, and policy-change rules still need the human's decision. - [Define central-purchase workflow and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/15) defines Orga-team purchases on behalf of members. In this mode members never receive voucher codes, so voucher delivery cannot be its fulfillment criterion. Mode scope, organizer responsibilities, purchase/ticket evidence, and partial group success remain open. - [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16) defines upfront bank-payment tracking and return of unused funds when tickets cannot be bought, including payment matching, eligibility, partial amounts, and refund evidence. Manual tracking, bank integration, and initiating transfers are not yet chosen. After those decisions, this ticket composes the lifecycle across the three allocation policies and two purchase modes. The map and downstream integration, recovery, notification, administration, architecture, and prototype questions are updated to match. No ticket is being resolved by this checkpoint.
phg commented 2026-10-22 11:53:20 +00:00
Author
Owner
Copy link

Planning checkpoint — lifecycle questions Q42–Q44

The human agreed to all three recommendations. These are inputs to the open composite lifecycle decision, not its final resolution. Define upfront-payment tracking and refunds for central purchases remains an unresolved prerequisite.

  • Q42 — distinguish request progress from related facts: track waiting, assigned, mode-specific delivery/purchase progress, and fulfilled, with withdrawal where permitted. Funding, delivery evidence, seller-order/payment facts, and recovery remain separately recorded. An uncertain purchase retains its assignment and known seller outcome rather than being reset to a clean waiting state.
  • Q43 — quantity reductions and safe cancellation: remove the newest waiting requests first. An assigned request can be cancelled and its voucher released only when this is safe before code disclosure and delivery/checkout starts. Otherwise cancellation requires recovery. Preserve fulfilled requests and binding seller commitments; the funding decision supplies any financial consequences. For Alice reducing three requests to one when one is fulfilled, one assigned, and one waiting: withdraw the waiting request, then cancel the assigned one only if safe; otherwise show that cancellation still needs recovery rather than claiming the reduction completed.
  • Q44 — verified failure preserves allocation priority: after a verified unsuccessful delivery/purchase and safe release, the same request returns to its original priority among requests still awaiting allocation. Preserve later existing assignments. In grouped mode retain the original group membership; future suitable free vouchers follow the established order. There is no new shuffle or move to the back unless the requester withdrew and later rejoined.

The root glossary now distinguishes assigned ticket requests and request recovery and makes the previously agreed self-purchase mail-server acceptance criterion explicit. Detailed recovery procedures remain in Decide stalled-voucher and delivery-failure recovery; funding eligibility, commitments, and refunds remain in their own decision. No funding rules or recovery deadlines are inferred here.

## Planning checkpoint — lifecycle questions Q42–Q44 The human agreed to all three recommendations. These are inputs to the open composite lifecycle decision, not its final resolution. [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16) remains an unresolved prerequisite. - **Q42 — distinguish request progress from related facts:** track waiting, assigned, mode-specific delivery/purchase progress, and fulfilled, with withdrawal where permitted. Funding, delivery evidence, seller-order/payment facts, and recovery remain separately recorded. An uncertain purchase retains its assignment and known seller outcome rather than being reset to a clean waiting state. - **Q43 — quantity reductions and safe cancellation:** remove the newest waiting requests first. An assigned request can be cancelled and its voucher released only when this is safe before code disclosure and delivery/checkout starts. Otherwise cancellation requires recovery. Preserve fulfilled requests and binding seller commitments; the funding decision supplies any financial consequences. For Alice reducing three requests to one when one is fulfilled, one assigned, and one waiting: withdraw the waiting request, then cancel the assigned one only if safe; otherwise show that cancellation still needs recovery rather than claiming the reduction completed. - **Q44 — verified failure preserves allocation priority:** after a verified unsuccessful delivery/purchase and safe release, the same request returns to its original priority among requests still awaiting allocation. Preserve later existing assignments. In grouped mode retain the original group membership; future suitable free vouchers follow the established order. There is no new shuffle or move to the back unless the requester withdrew and later rejoined. The root glossary now distinguishes assigned ticket requests and request recovery and makes the previously agreed self-purchase mail-server acceptance criterion explicit. Detailed recovery procedures remain in [Decide stalled-voucher and delivery-failure recovery](https://git.s1q.dev/MISChaufen/prevouch/issues/7); funding eligibility, commitments, and refunds remain in their own decision. No funding rules or recovery deadlines are inferred here.
phg commented 2026-10-22 11:57:03 +00:00
Author
Owner
Copy link

Planning checkpoint — lifecycle questions Q45–Q46 and composition pending funding

The human agreed to both recommendations. Together with the earlier Q42–Q44 agreements, these settle the lifecycle choices discussed so far. This remains a checkpoint: Define upfront-payment tracking and refunds for central purchases is still open, so funding-dependent transitions and examples cannot receive final confirmation yet.

Newly agreed boundaries

  • Q45 — pending withdrawal: retain a requester's cancellation intent while a delivery or checkout outcome is uncertain. Prevent any new send or checkout for that request while establishing the existing outcome. If safe cancellation becomes possible, withdraw rather than requeue it. If delivery or a binding purchase already happened, preserve the outcome and handle corrections or financial consequences separately. A pending withdrawal is not a completed withdrawal and does not itself release a voucher or undo a seller commitment.
  • Q46 — unserved outcome: explicitly finalized distribution marks remaining waiting requests Unserved, distinct from fulfilled or requester-withdrawn. Empty stock or missing successors alone leaves requests waiting. Uncertain deliveries or purchases remain in recovery until their outcomes are established; final closure must not invent those outcomes. Closure authority and the event workflow belong to Define administrator authority, queue visibility, and event lifecycle; refunds belong to the funding decision.

The root glossary now records Pending withdrawal and Unserved ticket request.

Composed lifecycle checkpoint

This section brings the agreed inputs together for later completion, without replacing the detailed allocation, central-purchase, funding, or recovery decisions.

  1. Entry and waiting: self +n creates n+1 separately identifiable ticket requests in the event's queue. Retain the accepted entry order used by FCFS and by permitted pre-lock policy changes. Shuffled modes use the recorded initial order, not later voucher arrivals. Rejoining after withdrawal creates new demand; later submissions append according to the chosen policy. One requester's several requests can be active concurrently.
  2. Allocation gate: the organizer must have started distribution. Allocate only explicitly classified, usable stock suitable for the same event's eligible pool, in the established policy order. Hold unknown-class or incompatible stock for administration rather than guessing or silently bypassing earlier requests. Central-purchase funding eligibility and any consequences of ineligibility must come from the funding decision; they are not supplied by this checkpoint.
  3. Exclusive assignment: a voucher and a request each have at most one active assignment. Concurrent joins, voucher arrivals, and batches must preserve that exclusivity and the selected ordering. A retry uses the existing assignment; safely released assignments may remain in history. Assignment is not delivery or purchase evidence.
  4. Self-purchase progress: the assigned voucher proceeds through delivery. The request is fulfilled only when the recipient's mail server accepts the voucher email; local queuing or outgoing-provider acceptance alone is insufficient. This fulfills voucher distribution without establishing seller order, seller payment, ticket purchase, or admission. A disclosed or uncertain delivery remains attached to its assignment for recovery.
  5. Central-purchase progress: an organizer exclusively claims the assigned request before accessing its code or starting external checkout. The member never receives that code. A binding seller order establishes the purchase commitment and locks the event's purchase mode and allocation policy. Keep the assignment reserved while seller payment is pending. Confirmed payment without confirmed seller sending remains awaiting ticket delivery. Fulfillment requires confirmed seller payment and seller confirmation that ticket access was sent to the correct holder's ticket email address; opening the link is unnecessary. The separate prevouch return address routes successors, subject to the routing decision's validation.
  6. Independent facts: keep request progress, funding, assignment, organizer responsibility, seller order/payment, delivery evidence, successor arrival, recovery, and pending withdrawal distinguishable. Neither an upfront bank receipt nor a successor substitutes for fulfillment evidence. Preserve individual outcomes when only some requests in a group succeed.
  7. Withdrawal and recovery: remove newest waiting requests first for a quantity reduction. Cancel assigned requests only when safe before disclosure and delivery/checkout starts; otherwise retain the cancellation intent through recovery. A verified unsuccessful, safely released request without a pending withdrawal retains its identity and original priority among still-waiting requests, including its original grouped membership. Preserve later existing assignments. A pending withdrawal instead resolves to withdrawal when safe. Detailed evidence, deadlines, voucher usability, and corrective procedures belong to Decide stalled-voucher and delivery-failure recovery.
  8. Stock exhaustion and final outcomes: a lack of usable vouchers leaves outstanding demand waiting. Explicit finalization distinguishes unserved waiting demand from requester withdrawal and from either mode's fulfillment. Preserve binding commitments, paid purchases, fulfilled requests, and uncertain outcomes; closing distribution does not erase them. Financial consequences remain with the funding decision.

Six policy/mode examples, conditional on eligibility

Alice requests three ticket opportunities, Bob two, and Cara four. Eight usable vouchers are available before the organizer starts distribution. All requests in these examples are assumed eligible; this assumption deliberately does not decide how unpaid or partially paid requests behave.

  • FCFS / self-purchase: Alice joined before Bob, then Cara. Assign A1–A3, B1–B2, and C1–C3. Fulfill each only on recipient-mail-server acceptance. C4 waits and receives the next suitable free voucher. Later Alice additions join behind C4.
  • FCFS / central purchase: the same eight assignments are purchasing work for the Orga-team, not fulfilled tickets. Exclusive claims, binding orders, seller payment, and seller-direct sending determine each request's outcome. C4 awaits subsequent eligible allocation.
  • Shuffled (grouped) / self-purchase: for recorded group order Bob(2), Cara(4), Alice(3), the initial eight assignments cover Bob's two, Cara's four, and Alice's first two. Alice's original third request has priority for the next suitable free voucher. A later submission creates a new group at the tail and cannot extend her original turn. Fulfillment is recorded individually on voucher-email acceptance.
  • Shuffled (grouped) / central purchase: use the same group order and eight assignments for organizer purchases. Alice may have two successful purchases while the third remains waiting or in recovery. Preserve partial success and her original remaining demand; grouped priority does not guarantee that enough stock or seller inventory will exist.
  • Shuffled (everyone) / self-purchase: for recorded order C1, A1, B1, C2, A2, C3, B2, C4, A3, the first eight assignments can fulfill Cara's four, Bob's two, and Alice's first two on their individual delivery evidence. A3 is next. Neither later stock nor delivery retries reshuffle the order.
  • Shuffled (everyone) / central purchase: the same eight assignments become organizer purchasing work; A3 is next subject to the funding contract. Outcomes remain individual even when one seller order covers several requests. No member receives voucher codes.

Accepted successors enter the event's common usable stock and serve the existing order rather than the requester whose purchase produced them. Group vouchers, initial angel vouchers, and non-replicating angel successors are all accepted when explicitly classified and suitable. Seller inventory/phase restrictions still apply. Missing successors leave demand waiting; the Congress Friends Ticket exception also prevents treating successor arrival as universal proof of completed payment.

If no later stock arrives, the ninth request stays waiting until withdrawal or explicit finalization, when a still-waiting request becomes unserved. Any assigned uncertain work instead retains its recorded outcome and recovery responsibility.

Remaining prerequisite and ownership

The final composite model still needs the funding decision's answers for unpaid and partially funded requests, their positions at initial shuffle and later payment, eligibility for one versus several assignments, protection of purchase commitments, and the effects of withdrawals, failed purchases, exhausted supply, and mode changes on funds and refunds. A final shared-understanding check of the completed model and funding examples must follow that decision. This ticket is therefore not closed and is not added to the map's Decisions so far.

The existing funding, recovery, and administrator tickets cover the remaining questions; no additional independent ticket is needed for these agreements. No production implementation or real purchase, email distribution, or bank operation was performed.

## Planning checkpoint — lifecycle questions Q45–Q46 and composition pending funding The human agreed to both recommendations. Together with the earlier Q42–Q44 agreements, these settle the lifecycle choices discussed so far. This remains a checkpoint: [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16) is still open, so funding-dependent transitions and examples cannot receive final confirmation yet. ### Newly agreed boundaries - **Q45 — pending withdrawal:** retain a requester's cancellation intent while a delivery or checkout outcome is uncertain. Prevent any new send or checkout for that request while establishing the existing outcome. If safe cancellation becomes possible, withdraw rather than requeue it. If delivery or a binding purchase already happened, preserve the outcome and handle corrections or financial consequences separately. A pending withdrawal is not a completed withdrawal and does not itself release a voucher or undo a seller commitment. - **Q46 — unserved outcome:** explicitly finalized distribution marks remaining waiting requests **Unserved**, distinct from fulfilled or requester-withdrawn. Empty stock or missing successors alone leaves requests waiting. Uncertain deliveries or purchases remain in recovery until their outcomes are established; final closure must not invent those outcomes. Closure authority and the event workflow belong to [Define administrator authority, queue visibility, and event lifecycle](https://git.s1q.dev/MISChaufen/prevouch/issues/10); refunds belong to the funding decision. The root glossary now records **Pending withdrawal** and **Unserved ticket request**. ### Composed lifecycle checkpoint This section brings the agreed inputs together for later completion, without replacing the detailed allocation, central-purchase, funding, or recovery decisions. 1. **Entry and waiting:** self +n creates n+1 separately identifiable ticket requests in the event's queue. Retain the accepted entry order used by FCFS and by permitted pre-lock policy changes. Shuffled modes use the recorded initial order, not later voucher arrivals. Rejoining after withdrawal creates new demand; later submissions append according to the chosen policy. One requester's several requests can be active concurrently. 2. **Allocation gate:** the organizer must have started distribution. Allocate only explicitly classified, usable stock suitable for the same event's eligible pool, in the established policy order. Hold unknown-class or incompatible stock for administration rather than guessing or silently bypassing earlier requests. Central-purchase funding eligibility and any consequences of ineligibility must come from the funding decision; they are not supplied by this checkpoint. 3. **Exclusive assignment:** a voucher and a request each have at most one active assignment. Concurrent joins, voucher arrivals, and batches must preserve that exclusivity and the selected ordering. A retry uses the existing assignment; safely released assignments may remain in history. Assignment is not delivery or purchase evidence. 4. **Self-purchase progress:** the assigned voucher proceeds through delivery. The request is fulfilled only when the recipient's mail server accepts the voucher email; local queuing or outgoing-provider acceptance alone is insufficient. This fulfills voucher distribution without establishing seller order, seller payment, ticket purchase, or admission. A disclosed or uncertain delivery remains attached to its assignment for recovery. 5. **Central-purchase progress:** an organizer exclusively claims the assigned request before accessing its code or starting external checkout. The member never receives that code. A binding seller order establishes the purchase commitment and locks the event's purchase mode and allocation policy. Keep the assignment reserved while seller payment is pending. Confirmed payment without confirmed seller sending remains awaiting ticket delivery. Fulfillment requires confirmed seller payment and seller confirmation that ticket access was sent to the correct holder's ticket email address; opening the link is unnecessary. The separate prevouch return address routes successors, subject to the routing decision's validation. 6. **Independent facts:** keep request progress, funding, assignment, organizer responsibility, seller order/payment, delivery evidence, successor arrival, recovery, and pending withdrawal distinguishable. Neither an upfront bank receipt nor a successor substitutes for fulfillment evidence. Preserve individual outcomes when only some requests in a group succeed. 7. **Withdrawal and recovery:** remove newest waiting requests first for a quantity reduction. Cancel assigned requests only when safe before disclosure and delivery/checkout starts; otherwise retain the cancellation intent through recovery. A verified unsuccessful, safely released request without a pending withdrawal retains its identity and original priority among still-waiting requests, including its original grouped membership. Preserve later existing assignments. A pending withdrawal instead resolves to withdrawal when safe. Detailed evidence, deadlines, voucher usability, and corrective procedures belong to [Decide stalled-voucher and delivery-failure recovery](https://git.s1q.dev/MISChaufen/prevouch/issues/7). 8. **Stock exhaustion and final outcomes:** a lack of usable vouchers leaves outstanding demand waiting. Explicit finalization distinguishes unserved waiting demand from requester withdrawal and from either mode's fulfillment. Preserve binding commitments, paid purchases, fulfilled requests, and uncertain outcomes; closing distribution does not erase them. Financial consequences remain with the funding decision. ### Six policy/mode examples, conditional on eligibility Alice requests three ticket opportunities, Bob two, and Cara four. Eight usable vouchers are available before the organizer starts distribution. All requests in these examples are assumed eligible; this assumption deliberately does not decide how unpaid or partially paid requests behave. - **FCFS / self-purchase:** Alice joined before Bob, then Cara. Assign A1–A3, B1–B2, and C1–C3. Fulfill each only on recipient-mail-server acceptance. C4 waits and receives the next suitable free voucher. Later Alice additions join behind C4. - **FCFS / central purchase:** the same eight assignments are purchasing work for the Orga-team, not fulfilled tickets. Exclusive claims, binding orders, seller payment, and seller-direct sending determine each request's outcome. C4 awaits subsequent eligible allocation. - **Shuffled (grouped) / self-purchase:** for recorded group order Bob(2), Cara(4), Alice(3), the initial eight assignments cover Bob's two, Cara's four, and Alice's first two. Alice's original third request has priority for the next suitable free voucher. A later submission creates a new group at the tail and cannot extend her original turn. Fulfillment is recorded individually on voucher-email acceptance. - **Shuffled (grouped) / central purchase:** use the same group order and eight assignments for organizer purchases. Alice may have two successful purchases while the third remains waiting or in recovery. Preserve partial success and her original remaining demand; grouped priority does not guarantee that enough stock or seller inventory will exist. - **Shuffled (everyone) / self-purchase:** for recorded order C1, A1, B1, C2, A2, C3, B2, C4, A3, the first eight assignments can fulfill Cara's four, Bob's two, and Alice's first two on their individual delivery evidence. A3 is next. Neither later stock nor delivery retries reshuffle the order. - **Shuffled (everyone) / central purchase:** the same eight assignments become organizer purchasing work; A3 is next subject to the funding contract. Outcomes remain individual even when one seller order covers several requests. No member receives voucher codes. Accepted successors enter the event's common usable stock and serve the existing order rather than the requester whose purchase produced them. Group vouchers, initial angel vouchers, and non-replicating angel successors are all accepted when explicitly classified and suitable. Seller inventory/phase restrictions still apply. Missing successors leave demand waiting; the Congress Friends Ticket exception also prevents treating successor arrival as universal proof of completed payment. If no later stock arrives, the ninth request stays waiting until withdrawal or explicit finalization, when a still-waiting request becomes unserved. Any assigned uncertain work instead retains its recorded outcome and recovery responsibility. ### Remaining prerequisite and ownership The final composite model still needs the funding decision's answers for unpaid and partially funded requests, their positions at initial shuffle and later payment, eligibility for one versus several assignments, protection of purchase commitments, and the effects of withdrawals, failed purchases, exhausted supply, and mode changes on funds and refunds. A final shared-understanding check of the completed model and funding examples must follow that decision. This ticket is therefore not closed and is not added to the map's Decisions so far. The existing funding, recovery, and administrator tickets cover the remaining questions; no additional independent ticket is needed for these agreements. No production implementation or real purchase, email distribution, or bank operation was performed.
phg commented 2026-10-22 18:46:51 +00:00
Author
Owner
Copy link

Resolution — ticket-request allocation and fulfillment

The human confirmed the completed lifecycle and worked examples in Q47, after the earlier Q42–Q46 agreements and the resolution of the funding prerequisite. This is the final composite decision and supersedes the earlier lifecycle checkpoints, including their conditional funding assumptions.

The detailed contracts remain canonical in Define allocation policies and organizer-triggered shuffling, Define central-purchase workflow and fulfillment, and Define upfront-payment tracking and refunds for central purchases. This resolution composes them rather than replacing their selection, purchasing, or accounting rules.

Request progress and independent facts

Each ticket request has an individual identity and outcome. Keep its waiting, assigned, mode-specific progress, fulfilled, withdrawn, or unserved status distinguishable from funding eligibility, purchase/refund holds, organizer responsibility, seller order/payment, delivery evidence, successor arrival, recovery, and pending withdrawal. These are related facts, not interchangeable evidence or one flattened status.

Recovery retains the known progress and commitments. An uncertain purchase is not reset to clean waiting; a pending withdrawal is an intent awaiting a safe outcome, not a released voucher or canceled seller order.

Entry, eligibility, and assignment

  1. Entry: self +n creates n+1 separately identifiable ticket requests for one event. A requester manages their own and companion requests; companions need no separate account. Preserve accepted entry order, including a stable order for simultaneous joins. Different events have separate queues and event-wide purchase modes.
  2. Ordering: an organizer explicitly starts distribution for every policy. FCFS uses accepted entry order. Shuffled modes record one initial ordering of groups or individual requests; unpaid requests participate. Before the grouped shuffle, a requester's requests consolidate into one group. After it, each new submission forms a new tail group; everyone-mode additions append their individual requests. Later stock, retries, restarts, and repeated start actions do not reshuffle. Rejoining after withdrawal creates new demand under the selected policy.
  3. Suitable stock: allocate only explicitly classified, usable vouchers suitable for the event's eligible pool. An administrator identifies a missing class; hold incompatible stock rather than guessing or silently bypassing earlier requests to use it. Event/seller phase, inventory, and voucher-class constraints still apply.
  4. Central-purchase eligibility: apply the funding decision's full agreed amount and required holder/tier details per request. Unpaid, partially funded, or otherwise ineligible waiting demand is temporarily skipped without expiring or losing its established position. Confirmed funding or corrected details restores eligibility without revoking someone else's assignment or purchase. Dynamic per-holder tiers retain accepted prices and required details; no automatic substitution or unapproved price increase.
  5. Funding and grouped turns: determine each requester balance's funded requests in their actual allocation order, after the initial shuffle in shuffled modes. Retain partial funds toward an earlier expensive request rather than bypassing it for a cheaper later one. Existing reservations and commitments take priority. In grouped mode, continue a group's original turn while its next original request remains eligible. Otherwise skip the group, retaining its original position. If eligibility returns during another group's active turn, finish that turn while its next original request remains eligible, then resume the earlier group before later groups. Later additions cannot extend a turn.
  6. Exclusive assignment: one voucher and one request each have at most one active assignment. At central assignment, reserve the request's full agreed amount together with its voucher/request reservation, before another assignment or refund can consume it. Multiple vouchers, requests from one requester, and organizers may be active concurrently. Simultaneous joins, arrivals, funding changes, and assignments preserve the accepted policy order and cannot spend a voucher, request, or funds twice. Delivery/purchase retries reuse the recorded assignment; safely released assignments remain in history.

No allocation occurs before distribution starts, even if stock or funding arrives. Afterwards, accepted suitable stock and restored eligibility cause allocation against the existing order. Architecture chooses how to serialize this safely; it does not choose a different ordering policy.

Self-purchase transitions and fulfillment

Waiting → assigned → voucher delivery → fulfilled. A person may receive several vouchers concurrently, including their own and companion requests.

Fulfillment requires acceptance of the voucher email by the recipient's mail server. Local queuing or outgoing-provider acceptance alone is insufficient. This establishes successful voucher distribution, not seller order, seller payment, ticket acquisition, or admission. Retain disclosed or uncertain delivery with its assignment for recovery; do not automatically recycle the code.

Central-purchase transitions and fulfillment

Eligible waiting → assigned with funds reserved → exclusive organizer claim → external checkout → accepted binding seller order → seller payment/ticket-delivery progress → fulfilled. The Orga-team performs manual seller checkout; members never receive voucher codes.

  • Claim the assigned request/voucher exclusively before revealing its code or starting checkout. Before disclosure, a claim can be released cleanly. After disclosure or checkout starts, transferring responsibility requires an explicit handover with current seller status. An uncertain outcome stays held; timeout alone does not permit another purchase.
  • A binding seller order is a purchase commitment, even with payment pending. Keep its assignment and applicable funding hold while awaiting seller payment; the claimant remains responsible, with explicit handover where another organizer completes the work.
  • Confirmed seller payment without confirmed ticket-access sending is Purchased, awaiting ticket delivery, not fulfilled.
  • Fulfillment requires confirmed seller payment and seller confirmation that ticket access was sent to the correct holder's ticket email address. Record the linked seller order and confirmations. The holder need not open the link.
  • The seller sends ticket access directly to each holder, including companions. The separate prevouch return address routes successors, subject to the existing routing decision's validation. A single seller order may cover several requests; preserve their individual outcomes and allocate actual costs/fees according to the funding decision.

Upfront bank receipt, assignment, claim, binding order, seller payment, ticket sending, and successor arrival remain separate. Neither upfront receipt nor successor arrival substitutes for either mode's fulfillment evidence. A later delivery problem is a recovery input, not automatic authorization for a replacement ticket.

Withdrawal, quantity reductions, and recovery

  • A waiting request may be withdrawn. Quantity reductions remove the newest waiting requests first. Preserve already fulfilled requests and binding seller commitments.
  • An assigned request can be canceled and its voucher released only when safe before code disclosure and delivery/checkout starts. If disclosure or an external outcome is uncertain, retain the assignment and investigate rather than reporting the reduction complete.
  • Record pending withdrawal while safety is unresolved. Prevent a new send or checkout for the affected request while establishing the existing outcome. When safe, withdraw rather than requeue. If delivery or a binding purchase already happened, preserve it and handle corrective or financial consequences separately.
  • After verified unsuccessful delivery/purchase and safe release, a still-active request returns with the same identity and original priority among waiting requests, retaining original grouped membership and the funding qualification to group turns. Preserve later existing assignments. A requester who actually withdrew and later rejoins creates new demand instead.
  • Release central purchase holds only when no binding order or outstanding charge can remain. Released funds can support a retry while the request stays active. Safe withdrawal or finalization instead makes established unused funds refundable under the funding decision. Spent/committed money is not automatically refundable; uncertain purchases and expected seller repayments remain distinct from available cash.

For example, Alice reducing three requests to one when one is fulfilled, one assigned, and one waiting first withdraws the waiting request. Cancel the assigned request only if safe; otherwise retain pending withdrawal/recovery instead of claiming only one request remains. Preserve the fulfilled outcome.

Exhausted supply, finalization, and allowed changes

Empty stock or missing successors leaves remaining demand waiting. Explicit distribution finalization marks remaining waiting demand unserved, distinct from fulfilled or requester-withdrawn, and makes its established unused funds refundable. Preserve successful purchases in partially served groups. Pending purchases, binding commitments, and uncertain outcomes remain visible until actually settled; finalization does not invent their outcomes or release their holds.

Allocation policy locks at the first successful self-purchase voucher send or first binding central-purchase order. Purchase mode locks at the first binding ticket order. Before a permitted change, pause allocation and establish safe outcomes, including external purchases that may have occurred after self-purchase disclosure. A mode change does not reopen a locked allocation policy or authorize a redraw. Preserve upfront-money history and refund established unused central-purchase funds according to the funding decision.

Worked examples: all three policies and both purchase modes

Alice requests self +2 (A1–A3), Bob self +1 (B1–B2), and Cara self +3 (C1–C4): nine requests. Eight suitable vouchers are available when the organizer starts distribution. In these six examples, all requests have the necessary eligibility; central requests have full funding and required details.

  1. FCFS / self-purchase: Alice entered before Bob, then Cara. Assign A1–A3, B1–B2, C1–C3. Fulfill each on recipient-mail-server acceptance. C4 receives the next suitable free voucher. A later Alice addition joins behind C4.
  2. FCFS / central purchase: make the same eight assignments with their funding reservations. They become purchasing work, not fulfilled tickets. Exclusive claims, binding orders, seller payment, and seller-confirmed sending determine each outcome. C4 remains next for suitable free stock while eligible.
  3. Shuffled (grouped) / self-purchase: for recorded group order Bob(2), Cara(4), Alice(3), assign Bob's two, Cara's four, and A1–A2. Alice's original A3 has the next turn. A later submission forms a new tail group and cannot extend her original turn. Fulfillment remains individual email acceptance.
  4. Shuffled (grouped) / central purchase: use the same eight assignments for funded organizer purchases. A1 and A2 can succeed while A3 waits for stock; preserve partial success and the original remaining request. If a purchase is uncertain, retain its own assignment/hold in recovery. Group priority guarantees neither enough vouchers nor seller inventory for the whole group.
  5. Shuffled (everyone) / self-purchase: for recorded order C1, A1, B1, C2, A2, C3, B2, C4, A3, assign the first eight. Cara can receive four vouchers, Bob two, and Alice two. Each fulfills on its own delivery evidence; A3 is next. New entries append and retries do not reshuffle.
  6. Shuffled (everyone) / central purchase: the same eight become funded purchasing assignments, with individual payment/delivery outcomes even when a seller order spans requests. A3 is next while eligible. No member receives a voucher code.

In each case, a later accepted successor joins the common usable event pool and serves its established order, not the person whose purchase produced it. Without later stock, the ninth request waits until withdrawal or explicit finalization; then still-waiting demand becomes unserved. Assigned uncertainty stays in recovery.

Funding-dependent examples

Illustrative prices only; the detailed financial rules and accounting remain in the funding decision.

  • Partial funding under every policy: at EUR 150 per request, Alice's EUR 300 funds only her first two requests in the actual order. Her third retains its position but is temporarily ineligible; Bob and Cara's funded requests can be assigned without waiting for her top-up. All eight vouchers may be assigned while her third request waits. A later EUR 150 receipt restores eligibility without taking back another assignment; later free stock serves the established order. If finalized unserved, established unused money becomes refundable. Earlier successful purchases and any pending purchase holds remain recorded separately.
  • Group skips and restoration: recorded group order Alice(3), Bob(2), Cara(4). Alice has EUR 300. With the first three vouchers, A1 and A2 are assigned, then A3 is unfunded and her group yields; B1 is assigned. Alice tops up before the next voucher arrives. Bob's active eligible turn still gets B2; the following suitable voucher serves A3 before Cara. Later Alice requests cannot extend her original group.
  • Different tiers: Alice's next request costs EUR 180 and a later request EUR 100. EUR 150 remains toward the earlier request rather than buying the cheaper one out of order. EUR 30 more fully funds the earlier request; assigning it reserves EUR 180. Missing required details or an unavailable tier keeps the affected request ineligible without automatic substitution or expiry.
  • Partial success and finalization: Alice pays EUR 450 for three EUR 150 requests; two are paid and seller-sent, the third stays waiting. Finalization makes the third unserved and the unused EUR 150 refundable. If instead the third has an unpaid binding order, its EUR 150 stays committed pending the actual seller outcome; finalization does not turn that commitment into a refund or an unserved waiting request.

Congress voucher classes and successor evidence

Apply Establish Congress voucher replication and incoming-email evidence: group vouchers, initial angel vouchers, and non-replicating angel successors are accepted inputs only when explicitly classified and suitable for the event pool. Group and initial angel vouchers have class-dependent replication; angel successors do not replicate. A non-replicating voucher still serves a request normally.

Respect seller inventory/phase restrictions and the documented processing/order-age conditions. Missing successors do not undo successful requests or prove a payment/admission outcome. The Friends Ticket exception prevents treating successor arrival as universal proof of completed payment. Correlation and trusted routing need their own evidence; neither a successor nor the return alias alone proves fulfillment or admission.

Existing decision handoffs

These existing tickets cover the remaining work; no additional independent decision or newly specifiable fog emerged. The glossary already records the settled lifecycle terms. This is a planning resolution, not a production implementation or real distribution, purchase, or bank operation.

Discussion and interactive model: Ticket-request lifecycle review.

## Resolution — ticket-request allocation and fulfillment The human confirmed the completed lifecycle and worked examples in Q47, after the earlier Q42–Q46 agreements and the resolution of the funding prerequisite. This is the final composite decision and supersedes the earlier lifecycle checkpoints, including their conditional funding assumptions. The detailed contracts remain canonical in [Define allocation policies and organizer-triggered shuffling](https://git.s1q.dev/MISChaufen/prevouch/issues/14), [Define central-purchase workflow and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/15), and [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16). This resolution composes them rather than replacing their selection, purchasing, or accounting rules. ### Request progress and independent facts Each ticket request has an individual identity and outcome. Keep its waiting, assigned, mode-specific progress, fulfilled, withdrawn, or unserved status distinguishable from funding eligibility, purchase/refund holds, organizer responsibility, seller order/payment, delivery evidence, successor arrival, recovery, and pending withdrawal. These are related facts, not interchangeable evidence or one flattened status. Recovery retains the known progress and commitments. An uncertain purchase is not reset to clean waiting; a pending withdrawal is an intent awaiting a safe outcome, not a released voucher or canceled seller order. ### Entry, eligibility, and assignment 1. **Entry:** self +n creates n+1 separately identifiable ticket requests for one event. A requester manages their own and companion requests; companions need no separate account. Preserve accepted entry order, including a stable order for simultaneous joins. Different events have separate queues and event-wide purchase modes. 2. **Ordering:** an organizer explicitly starts distribution for every policy. FCFS uses accepted entry order. Shuffled modes record one initial ordering of groups or individual requests; unpaid requests participate. Before the grouped shuffle, a requester's requests consolidate into one group. After it, each new submission forms a new tail group; everyone-mode additions append their individual requests. Later stock, retries, restarts, and repeated start actions do not reshuffle. Rejoining after withdrawal creates new demand under the selected policy. 3. **Suitable stock:** allocate only explicitly classified, usable vouchers suitable for the event's eligible pool. An administrator identifies a missing class; hold incompatible stock rather than guessing or silently bypassing earlier requests to use it. Event/seller phase, inventory, and voucher-class constraints still apply. 4. **Central-purchase eligibility:** apply the funding decision's full agreed amount and required holder/tier details per request. Unpaid, partially funded, or otherwise ineligible waiting demand is temporarily skipped without expiring or losing its established position. Confirmed funding or corrected details restores eligibility without revoking someone else's assignment or purchase. Dynamic per-holder tiers retain accepted prices and required details; no automatic substitution or unapproved price increase. 5. **Funding and grouped turns:** determine each requester balance's funded requests in their actual allocation order, after the initial shuffle in shuffled modes. Retain partial funds toward an earlier expensive request rather than bypassing it for a cheaper later one. Existing reservations and commitments take priority. In grouped mode, continue a group's original turn while its next original request remains eligible. Otherwise skip the group, retaining its original position. If eligibility returns during another group's active turn, finish that turn while its next original request remains eligible, then resume the earlier group before later groups. Later additions cannot extend a turn. 6. **Exclusive assignment:** one voucher and one request each have at most one active assignment. At central assignment, reserve the request's full agreed amount together with its voucher/request reservation, before another assignment or refund can consume it. Multiple vouchers, requests from one requester, and organizers may be active concurrently. Simultaneous joins, arrivals, funding changes, and assignments preserve the accepted policy order and cannot spend a voucher, request, or funds twice. Delivery/purchase retries reuse the recorded assignment; safely released assignments remain in history. No allocation occurs before distribution starts, even if stock or funding arrives. Afterwards, accepted suitable stock and restored eligibility cause allocation against the existing order. Architecture chooses how to serialize this safely; it does not choose a different ordering policy. ### Self-purchase transitions and fulfillment **Waiting → assigned → voucher delivery → fulfilled.** A person may receive several vouchers concurrently, including their own and companion requests. Fulfillment requires acceptance of the voucher email by the recipient's mail server. Local queuing or outgoing-provider acceptance alone is insufficient. This establishes successful voucher distribution, not seller order, seller payment, ticket acquisition, or admission. Retain disclosed or uncertain delivery with its assignment for recovery; do not automatically recycle the code. ### Central-purchase transitions and fulfillment **Eligible waiting → assigned with funds reserved → exclusive organizer claim → external checkout → accepted binding seller order → seller payment/ticket-delivery progress → fulfilled.** The Orga-team performs manual seller checkout; members never receive voucher codes. - Claim the assigned request/voucher exclusively before revealing its code or starting checkout. Before disclosure, a claim can be released cleanly. After disclosure or checkout starts, transferring responsibility requires an explicit handover with current seller status. An uncertain outcome stays held; timeout alone does not permit another purchase. - A binding seller order is a purchase commitment, even with payment pending. Keep its assignment and applicable funding hold while awaiting seller payment; the claimant remains responsible, with explicit handover where another organizer completes the work. - Confirmed seller payment without confirmed ticket-access sending is **Purchased, awaiting ticket delivery**, not fulfilled. - Fulfillment requires confirmed seller payment and seller confirmation that ticket access was sent to the correct holder's ticket email address. Record the linked seller order and confirmations. The holder need not open the link. - The seller sends ticket access directly to each holder, including companions. The separate prevouch return address routes successors, subject to the existing routing decision's validation. A single seller order may cover several requests; preserve their individual outcomes and allocate actual costs/fees according to the funding decision. Upfront bank receipt, assignment, claim, binding order, seller payment, ticket sending, and successor arrival remain separate. Neither upfront receipt nor successor arrival substitutes for either mode's fulfillment evidence. A later delivery problem is a recovery input, not automatic authorization for a replacement ticket. ### Withdrawal, quantity reductions, and recovery - A waiting request may be withdrawn. Quantity reductions remove the newest waiting requests first. Preserve already fulfilled requests and binding seller commitments. - An assigned request can be canceled and its voucher released only when safe before code disclosure and delivery/checkout starts. If disclosure or an external outcome is uncertain, retain the assignment and investigate rather than reporting the reduction complete. - Record **pending withdrawal** while safety is unresolved. Prevent a new send or checkout for the affected request while establishing the existing outcome. When safe, withdraw rather than requeue. If delivery or a binding purchase already happened, preserve it and handle corrective or financial consequences separately. - After verified unsuccessful delivery/purchase and safe release, a still-active request returns with the same identity and original priority among waiting requests, retaining original grouped membership and the funding qualification to group turns. Preserve later existing assignments. A requester who actually withdrew and later rejoins creates new demand instead. - Release central purchase holds only when no binding order or outstanding charge can remain. Released funds can support a retry while the request stays active. Safe withdrawal or finalization instead makes established unused funds refundable under the funding decision. Spent/committed money is not automatically refundable; uncertain purchases and expected seller repayments remain distinct from available cash. For example, Alice reducing three requests to one when one is fulfilled, one assigned, and one waiting first withdraws the waiting request. Cancel the assigned request only if safe; otherwise retain pending withdrawal/recovery instead of claiming only one request remains. Preserve the fulfilled outcome. ### Exhausted supply, finalization, and allowed changes Empty stock or missing successors leaves remaining demand **waiting**. Explicit distribution finalization marks remaining waiting demand **unserved**, distinct from fulfilled or requester-withdrawn, and makes its established unused funds refundable. Preserve successful purchases in partially served groups. Pending purchases, binding commitments, and uncertain outcomes remain visible until actually settled; finalization does not invent their outcomes or release their holds. Allocation policy locks at the first successful self-purchase voucher send or first binding central-purchase order. Purchase mode locks at the first binding ticket order. Before a permitted change, pause allocation and establish safe outcomes, including external purchases that may have occurred after self-purchase disclosure. A mode change does not reopen a locked allocation policy or authorize a redraw. Preserve upfront-money history and refund established unused central-purchase funds according to the funding decision. ### Worked examples: all three policies and both purchase modes Alice requests self +2 (A1–A3), Bob self +1 (B1–B2), and Cara self +3 (C1–C4): nine requests. Eight suitable vouchers are available when the organizer starts distribution. In these six examples, all requests have the necessary eligibility; central requests have full funding and required details. 1. **FCFS / self-purchase:** Alice entered before Bob, then Cara. Assign A1–A3, B1–B2, C1–C3. Fulfill each on recipient-mail-server acceptance. C4 receives the next suitable free voucher. A later Alice addition joins behind C4. 2. **FCFS / central purchase:** make the same eight assignments with their funding reservations. They become purchasing work, not fulfilled tickets. Exclusive claims, binding orders, seller payment, and seller-confirmed sending determine each outcome. C4 remains next for suitable free stock while eligible. 3. **Shuffled (grouped) / self-purchase:** for recorded group order Bob(2), Cara(4), Alice(3), assign Bob's two, Cara's four, and A1–A2. Alice's original A3 has the next turn. A later submission forms a new tail group and cannot extend her original turn. Fulfillment remains individual email acceptance. 4. **Shuffled (grouped) / central purchase:** use the same eight assignments for funded organizer purchases. A1 and A2 can succeed while A3 waits for stock; preserve partial success and the original remaining request. If a purchase is uncertain, retain its own assignment/hold in recovery. Group priority guarantees neither enough vouchers nor seller inventory for the whole group. 5. **Shuffled (everyone) / self-purchase:** for recorded order C1, A1, B1, C2, A2, C3, B2, C4, A3, assign the first eight. Cara can receive four vouchers, Bob two, and Alice two. Each fulfills on its own delivery evidence; A3 is next. New entries append and retries do not reshuffle. 6. **Shuffled (everyone) / central purchase:** the same eight become funded purchasing assignments, with individual payment/delivery outcomes even when a seller order spans requests. A3 is next while eligible. No member receives a voucher code. In each case, a later accepted successor joins the common usable event pool and serves its established order, not the person whose purchase produced it. Without later stock, the ninth request waits until withdrawal or explicit finalization; then still-waiting demand becomes unserved. Assigned uncertainty stays in recovery. ### Funding-dependent examples Illustrative prices only; the detailed financial rules and accounting remain in the funding decision. - **Partial funding under every policy:** at EUR 150 per request, Alice's EUR 300 funds only her first two requests in the actual order. Her third retains its position but is temporarily ineligible; Bob and Cara's funded requests can be assigned without waiting for her top-up. All eight vouchers may be assigned while her third request waits. A later EUR 150 receipt restores eligibility without taking back another assignment; later free stock serves the established order. If finalized unserved, established unused money becomes refundable. Earlier successful purchases and any pending purchase holds remain recorded separately. - **Group skips and restoration:** recorded group order Alice(3), Bob(2), Cara(4). Alice has EUR 300. With the first three vouchers, A1 and A2 are assigned, then A3 is unfunded and her group yields; B1 is assigned. Alice tops up before the next voucher arrives. Bob's active eligible turn still gets B2; the following suitable voucher serves A3 before Cara. Later Alice requests cannot extend her original group. - **Different tiers:** Alice's next request costs EUR 180 and a later request EUR 100. EUR 150 remains toward the earlier request rather than buying the cheaper one out of order. EUR 30 more fully funds the earlier request; assigning it reserves EUR 180. Missing required details or an unavailable tier keeps the affected request ineligible without automatic substitution or expiry. - **Partial success and finalization:** Alice pays EUR 450 for three EUR 150 requests; two are paid and seller-sent, the third stays waiting. Finalization makes the third unserved and the unused EUR 150 refundable. If instead the third has an unpaid binding order, its EUR 150 stays committed pending the actual seller outcome; finalization does not turn that commitment into a refund or an unserved waiting request. ### Congress voucher classes and successor evidence Apply [Establish Congress voucher replication and incoming-email evidence](https://git.s1q.dev/MISChaufen/prevouch/issues/2): group vouchers, initial angel vouchers, and non-replicating angel successors are accepted inputs only when explicitly classified and suitable for the event pool. Group and initial angel vouchers have class-dependent replication; angel successors do not replicate. A non-replicating voucher still serves a request normally. Respect seller inventory/phase restrictions and the documented processing/order-age conditions. Missing successors do not undo successful requests or prove a payment/admission outcome. The Friends Ticket exception prevents treating successor arrival as universal proof of completed payment. Correlation and trusted routing need their own evidence; neither a successor nor the return alias alone proves fulfillment or admission. ### Existing decision handoffs - [Choose successor routing and incoming-voucher trust rules](https://git.s1q.dev/MISChaufen/prevouch/issues/6) and [Obtain redacted evidence of successor-address routing](https://git.s1q.dev/MISChaufen/prevouch/issues/13): actual ticket/successor addressing, suitable incoming stock, classification, authenticity, deduplication, and correlation evidence. - [Decide stalled-voucher and delivery-failure recovery](https://git.s1q.dev/MISChaufen/prevouch/issues/7): evidence, deadlines, safe release, disputed or failed delivery/purchase, retained priority, pending withdrawal, and post-fulfillment corrections. - [Define administrator authority, queue visibility, and event lifecycle](https://git.s1q.dev/MISChaufen/prevouch/issues/10): permissions, event eligibility/operations, policy/mode change actions, finalization, and visible unresolved work. - [Define delivery addresses, email templates, and notification preferences](https://git.s1q.dev/MISChaufen/prevouch/issues/9): explain the distinct request, funding, purchase, delivery, recovery, unserved, and refund states through the chosen channels. - [Choose the application architecture and deployment contract](https://git.s1q.dev/MISChaufen/prevouch/issues/11): durable identities/order, exclusive assignments and claims, evidence/history, and coordinated reservations under concurrency. - [Evaluate member and admin journeys in four live-switchable designs](https://git.s1q.dev/MISChaufen/prevouch/issues/12): demonstrate the six policy/mode cases, eight initial vouchers and successors, partial funding, restored group turns, tier details, concurrent purchasing, recovery/withdrawal, and partial or no service. These existing tickets cover the remaining work; no additional independent decision or newly specifiable fog emerged. The glossary already records the settled lifecycle terms. This is a planning resolution, not a production implementation or real distribution, purchase, or bank operation. Discussion and interactive model: [Ticket-request lifecycle review](t3-thread://v1/5a06ea42-9433-4657-9b04-48ccf671b3b7).
phg 2026-10-22 18:46:58 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
research/design-references
research/voucher-replication
research/apple-web-push
No results found.
Labels
Clear labels   
needs-info

   
needs-triage

   
ready-for-agent

   
ready-for-human

   
wayfinder:grilling

   
wayfinder:map

   
wayfinder:prototype

   
wayfinder:research

   
wayfinder:task

   
wontfix
No labels
needs-info
needs-triage
ready-for-agent
ready-for-human
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wayfinder:task
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
phg
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#7 Decide stalled-voucher and delivery-failure recovery
MISChaufen/prevouch
#9 Define delivery addresses, email templates, and notification preferences
MISChaufen/prevouch
#11 Choose the application architecture and deployment contract
MISChaufen/prevouch
#12 Evaluate member and admin journeys in four live-switchable designs
MISChaufen/prevouch
Depends on
#2 Establish Congress voucher replication and incoming-email evidence
MISChaufen/prevouch
#14 Define allocation policies and organizer-triggered shuffling
MISChaufen/prevouch
#15 Define central-purchase workflow and fulfillment
MISChaufen/prevouch
#16 Define upfront-payment tracking and refunds for central purchases
MISChaufen/prevouch
Reference
MISChaufen/prevouch#5
No description provided.