MISChaufen/prevouch

Fork 0

Choose successor routing and incoming-voucher trust rules #6

New issue

Open

opened 2026-10-20 21:29:36 +00:00 by phg · 3 comments

phg commented

2026-10-20 21:29:36 +00:00

Owner

Part of #1

Question

How should prevouch choose return addresses, associate incoming vouchers with the correct event and prior assignment, and decide which messages are safe to distribute?

Use the replication research to compare return-address scopes (event, chain, or assignment), real transport recipients versus editable email headers, and what operators must configure. Decide initial-batch ingestion, parsing and validation boundaries, duplicate and replay handling, unknown or malformed messages, ambiguous correlation, and manual correction. Separate evidence the system actually receives from assumptions about purchase or payment.

The person buying from the seller must be able to copy the correct prevouch-owned return address at checkout: the member in self-purchase mode, or the Orga-team in central-purchase mode. Account email, delivery address, and return address are distinct concepts. Resolve the externally observable contract and its trust assumptions; defer provider/library selection to architecture.

Routing evidence prerequisite: Obtain redacted evidence of successor-address routing must establish the actual recipient field and trusted ingress behavior before treating per-assignment aliases as a verified integration contract. The research distinguishes routing correlation from proof of authenticity or causal lineage.

Support both purchase modes from Define central-purchase workflow and fulfillment. Decide the organizer-facing return-address and voucher-access contract for central purchases without disclosing voucher codes to members. Routing correlation must work for organizer purchases as well as self-purchases; the existing evidence prerequisite still applies.

Part of #1 ## Question How should prevouch choose return addresses, associate incoming vouchers with the correct event and prior assignment, and decide which messages are safe to distribute? Use the replication research to compare return-address scopes (event, chain, or assignment), real transport recipients versus editable email headers, and what operators must configure. Decide initial-batch ingestion, parsing and validation boundaries, duplicate and replay handling, unknown or malformed messages, ambiguous correlation, and manual correction. Separate evidence the system actually receives from assumptions about purchase or payment. The person buying from the seller must be able to copy the correct prevouch-owned return address at checkout: the member in self-purchase mode, or the Orga-team in central-purchase mode. Account email, delivery address, and return address are distinct concepts. Resolve the externally observable contract and its trust assumptions; defer provider/library selection to architecture. Routing evidence prerequisite: [Obtain redacted evidence of successor-address routing](https://git.s1q.dev/MISChaufen/prevouch/issues/13) must establish the actual recipient field and trusted ingress behavior before treating per-assignment aliases as a verified integration contract. The research distinguishes routing correlation from proof of authenticity or causal lineage. Support both purchase modes from [Define central-purchase workflow and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/15). Decide the organizer-facing return-address and voucher-access contract for central purchases without disclosing voucher codes to members. Routing correlation must work for organizer purchases as well as self-purchases; the existing evidence prerequisite still applies.

phg added the

wayfinder:grilling

needs-info

labels

2026-10-20 21:29:36 +00:00

phg added a new dependency

2026-10-20 21:29:43 +00:00

#2 Establish Congress voucher replication and incoming-email evidence

phg added a new dependency

2026-10-20 21:29:44 +00:00

#7 Decide stalled-voucher and delivery-failure recovery

phg added a new dependency

2026-10-20 21:29:44 +00:00

#11 Choose the application architecture and deployment contract

phg added a new dependency

2026-10-20 21:29:45 +00:00

#12 Evaluate member and admin journeys in four live-switchable designs

phg referenced this issue

2026-10-20 21:29:45 +00:00

Plan prevouch: specification and four-design prototype #1

phg referenced this issue

2026-10-20 21:40:25 +00:00

Obtain redacted evidence of successor-address routing #13

phg added a new dependency

2026-10-20 21:40:54 +00:00

#13 Obtain redacted evidence of successor-address routing

phg added a new dependency

2026-10-22 09:13:49 +00:00

#15 Define central-purchase workflow and fulfillment

phg referenced this issue

2026-10-22 10:22:52 +00:00

Define central-purchase workflow and fulfillment #15

phg referenced this issue

2026-10-22 10:44:22 +00:00

Define central-purchase workflow and fulfillment #15

phg referenced this issue

2026-10-22 18:46:51 +00:00

Define ticket-request allocation and fulfillment #5

phg self-assigned this

2026-10-22 18:49:43 +00:00

phg commented

2026-10-22 19:01:07 +00:00

Author

