ADR 032 Customer Reservation Contract Acceptance Evidence

Context

The legacy reservation payment screen renders the applicable document list, requires four separately checked consent items, and captures a signature image. Evidence: source-refs/sanmopia_web/application/views/service/reservation_payment.php:42-124.

Accepted ADR-031 currently authorizes a server-owned contract version and content digest but deliberately leaves contract wording, retention, and signature requirements open. The public creation command therefore cannot yet prove parity with the legacy acceptance step. A browser-only checkbox, an inline image, or a generic accepted=true flag would lose the exact documents, wording, actor, revision, and evidence lifecycle that were accepted.

Decision

The final-review projection would return a server-owned, revisioned ReservationContractAcceptanceBundle containing every required acceptance item, document version and content digest, display wording key, requirement status, signature policy, and retention-policy revision. The browser would render this bundle unchanged and express the authenticated mother’s choices only.

Confirmation would bind the exact review projection to the exact accepted item codes and, when the approved policy requires it, an opaque private ReservationSignatureEvidence reference. Signature bytes would never appear in the creation command, logs, public evidence, or a public bucket. A bounded authenticated upload capability would create the evidence reference and digest; the backend would revalidate ownership, expiry, content type, digest, and policy revision before acceptance.

The same primary-data transaction as reservation confirmation would persist the immutable principal, accepted document versions and digests, item decisions, signature evidence reference and digest, review revision, timestamp, and contract-acceptance identifier. Exact replay would return the original acceptance; changed wording, document digest, signature policy, principal, or review revision would fail closed.

This decision does not select the legal wording, the four target item codes, whether a drawn signature remains required, the permitted signature mechanism, or the retention period. Product and legal policy evidence must name those facts before its contract shape can be implemented.

Layer-first Placement

The acceptance policy belongs to domain/document_reporting/features/reservation_contract_acceptance/ and is consumed by application/reservation_operations/features/customer_reservation_creation/ through a public contract or consumer-owned port. Private signature storage is an adapter behind that port. Frontend code owns only disclosure and intent; orchestration may coordinate upload completion with confirmation but cannot rewrite legal facts.

Dependency direction remains domain <- application <- adapters/interfaces <- orchestration. No new global command/query directory is introduced.

Evidence Required Before Implementation

1. Product and legal owners identify every required acceptance item, wording source, document version, signature rule, and retention policy.
2. Contract examples prove that changed document or policy revisions invalidate an older acceptance attempt.
3. Backend tests prove principal binding, private evidence ownership, digest verification, atomic acceptance, exact replay, conflict, and expiry behavior.
4. Authenticated desktop and mobile scenarios prove individual consent, validation, signature-policy variants, retry, cleanup, redaction, and private artifact non-disclosure.

Consequences

The reservation workflow can gain auditable legal evidence without storing raw signature data in commands or trusting local UI state. It also adds a private artifact lifecycle and explicit policy ownership. Until the named policy gaps are resolved and implementation evidence passes, ADR-031 remains partial and no reservation-to-payment flow may claim full legal acceptance parity.

Revision History

• 2026-07-21: the workspace owner reaffirmed blanket approval of every current ADR. The decision remains accepted. Implementation and the named legal-policy gaps remain independently gated.
• 2026-07-17: accepted by the workspace owner through explicit blanket ADR approval. Implementation remains not-started; approval does not invent the unresolved legal wording, item codes, signature rule, or retention policy.
• 2026-07-13: proposed after the ADR-031 contract-to-legacy audit found that contract version and digest alone do not preserve the legacy four-item consent and signature step. No implementation authority granted.