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

Define allocation policies and organizer-triggered shuffling #14

New issue
Closed
opened 2026-10-22 09:09:15 +00:00 by phg · 6 comments
phg commented 2026-10-22 09:09:15 +00:00
Owner
Copy link

Part of #1

Question

How should the three event-wide allocation policies establish the queue and serve ticket requests when vouchers become available?

Required policies:

  • First come, first served: accepted entry order; requests submitted together remain consecutive and later additions join the back.
  • Shuffled (grouped): an organizer triggers an initial shuffle of request groups when voucher distribution or central purchasing begins, keeping +n requests together.
  • Shuffled (everyone): the organizer-triggered initial shuffle orders individual ticket requests, including companion requests separately.

The human revised the earlier voucher-arrival proposal: the initial shuffle is manual, its resulting order stays fixed, and new entries after it join the end. Voucher arrivals, duplicate messages, retries, and restarts do not trigger shuffling. An event's allocation policy can change until the first voucher is sent or the first ticket is bought by the Orga-team; afterwards it is fixed.

Settle the exact transition into distribution/purchasing, who triggers it, and whether consuming later stock is automatic or organizer-controlled. Decide how additions after the initial shuffle form tail entries/groups without enlarging an earlier group's turn, how quantity reductions and withdrawals affect the fixed order, and how a policy change after the initial shuffle but before the cutoff reconstructs the queue.

Clarify policy-change handling while delivery or organizer checkout is in progress, including an uncertain result. Decide what members see before and after the initial shuffle and what recorded evidence makes the chosen order and any permitted policy changes explainable without an unrequested reroll.

Use Alice/Bob/Cara examples with mixed +n quantities, eight initial vouchers, later additions, and successors. Cover a group larger than available stock and preserve its turn across arrivals. Grouped mode gives each initial group an equal chance; everyone mode gives each initial individual ticket request an equal chance. Preserve exclusive active assignments and the fixed ordering rather than redrawing previously ordered entries.

The allocation contract feeds Define ticket-request allocation and fulfillment. Funding eligibility and its consequences for unpaid or partially paid requests belong to Define upfront-payment tracking and refunds for central purchases, which must apply the chosen ordering contract.

Resolution: an agreed ordering/selection contract and worked examples in a resolution comment, not an allocator implementation. Earlier checkpoints are historical inputs; the latest human revisions supersede their arrival-triggered reshuffling assumptions.

Part of #1 ## Question How should the three event-wide allocation policies establish the queue and serve ticket requests when vouchers become available? Required policies: - **First come, first served**: accepted entry order; requests submitted together remain consecutive and later additions join the back. - **Shuffled (grouped)**: an organizer triggers an initial shuffle of request groups when voucher distribution or central purchasing begins, keeping +n requests together. - **Shuffled (everyone)**: the organizer-triggered initial shuffle orders individual ticket requests, including companion requests separately. The human revised the earlier voucher-arrival proposal: the initial shuffle is manual, its resulting order stays fixed, and new entries after it join the end. Voucher arrivals, duplicate messages, retries, and restarts do not trigger shuffling. An event's allocation policy can change until the first voucher is sent or the first ticket is bought by the Orga-team; afterwards it is fixed. Settle the exact transition into distribution/purchasing, who triggers it, and whether consuming later stock is automatic or organizer-controlled. Decide how additions after the initial shuffle form tail entries/groups without enlarging an earlier group's turn, how quantity reductions and withdrawals affect the fixed order, and how a policy change after the initial shuffle but before the cutoff reconstructs the queue. Clarify policy-change handling while delivery or organizer checkout is in progress, including an uncertain result. Decide what members see before and after the initial shuffle and what recorded evidence makes the chosen order and any permitted policy changes explainable without an unrequested reroll. Use Alice/Bob/Cara examples with mixed +n quantities, eight initial vouchers, later additions, and successors. Cover a group larger than available stock and preserve its turn across arrivals. Grouped mode gives each initial group an equal chance; everyone mode gives each initial individual ticket request an equal chance. Preserve exclusive active assignments and the fixed ordering rather than redrawing previously ordered entries. The allocation contract feeds [Define ticket-request allocation and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/5). Funding eligibility and its consequences for unpaid or partially paid requests belong to [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16), which must apply the chosen ordering contract. Resolution: an agreed ordering/selection contract and worked examples in a resolution comment, not an allocator implementation. Earlier checkpoints are historical inputs; the latest human revisions supersede their arrival-triggered reshuffling assumptions.
phg self-assigned this 2026-10-22 09:19:58 +00:00
phg commented 2026-10-22 09:25:07 +00:00
Author
Owner
Copy link