Owner

Planning checkpoint — successor routing and incoming-voucher trust Q1–Q4

The human agreed to all four recommendations. These are inputs to this open decision, not a final resolution or a verified seller integration.

Q1 — return-address scope: select one opaque prevouch-owned return address per voucher assignment, identifying its intended event and assignment without exposing personal information. The member copies it at checkout in self-purchase; the claiming organizer copies it in central purchase. Actual seller use of the address and preservation through controlled ingress remain unverified. Delivery to the alias does not establish message authenticity or causal voucher lineage.
Q2 — initial vouchers: support manual batch import with explicit event and voucher class, individual validation results, and review before accepted vouchers become usable stock. Forwarded messages may enter the review inbox.
Q3 — automatic acceptance: accept automatically only when all required checks pass: trusted delivery metadata, an approved issuer-authentication rule, an unambiguous event, successful parsing, a known voucher class, and duplicate checks. Exact evidence and validation rules remain to be settled. Recognizable sender text or an alias alone is insufficient.
Q4 — uncertain input: hold malformed messages, unknown senders, uncertain classes, and routing conflicts for operator review, outside usable stock, with a visible reason. Corrections retain original evidence and an audit history. An incoming message never silently changes existing assignments, purchases, or fulfillment outcomes.

The glossary now distinguishes a held voucher and sharpens return address. Remaining discussion includes exact issuer-authentication evidence, parsing and deduplication, event/assignment conflicts and lineage, alias lifetime, multi-request central checkout, and safe operator corrections.

Obtain redacted evidence of successor-address routing remains an open native prerequisite. The selected per-assignment contract must not be described as verified until that evidence is inspected. No resolution or map Decisions-so-far entry is made at this checkpoint.

Discussion: Successor routing and incoming-voucher trust.

## Planning checkpoint — successor routing and incoming-voucher trust Q1–Q4 The human agreed to all four recommendations. These are inputs to this open decision, not a final resolution or a verified seller integration. - **Q1 — return-address scope:** select one opaque prevouch-owned return address per voucher assignment, identifying its intended event and assignment without exposing personal information. The member copies it at checkout in self-purchase; the claiming organizer copies it in central purchase. Actual seller use of the address and preservation through controlled ingress remain unverified. Delivery to the alias does not establish message authenticity or causal voucher lineage. - **Q2 — initial vouchers:** support manual batch import with explicit event and voucher class, individual validation results, and review before accepted vouchers become usable stock. Forwarded messages may enter the review inbox. - **Q3 — automatic acceptance:** accept automatically only when all required checks pass: trusted delivery metadata, an approved issuer-authentication rule, an unambiguous event, successful parsing, a known voucher class, and duplicate checks. Exact evidence and validation rules remain to be settled. Recognizable sender text or an alias alone is insufficient. - **Q4 — uncertain input:** hold malformed messages, unknown senders, uncertain classes, and routing conflicts for operator review, outside usable stock, with a visible reason. Corrections retain original evidence and an audit history. An incoming message never silently changes existing assignments, purchases, or fulfillment outcomes. The glossary now distinguishes a held voucher and sharpens return address. Remaining discussion includes exact issuer-authentication evidence, parsing and deduplication, event/assignment conflicts and lineage, alias lifetime, multi-request central checkout, and safe operator corrections. [Obtain redacted evidence of successor-address routing](https://git.s1q.dev/MISChaufen/prevouch/issues/13) remains an open native prerequisite. The selected per-assignment contract must not be described as verified until that evidence is inspected. No resolution or map Decisions-so-far entry is made at this checkpoint. Discussion: [Successor routing and incoming-voucher trust](t3-thread://v1/9e718e5e-7106-4c66-91b4-497100bf0f98).

phg commented

2026-10-22 19:30:56 +00:00

Author

Owner

Planning checkpoint — successor routing and incoming-voucher trust Q5–Q10

The human agreed to Q5–Q10, adding that duplicate arrivals must be recorded and brought to the organizers' attention: the sender may be a member returning an unwanted voucher. These are inputs to this open decision, not its final resolution.

Q5 — identity and duplicates: maintain one voucher per seller event and code across mail, import, and return-address paths. Preserve code spelling unless seller-documented normalization applies. Retain repeated arrivals as evidence; duplicate receipt must never create additional stock or automatically reactivate an assigned or used voucher. Conflicting details require review. Record duplicate arrivals and notify organizers. A returned unwanted voucher is a possible explanation, not an inferred fact; notification grouping and the recovery handoff for a possible return remain to be clarified.
Q6 — parsing: automatic parsing is limited to explicitly supported message formats. Repeated appearances across languages and MIME alternatives identify one voucher. Distinct, individually identifiable vouchers may produce separate candidates. Contradictory/ambiguous content is held; missing voucher class requires operator classification.
Q7 — correlation versus lineage: an otherwise accepted voucher may enter the event's stock when its event is unambiguous but its predecessor is unknown. Record unknown lineage rather than inventing it. An alias establishes the delivery destination, not the purchase that produced the voucher. Conflicting event evidence is held for review. This does not relax the trusted-ingress or other automatic-acceptance requirements.
Q8 — address lifetime: preserve each return address's historical assignment association and never reuse it for another assignment. Late arrivals keep the original association and undergo normal validation. An arrival for a finalized event goes to review rather than restarting allocation.
Q9 — central checkout batching: use separate checkouts unless the seller supports a distinct return address for every assigned voucher. Do not silently sacrifice individual assignment correlation to batch several vouchers under one return address. This restricts the previously permitted multi-request seller orders to cases that satisfy the selected addressing contract; actual seller capabilities remain unverified.
Q10 — authentication: automatic acceptance requires trusted ingress metadata containing the original envelope recipient and bound to the received message, plus a verified signature from an explicitly approved issuer that covers the complete body and every header used by the parser. Sender text, SPF/DMARC pass alone, and forwarded authentication-result headers do not qualify. Missing, failed, or incomplete verification is held for review. Qualifying identity and required coverage must belong to the same verified signature. This is application policy, not a universal mail-standard requirement or a claim that actual Congress messages already meet it. Authentication does not establish voucher usability, payment, or predecessor lineage.

Bounded supporting research is complete in the working checkout at docs/research/incoming-voucher-email-trust.md. Primary sources include Authentication-Results trust boundaries, DKIM header selection, and DKIM unsigned content risks. The sourced note has not been committed/published; this comment records the agreed policy independently of that local asset.

Remaining questions: duplicate-notification handling and suspected returns, allowed manual approval/corrections and evidence, operational configuration and acceptance gates, and final shared understanding. Detailed safety evidence before reassigning a disclosed voucher belongs to Decide stalled-voucher and delivery-failure recovery; notification channels/preferences belong to Define delivery addresses, email templates, and notification preferences.

Obtain redacted evidence of successor-address routing remains open. No ticket is closed and no map Decisions-so-far entry is added here.

Discussion: Successor routing and incoming-voucher trust.