Planning checkpoint — allocation questions Q10–Q13

The human agreed to the following inputs for this decision. This is a checkpoint, not the final resolution; batch semantics, additions after selection, policy changes, and member-visible progress remain to be settled.

  • One policy per event: every participant in an event shares its First come, first served, Shuffled (grouped), or Shuffled (everyone) policy.
  • Grouped entry: while requests are waiting for selection, one requester's outstanding requests form a single group. Alice requesting three and later adding two has one waiting group of five, rather than two group entries. FCFS still places her later additions at the back. What happens to additions after a group is selected remains open.
  • Selected group keeps its turn: if Alice's group of three is selected with one voucher available, the next two available vouchers go to its remaining requests before another group is selected. New arrivals reshuffle groups still waiting for their turn; an already selected group retains priority.
  • Random selection unit: grouped mode gives each waiting group an equal chance of selection regardless of size; everyone mode gives each individual ticket request an equal chance, including companion requests. Alice +2 and Bob alone have one group entry each in grouped mode, versus three entries and one in everyone mode.

These rules apply to the allocation contract. Funding eligibility, central-purchase fulfillment, and failure/recovery deadlines remain decisions in their existing tickets. Shared terms have been updated in the root glossary.

## Planning checkpoint — allocation questions Q10–Q13 The human agreed to the following inputs for this decision. This is a checkpoint, not the final resolution; batch semantics, additions after selection, policy changes, and member-visible progress remain to be settled. - **One policy per event:** every participant in an event shares its First come, first served, Shuffled (grouped), or Shuffled (everyone) policy. - **Grouped entry:** while requests are waiting for selection, one requester's outstanding requests form a single group. Alice requesting three and later adding two has one waiting group of five, rather than two group entries. FCFS still places her later additions at the back. What happens to additions after a group is selected remains open. - **Selected group keeps its turn:** if Alice's group of three is selected with one voucher available, the next two available vouchers go to its remaining requests before another group is selected. New arrivals reshuffle groups still waiting for their turn; an already selected group retains priority. - **Random selection unit:** grouped mode gives each waiting group an equal chance of selection regardless of size; everyone mode gives each individual ticket request an equal chance, including companion requests. Alice +2 and Bob alone have one group entry each in grouped mode, versus three entries and one in everyone mode. These rules apply to the allocation contract. Funding eligibility, central-purchase fulfillment, and failure/recovery deadlines remain decisions in their existing tickets. Shared terms have been updated in the root glossary.
phg changed title from Define allocation policies and voucher-arrival shuffling to Define allocation policies and organizer-triggered shuffling 2026-10-22 09:36:23 +00:00
phg commented 2026-10-22 09:36:52 +00:00
Author
Owner
Copy link

Planning checkpoint — revised shuffle and policy-change rules (Q14–Q17)

This records the human's latest changes and supersedes the automatic, repeated voucher-arrival shuffling described in earlier checkpoints. The decision remains open.

  • Q14 agreed: a selected group's membership is frozen. Alice receiving one voucher for her selected group of three keeps priority for the original two remaining requests; later requests cannot extend that turn.
  • Q15 revised: an organizer triggers the shuffle; it is not automatic.
  • Q16 revised: the allocation policy may change until the first voucher has been sent to a member, or the first ticket has been bought by the Orga-team in central purchase. After that it is fixed. This replaces the earlier recommendation to lock at the first queue join.
  • Q17 revised: shuffled modes have an initial shuffle when voucher distribution or ticket purchasing begins; their resulting order then stays fixed. New entries after the shuffle join the end. Voucher arrivals do not cause new shuffles.

Still to clarify: post-shuffle additions and grouping, permitted policy changes between initial shuffle and first send/purchase, in-progress work at that boundary, ongoing allocation triggers, member-visible positions, and the record of the initial ordering. Funding and central-purchase fulfillment remain with their own decisions.