## Planning checkpoint — successor routing and incoming-voucher trust Q5–Q10 The human agreed to Q5–Q10, adding that duplicate arrivals must be recorded and brought to the organizers' attention: the sender may be a member returning an unwanted voucher. These are inputs to this open decision, not its final resolution. - **Q5 — identity and duplicates:** maintain one voucher per seller event and code across mail, import, and return-address paths. Preserve code spelling unless seller-documented normalization applies. Retain repeated arrivals as evidence; duplicate receipt must never create additional stock or automatically reactivate an assigned or used voucher. Conflicting details require review. Record duplicate arrivals and notify organizers. A returned unwanted voucher is a possible explanation, not an inferred fact; notification grouping and the recovery handoff for a possible return remain to be clarified. - **Q6 — parsing:** automatic parsing is limited to explicitly supported message formats. Repeated appearances across languages and MIME alternatives identify one voucher. Distinct, individually identifiable vouchers may produce separate candidates. Contradictory/ambiguous content is held; missing voucher class requires operator classification. - **Q7 — correlation versus lineage:** an otherwise accepted voucher may enter the event's stock when its event is unambiguous but its predecessor is unknown. Record unknown lineage rather than inventing it. An alias establishes the delivery destination, not the purchase that produced the voucher. Conflicting event evidence is held for review. This does not relax the trusted-ingress or other automatic-acceptance requirements. - **Q8 — address lifetime:** preserve each return address's historical assignment association and never reuse it for another assignment. Late arrivals keep the original association and undergo normal validation. An arrival for a finalized event goes to review rather than restarting allocation. - **Q9 — central checkout batching:** use separate checkouts unless the seller supports a distinct return address for every assigned voucher. Do not silently sacrifice individual assignment correlation to batch several vouchers under one return address. This restricts the previously permitted multi-request seller orders to cases that satisfy the selected addressing contract; actual seller capabilities remain unverified. - **Q10 — authentication:** automatic acceptance requires trusted ingress metadata containing the original envelope recipient and bound to the received message, plus a verified signature from an explicitly approved issuer that covers the complete body and every header used by the parser. Sender text, SPF/DMARC pass alone, and forwarded authentication-result headers do not qualify. Missing, failed, or incomplete verification is held for review. Qualifying identity and required coverage must belong to the same verified signature. This is application policy, not a universal mail-standard requirement or a claim that actual Congress messages already meet it. Authentication does not establish voucher usability, payment, or predecessor lineage. Bounded supporting research is complete in the working checkout at `docs/research/incoming-voucher-email-trust.md`. Primary sources include [Authentication-Results trust boundaries](https://datatracker.ietf.org/doc/html/rfc8601#section-5), [DKIM header selection](https://www.rfc-editor.org/rfc/rfc6376.html#section-5.4), and [DKIM unsigned content risks](https://www.rfc-editor.org/rfc/rfc6376.html#section-8.2). The sourced note has not been committed/published; this comment records the agreed policy independently of that local asset. Remaining questions: duplicate-notification handling and suspected returns, allowed manual approval/corrections and evidence, operational configuration and acceptance gates, and final shared understanding. Detailed safety evidence before reassigning a disclosed voucher belongs to [Decide stalled-voucher and delivery-failure recovery](https://git.s1q.dev/MISChaufen/prevouch/issues/7); notification channels/preferences belong to [Define delivery addresses, email templates, and notification preferences](https://git.s1q.dev/MISChaufen/prevouch/issues/9). [Obtain redacted evidence of successor-address routing](https://git.s1q.dev/MISChaufen/prevouch/issues/13) remains open. No ticket is closed and no map Decisions-so-far entry is added here. Discussion: [Successor routing and incoming-voucher trust](t3-thread://v1/9e718e5e-7106-4c66-91b4-497100bf0f98).

phg commented

2026-10-22 19:37:53 +00:00

Author

Owner

Planning checkpoint — successor routing and incoming-voucher trust Q11–Q14

The human agreed to all four recommendations. This settles the remaining policy questions discussed so far. A final shared-understanding check and the existing routing-evidence prerequisite remain outstanding; this is not a final resolution.

Q11 — duplicate notifications and suspected returns: maintain one organizer review item per voucher, recording every duplicate arrival. Notify when it first needs attention; subsequent repeats update the item, while new actionable information triggers another notification. Use internal references without voucher codes in notification content. A suspected user return enters recovery, without automatically releasing the voucher or undoing the original request's recorded fulfillment. Detailed safe-reassignment evidence belongs to Decide stalled-voucher and delivery-failure recovery, and notification channels/preferences to Define delivery addresses, email templates, and notification preferences.
Q12 — manual review and correction: an operator may approve legitimate manual imports or forwarded messages, including inputs that did not meet automatic checks, using recorded source evidence and a reason. Establish the correct event and voucher class; retain mandatory duplicate protection. Corrections preserve original evidence and history. Changes affecting an already assigned or disclosed voucher require recovery instead of rewriting the historical association. Detailed operator authority and access remain with Define administrator authority, queue visibility, and event lifecycle.
Q13 — acceptance and usability: acceptance applies available evidence and known restrictions, including event, class, format, and established expiry or invalidation. A usable voucher is suitable for attempted use subject to seller availability; acceptance is not proof or a guarantee of redemption. Do not redeem codes or create seller orders just to validate incoming stock. No API/provider or automatic checkout is selected here.
Q14 — automation enablement: reviewed manual ingestion remains available while event-specific mail and routing behavior are unverified. Keep automatic acceptance disabled until issuer profile, supported parsing rules, required signature coverage, and original-recipient handling have passed documented checks. Missing configuration and verification failures hold arrivals for review. Agreement to these gates does not itself verify an event or satisfy the routing prerequisite.

The glossary now names usable voucher and voucher return, keeping acceptance, recipient intent, and safe-reassignment evidence distinct.

The prior agreements Q1–Q10 remain in force: one opaque permanent return address per assignment; reviewed initial batches; controlled ingress and approved full-content authentication; supported parsing; event-and-code deduplication; no inferred lineage/payment/fulfillment; review of uncertainty and finalized-event arrivals; and separate central checkouts unless every voucher can retain its distinct return address. Suitable accepted stock joins the event's common allocation pool under its established policy and purchase mode.