The map, lifecycle, recovery, administrator, architecture, funding, and prototype scopes and the glossary are updated to match the revised trigger and fixed-order requirement.

## Planning checkpoint — revised shuffle and policy-change rules (Q14–Q17) This records the human's latest changes and supersedes the automatic, repeated voucher-arrival shuffling described in earlier checkpoints. The decision remains open. - **Q14 agreed:** a selected group's membership is frozen. Alice receiving one voucher for her selected group of three keeps priority for the original two remaining requests; later requests cannot extend that turn. - **Q15 revised:** an organizer triggers the shuffle; it is not automatic. - **Q16 revised:** the allocation policy may change until the first voucher has been sent to a member, or the first ticket has been bought by the Orga-team in central purchase. After that it is fixed. This replaces the earlier recommendation to lock at the first queue join. - **Q17 revised:** shuffled modes have an initial shuffle when voucher distribution or ticket purchasing begins; their resulting order then stays fixed. New entries after the shuffle join the end. Voucher arrivals do not cause new shuffles. Still to clarify: post-shuffle additions and grouping, permitted policy changes between initial shuffle and first send/purchase, in-progress work at that boundary, ongoing allocation triggers, member-visible positions, and the record of the initial ordering. Funding and central-purchase fulfillment remain with their own decisions. The map, lifecycle, recovery, administrator, architecture, funding, and prototype scopes and the glossary are updated to match the revised trigger and fixed-order requirement.
phg commented 2026-10-22 09:47:59 +00:00
Author
Owner
Copy link

Planning checkpoint — allocation questions Q18–Q21

The human agreed to all four recommendations. This records inputs to the still-open allocation decision; it is not its final resolution.

  • Post-shuffle groups: every later submission forms a new group at the end, including extra requests from someone who already has a group waiting or being served. Before the initial shuffle, requests from the same person consolidate into one group. For an initial order Alice(3), Bob(2), Alice adding two produces Alice(3), Bob(2), Alice(2).
  • Permitted policy changes: after a shuffle but before the first voucher sent or first ticket bought, changing allocation policy rebuilds the waiting order under the new policy. FCFS uses original request timestamps; switching to a shuffled policy requires a fresh organizer-triggered shuffle. Preserve the prior order and policy change in history. Handling assignments or checkout already in progress still needs clarification.
  • Later stock: after the organizer establishes the shuffled order, new accepted vouchers automatically serve the next eligible requests in that fixed order. Self-purchase sends vouchers to members; central purchase creates purchasing assignments for the Orga-team. No further shuffle occurs, and central purchase does not disclose codes to members.
  • Visible progress: members see their own current queue positions and group progress after shuffling. Before the initial shuffle, show that the event awaits the organizer's shuffle without presenting a final rank. Positions advance as earlier requests are served or withdrawn.

Remaining allocation boundaries: how distribution starts in FCFS, how policy changes interact with active or uncertain sends/purchases, and what evidence is retained for the shuffle. Funding eligibility and central-purchase fulfillment remain in their existing decisions.

## Planning checkpoint — allocation questions Q18–Q21 The human agreed to all four recommendations. This records inputs to the still-open allocation decision; it is not its final resolution. - **Post-shuffle groups:** every later submission forms a new group at the end, including extra requests from someone who already has a group waiting or being served. Before the initial shuffle, requests from the same person consolidate into one group. For an initial order Alice(3), Bob(2), Alice adding two produces Alice(3), Bob(2), Alice(2). - **Permitted policy changes:** after a shuffle but before the first voucher sent or first ticket bought, changing allocation policy rebuilds the waiting order under the new policy. FCFS uses original request timestamps; switching to a shuffled policy requires a fresh organizer-triggered shuffle. Preserve the prior order and policy change in history. Handling assignments or checkout already in progress still needs clarification. - **Later stock:** after the organizer establishes the shuffled order, new accepted vouchers automatically serve the next eligible requests in that fixed order. Self-purchase sends vouchers to members; central purchase creates purchasing assignments for the Orga-team. No further shuffle occurs, and central purchase does not disclose codes to members. - **Visible progress:** members see their own current queue positions and group progress after shuffling. Before the initial shuffle, show that the event awaits the organizer's shuffle without presenting a final rank. Positions advance as earlier requests are served or withdrawn. Remaining allocation boundaries: how distribution starts in FCFS, how policy changes interact with active or uncertain sends/purchases, and what evidence is retained for the shuffle. Funding eligibility and central-purchase fulfillment remain in their existing decisions.
phg commented 2026-10-22 09:53:12 +00:00
Author
Owner
Copy link