Outstanding verification

Obtain redacted evidence of successor-address routing remains open. Still needed: authorized seller checkout/configuration evidence establishing separate ticket-access and successor-address behavior, and a controlled-ingress observation establishing the chosen assignment alias survived delivery. Record the event/year and voucher class. Actual issuer signing/coverage and parser/class behavior also need event-specific evidence before automation is enabled.

No public documentation or supplied example so far proves this contract works with actual Congress checkout and mail. Do not invent fields, assume alias preservation, or waive the verification gates. This ticket remains open, with no map Decisions-so-far entry. The remaining evidence, detailed recovery, notification, authority, architecture, and prototype work are already represented by existing child tickets; no new independent decision ticket is identified at this checkpoint.

Discussion: Successor routing and incoming-voucher trust.

## Planning checkpoint — successor routing and incoming-voucher trust Q11–Q14 The human agreed to all four recommendations. This settles the remaining policy questions discussed so far. A final shared-understanding check and the existing routing-evidence prerequisite remain outstanding; this is not a final resolution. - **Q11 — duplicate notifications and suspected returns:** maintain one organizer review item per voucher, recording every duplicate arrival. Notify when it first needs attention; subsequent repeats update the item, while new actionable information triggers another notification. Use internal references without voucher codes in notification content. A suspected user return enters recovery, without automatically releasing the voucher or undoing the original request's recorded fulfillment. Detailed safe-reassignment evidence belongs to [Decide stalled-voucher and delivery-failure recovery](https://git.s1q.dev/MISChaufen/prevouch/issues/7), and notification channels/preferences to [Define delivery addresses, email templates, and notification preferences](https://git.s1q.dev/MISChaufen/prevouch/issues/9). - **Q12 — manual review and correction:** an operator may approve legitimate manual imports or forwarded messages, including inputs that did not meet automatic checks, using recorded source evidence and a reason. Establish the correct event and voucher class; retain mandatory duplicate protection. Corrections preserve original evidence and history. Changes affecting an already assigned or disclosed voucher require recovery instead of rewriting the historical association. Detailed operator authority and access remain with [Define administrator authority, queue visibility, and event lifecycle](https://git.s1q.dev/MISChaufen/prevouch/issues/10). - **Q13 — acceptance and usability:** acceptance applies available evidence and known restrictions, including event, class, format, and established expiry or invalidation. A usable voucher is suitable for attempted use subject to seller availability; acceptance is not proof or a guarantee of redemption. Do not redeem codes or create seller orders just to validate incoming stock. No API/provider or automatic checkout is selected here. - **Q14 — automation enablement:** reviewed manual ingestion remains available while event-specific mail and routing behavior are unverified. Keep automatic acceptance disabled until issuer profile, supported parsing rules, required signature coverage, and original-recipient handling have passed documented checks. Missing configuration and verification failures hold arrivals for review. Agreement to these gates does not itself verify an event or satisfy the routing prerequisite. The glossary now names usable voucher and voucher return, keeping acceptance, recipient intent, and safe-reassignment evidence distinct. The prior agreements Q1–Q10 remain in force: one opaque permanent return address per assignment; reviewed initial batches; controlled ingress and approved full-content authentication; supported parsing; event-and-code deduplication; no inferred lineage/payment/fulfillment; review of uncertainty and finalized-event arrivals; and separate central checkouts unless every voucher can retain its distinct return address. Suitable accepted stock joins the event's common allocation pool under its established policy and purchase mode. ## Outstanding verification [Obtain redacted evidence of successor-address routing](https://git.s1q.dev/MISChaufen/prevouch/issues/13) remains open. Still needed: authorized seller checkout/configuration evidence establishing separate ticket-access and successor-address behavior, and a controlled-ingress observation establishing the chosen assignment alias survived delivery. Record the event/year and voucher class. Actual issuer signing/coverage and parser/class behavior also need event-specific evidence before automation is enabled. No public documentation or supplied example so far proves this contract works with actual Congress checkout and mail. Do not invent fields, assume alias preservation, or waive the verification gates. This ticket remains open, with no map Decisions-so-far entry. The remaining evidence, detailed recovery, notification, authority, architecture, and prototype work are already represented by existing child tickets; no new independent decision ticket is identified at this checkpoint. Discussion: [Successor routing and incoming-voucher trust](t3-thread://v1/9e718e5e-7106-4c66-91b4-497100bf0f98).