Planning checkpoint — allocation questions Q22–Q24

The human agreed to all three recommendations. These complete the remaining allocation boundaries; the consolidated contract and examples will receive a final shared-understanding check before this ticket is resolved.

  • Explicit start for every policy: an organizer starts distribution/purchasing for FCFS and both shuffled modes. Shuffled modes establish their initial order then; FCFS uses accepted entry order. Available stock accumulates without distribution before that action. Afterwards, allocation proceeds automatically.
  • Changes while work is active: hold a policy change until any send or purchase outcome is known. Pause allocation and finish or safely release outstanding work first. If nothing was sent or bought, policy changes remain possible. The first successful send or purchase permanently locks the policy; uncertain outcomes require recovery before proceeding.
  • Recorded order and history: retain who started the shuffle, when, the policy, included requests/groups, and resulting order. Record permitted policy changes and replacement orders. Repeating the start action or reloading reuses the recorded order rather than drawing again.

Funding eligibility, central-purchase fulfillment, and detailed recovery procedures remain with their existing decisions.

## Planning checkpoint — allocation questions Q22–Q24 The human agreed to all three recommendations. These complete the remaining allocation boundaries; the consolidated contract and examples will receive a final shared-understanding check before this ticket is resolved. - **Explicit start for every policy:** an organizer starts distribution/purchasing for FCFS and both shuffled modes. Shuffled modes establish their initial order then; FCFS uses accepted entry order. Available stock accumulates without distribution before that action. Afterwards, allocation proceeds automatically. - **Changes while work is active:** hold a policy change until any send or purchase outcome is known. Pause allocation and finish or safely release outstanding work first. If nothing was sent or bought, policy changes remain possible. The first successful send or purchase permanently locks the policy; uncertain outcomes require recovery before proceeding. - **Recorded order and history:** retain who started the shuffle, when, the policy, included requests/groups, and resulting order. Record permitted policy changes and replacement orders. Repeating the start action or reloading reuses the recorded order rather than drawing again. Funding eligibility, central-purchase fulfillment, and detailed recovery procedures remain with their existing decisions.
phg commented 2026-10-22 09:56:50 +00:00
Author
Owner
Copy link

Resolution — allocation policies and organizer-triggered shuffling

This consolidates the human's agreements and revisions during the grilling. It supersedes earlier checkpoint proposals for automatic reshuffling on voucher arrival and locking the policy at the first queue join.

Event policy and distribution start

Each event has one allocation policy shared by its participants:

  • First come, first served: serve requests in their original accepted entry order. Requests submitted together are consecutive; later additions join the back. Preserve a stable accepted order for simultaneous submissions.
  • Shuffled (grouped): the organizer-triggered initial shuffle gives every initial request group an equal chance, irrespective of group size. Serve the resulting groups consecutively.
  • Shuffled (everyone): the organizer-triggered initial shuffle gives every individual ticket request an equal chance. A requester's own and +n companion requests are separate entries and can be separated in the resulting order.

Every policy requires an explicit organizer start action. Before start, usable voucher stock may accumulate without distribution. Starting a shuffled event establishes and records its initial order; starting FCFS uses accepted entry order. This decision concerns allocation policy; the scope of self-purchase versus central purchase remains in its own decision.

After start, accepted usable stock automatically serves the next eligible requests in the established order. In self-purchase this sends vouchers to members; in central purchase it creates purchasing assignments for the Orga-team. Central-purchase members never receive voucher codes. This allocation decision does not choose automated external checkout.

Fixed order, groups, and later entries

The shuffled order stays fixed. Voucher arrivals, batches of eight, duplicate mail, retries, restarts, page reloads, or repeating the start action do not trigger another draw. Consume later stock against the existing order.

For the initial grouped shuffle, all requests registered by one requester consolidate into one group, including additions before that shuffle. After the shuffle, every new submission creates a new group at the end, even if that person already has an earlier waiting or partly served group. Later additions cannot enlarge or extend an earlier group's turn.

A partly served group keeps its turn across voucher arrivals: its original remaining requests receive available vouchers before another group is served. This preserves contiguity; it does not promise sufficient stock to complete the group.

In everyone mode, new submissions append their individual requests at the end without shuffling the existing order. FCFS additions always append under accepted entry order. A permitted withdrawal removes the request from the current waiting order; rejoining is new demand rather than restoration of an earlier position. Lifecycle and funding decisions determine when withdrawal is permitted and any financial consequences.

Retain request identities and exclusive active assignments. One voucher and one request may participate in at most one active assignment each; retries reuse the assignment rather than allocating a second voucher. Historical safely released assignments may remain recorded.

Policy changes and the permanent lock

The event's allocation policy may change until the first successful voucher send to a member in self-purchase mode, or the first ticket bought by the Orga-team in central-purchase mode. After that milestone, the allocation policy is permanently fixed. Merely joining, starting, shuffling, reserving a voucher, or receiving an upfront payment is not that permanent-lock milestone.

For a permitted policy change, pause allocation and finish or safely release outstanding work first. A send or seller checkout that is in progress or has an uncertain outcome holds the change until its outcome is known. If it resolves without a successful send or purchase and outstanding work is safely released, policy changes remain possible. Uncertain or disclosed-voucher cases use the recovery policy rather than an automatic reassignment.

Changing policy before the lock rebuilds the waiting order under the new policy: FCFS uses original accepted request timestamps/order, and a shuffled policy requires a fresh explicit organizer shuffle. Keep the prior order and the policy change in history. Repeating the same start action without a permitted policy change reuses the already recorded result.

Member progress and recorded evidence

Members see their own current positions and group progress once the shuffled order exists. Before it exists, show that the event awaits the organizer's shuffle without a final rank. FCFS can show its current accepted-order positions. Positions advance as earlier requests are served or withdrawn; new tail entries do not jump ahead.

Record who started the shuffle, when, the selected policy, included requests/groups, and resulting order. Preserve permitted policy changes and replacement orders. Broader identity visibility and permissions belong to the administrator decision; this contract establishes the evidence that must exist, not its storage technology.

Worked examples

All examples assume the requests are eligible and each accepted voucher can serve any request in the event's pool. Alice requests self +2 (three requests), Bob self +1 (two), and Cara self +3 (four): nine requests for eight initial vouchers. Individual labels below identify requests, not separately decided companion identities.

  1. FCFS: Alice joins before Bob, who joins before Cara. The first eight serve Alice's three, Bob's two, and Cara's first three. Cara's fourth is next when another voucher arrives. A later addition by Alice goes behind Cara's remaining request.
  2. Shuffled (grouped): suppose the recorded group order is Bob(2), Cara(4), Alice(3). The first eight serve Bob's two, Cara's four, and Alice's first two. Alice's original third request retains priority for the next voucher. If Bob then adds two and Alice subsequently adds two, the remaining order is Alice's original third request, Bob's new two, then Alice's new two. Alice cannot extend her original turn ahead of Bob's later group. Successors arriving one at a time consume this order without another shuffle.
  3. Shuffled (everyone): suppose the recorded individual order is C1, A1, B1, C2, A2, C3, B2, C4, A3. The first eight serve Cara's four, Alice's first two, and Bob's two; A3 is next. Parties are split by the individual shuffle. New requests append after A3; they do not trigger a new draw.
  4. Policy change: an organizer starts a shuffled event while no voucher has been sent and no central ticket bought. With no active or uncertain work, they change to FCFS: rebuild from original accepted request order. Switching to a shuffled policy requires a fresh explicit shuffle. Record each replaced order. After the first successful send or central purchase, the same policy change is unavailable.
  5. Replay and uncertain work: retrying the start action with the same event state reuses its recorded ordering. A sender or organizer checkout whose result is unknown holds a policy change for recovery; it does not authorize a redraw or reallocation of an exposed voucher.

Contracts with the remaining decisions

No additional allocation ticket is needed. The already-open lifecycle, purchase, funding, recovery, administration, architecture, and prototype decisions hold the remaining work toward the map's destination.

## Resolution — allocation policies and organizer-triggered shuffling This consolidates the human's agreements and revisions during the grilling. It supersedes earlier checkpoint proposals for automatic reshuffling on voucher arrival and locking the policy at the first queue join. ### Event policy and distribution start Each event has one allocation policy shared by its participants: - **First come, first served:** serve requests in their original accepted entry order. Requests submitted together are consecutive; later additions join the back. Preserve a stable accepted order for simultaneous submissions. - **Shuffled (grouped):** the organizer-triggered initial shuffle gives every initial request group an equal chance, irrespective of group size. Serve the resulting groups consecutively. - **Shuffled (everyone):** the organizer-triggered initial shuffle gives every individual ticket request an equal chance. A requester's own and +n companion requests are separate entries and can be separated in the resulting order. Every policy requires an explicit organizer start action. Before start, usable voucher stock may accumulate without distribution. Starting a shuffled event establishes and records its initial order; starting FCFS uses accepted entry order. This decision concerns allocation policy; the scope of self-purchase versus central purchase remains in its own decision. After start, accepted usable stock automatically serves the next eligible requests in the established order. In self-purchase this sends vouchers to members; in central purchase it creates purchasing assignments for the Orga-team. Central-purchase members never receive voucher codes. This allocation decision does not choose automated external checkout. ### Fixed order, groups, and later entries The shuffled order stays fixed. Voucher arrivals, batches of eight, duplicate mail, retries, restarts, page reloads, or repeating the start action do not trigger another draw. Consume later stock against the existing order. For the initial grouped shuffle, all requests registered by one requester consolidate into one group, including additions before that shuffle. After the shuffle, every new submission creates a new group at the end, even if that person already has an earlier waiting or partly served group. Later additions cannot enlarge or extend an earlier group's turn. A partly served group keeps its turn across voucher arrivals: its original remaining requests receive available vouchers before another group is served. This preserves contiguity; it does not promise sufficient stock to complete the group. In everyone mode, new submissions append their individual requests at the end without shuffling the existing order. FCFS additions always append under accepted entry order. A permitted withdrawal removes the request from the current waiting order; rejoining is new demand rather than restoration of an earlier position. Lifecycle and funding decisions determine when withdrawal is permitted and any financial consequences. Retain request identities and exclusive active assignments. One voucher and one request may participate in at most one active assignment each; retries reuse the assignment rather than allocating a second voucher. Historical safely released assignments may remain recorded. ### Policy changes and the permanent lock The event's allocation policy may change until the first successful voucher send to a member in self-purchase mode, or the first ticket bought by the Orga-team in central-purchase mode. After that milestone, the allocation policy is permanently fixed. Merely joining, starting, shuffling, reserving a voucher, or receiving an upfront payment is not that permanent-lock milestone. For a permitted policy change, pause allocation and finish or safely release outstanding work first. A send or seller checkout that is in progress or has an uncertain outcome holds the change until its outcome is known. If it resolves without a successful send or purchase and outstanding work is safely released, policy changes remain possible. Uncertain or disclosed-voucher cases use the recovery policy rather than an automatic reassignment. Changing policy before the lock rebuilds the waiting order under the new policy: FCFS uses original accepted request timestamps/order, and a shuffled policy requires a fresh explicit organizer shuffle. Keep the prior order and the policy change in history. Repeating the same start action without a permitted policy change reuses the already recorded result. ### Member progress and recorded evidence Members see their own current positions and group progress once the shuffled order exists. Before it exists, show that the event awaits the organizer's shuffle without a final rank. FCFS can show its current accepted-order positions. Positions advance as earlier requests are served or withdrawn; new tail entries do not jump ahead. Record who started the shuffle, when, the selected policy, included requests/groups, and resulting order. Preserve permitted policy changes and replacement orders. Broader identity visibility and permissions belong to the administrator decision; this contract establishes the evidence that must exist, not its storage technology. ### Worked examples All examples assume the requests are eligible and each accepted voucher can serve any request in the event's pool. Alice requests self +2 (three requests), Bob self +1 (two), and Cara self +3 (four): nine requests for eight initial vouchers. Individual labels below identify requests, not separately decided companion identities. 1. **FCFS:** Alice joins before Bob, who joins before Cara. The first eight serve Alice's three, Bob's two, and Cara's first three. Cara's fourth is next when another voucher arrives. A later addition by Alice goes behind Cara's remaining request. 2. **Shuffled (grouped):** suppose the recorded group order is Bob(2), Cara(4), Alice(3). The first eight serve Bob's two, Cara's four, and Alice's first two. Alice's original third request retains priority for the next voucher. If Bob then adds two and Alice subsequently adds two, the remaining order is Alice's original third request, Bob's new two, then Alice's new two. Alice cannot extend her original turn ahead of Bob's later group. Successors arriving one at a time consume this order without another shuffle. 3. **Shuffled (everyone):** suppose the recorded individual order is C1, A1, B1, C2, A2, C3, B2, C4, A3. The first eight serve Cara's four, Alice's first two, and Bob's two; A3 is next. Parties are split by the individual shuffle. New requests append after A3; they do not trigger a new draw. 4. **Policy change:** an organizer starts a shuffled event while no voucher has been sent and no central ticket bought. With no active or uncertain work, they change to FCFS: rebuild from original accepted request order. Switching to a shuffled policy requires a fresh explicit shuffle. Record each replaced order. After the first successful send or central purchase, the same policy change is unavailable. 5. **Replay and uncertain work:** retrying the start action with the same event state reuses its recorded ordering. A sender or organizer checkout whose result is unknown holds a policy change for recovery; it does not authorize a redraw or reallocation of an exposed voucher. ### Contracts with the remaining decisions - [Define ticket-request allocation and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/5) composes this ordering contract into the lifecycle across both purchase modes, retaining the earlier self-purchase delivery evidence and voucher-class rules where applicable. - [Define central-purchase workflow and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/15) decides purchase-mode scope, organizer work, purchase evidence, ticket delivery, and central fulfillment. - [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16) decides funding eligibility, unpaid/partially paid requests, late payment, and refunds. Those rules must apply the established order rather than silently reshuffling it; any required revision to group continuity must be explicit. - [Decide stalled-voucher and delivery-failure recovery](https://git.s1q.dev/MISChaufen/prevouch/issues/7) supplies recovery procedures, deadlines, safe release, and any explicit exception for stalled or ineligible work. This ordering contract does not invent those exceptions. - [Define administrator authority, queue visibility, and event lifecycle](https://git.s1q.dev/MISChaufen/prevouch/issues/10) supplies organizer permissions, broader queue visibility, and event operations while respecting this start/change/lock contract. - [Choose the application architecture and deployment contract](https://git.s1q.dev/MISChaufen/prevouch/issues/11) chooses how to persist and serialize these actions; [Evaluate member and admin journeys in four live-switchable designs](https://git.s1q.dev/MISChaufen/prevouch/issues/12) demonstrates the agreed states with simulated integrations. No additional allocation ticket is needed. The already-open lifecycle, purchase, funding, recovery, administration, architecture, and prototype decisions hold the remaining work toward the map's destination.
phg 2026-10-22 09:56:52 +00:00
phg commented 2026-10-22 13:28:42 +00:00
Author
Owner
Copy link

Funding qualification to group continuity

The agreed resolution in Define upfront-payment tracking and refunds for central purchases now supplies the explicit funding/eligibility qualification to this decision's grouped-turn continuity rule. Apply its “Funding eligibility and queue order” section, including restoration after another group's active turn. That ticket remains the canonical source for the qualification; this allocation-policy decision remains resolved.

## Funding qualification to group continuity The agreed resolution in [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16) now supplies the explicit funding/eligibility qualification to this decision's grouped-turn continuity rule. Apply its “Funding eligibility and queue order” section, including restoration after another group's active turn. That ticket remains the canonical source for the qualification; this allocation-policy decision remains resolved.
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
#5 Define ticket-request allocation and fulfillment
MISChaufen/prevouch
#10 Define administrator authority, queue visibility, and event lifecycle
MISChaufen/prevouch
#16 Define upfront-payment tracking and refunds for central purchases
MISChaufen/prevouch
Reference
MISChaufen/prevouch#14
No description provided.