Prompt-backed scenario · U2Updated
Event registration AI agent: a prompt-backed reference workflow
In brief
An event registration AI agent can accept a typed ticket tier, check capacity before confirmation, waitlist sold-out requests without overselling, track the registration lifecycle, and merge a repeated email into one registration. This page makes those prompt rules inspectable; it is not evidence of a generated artifact or live registration service.
Corpus U2 · contract map
Resolve ticket capacity before confirmation or badge action.
01 · Input
Typed request + state
- tier
- tier_capacity
- confirmed_count
- existing_registration
02 · Decide
Prompt-owned rules
- Constrain the ticket tier
- Check capacity before confirmation
- Track the full lifecycle
- Merge the same email
03 · Return
Inspectable contract
- registration_status
- tier
- capacity_action
- merged_registration_id
- badge_action
Corpus U2
The exact acceptance-corpus prompt
Corpus U2
Event Ticket Registration Agent
Running a conference and need to handle ticket registrations. People pick a tier (standard, vip, student) and we need to check if that tier's actually sold out before confirming, don't want to oversell. If it is sold out, put them on a waitlist for that tier instead of just rejecting them. Track status through the whole thing, pending payment, confirmed, waitlisted, cancelled, refunded. Also had an issue last year where someone registered twice with the same email and we sent two badges, so if that happens again just merge it into their existing registration.
This is a prompt-backed reference scenario, not a customer result, verified generated artifact, deployed service, or live endpoint. The source is the public generation acceptance corpus in issue #2567. At the 2026-08-08 checkpoint recorded there, the Medium scenarios had not been proven end to end.
Contract surface
Input and state fields
Registration request
The minimum identity and tier choices named in the prompt.
- Identity used for the same-email merge rule.
- tier
- Typed as standard, vip, or student.
Capacity and lifecycle state
State needed to confirm safely and keep one registration record.
- tier_capacity
- Capacity for the selected tier.
- confirmed_count
- Confirmed registrations already consuming capacity.
- existing_registration
- The record matched by the same email.
- status_history
- Lifecycle states and their timestamps.
Fields are shown because the rule depends on them. Names are a reviewable contract draft, not a claim about a generated schema.
Decision logic
Business decisions to approve
- 01
Constrain the ticket tier
The contract accepts only standard, vip, or student as the typed tier.
- 02
Check capacity before confirmation
A sold-out tier goes to the waitlist instead of confirming above capacity; the flow must never oversell.
- 03
Track the full lifecycle
The visible status model includes pending payment, confirmed, waitlisted, cancelled, and refunded.
- 04
Merge the same email
A second request with the same email must merge into the existing registration rather than issue a second badge.
Response shape
Reviewable output contract
registration_status- One of the five prompt-owned lifecycle states.
tier- The accepted standard, vip, or student tier.
capacity_action- confirm or waitlist after the non-oversell check.
merged_registration_id- Existing record when the same-email rule fires.
badge_action- Issue once or keep the existing badge after a merge.
An approved specification should expose these decisions as typed response fields or traceable side-effect records. Generation must not infer a missing rule after approval.
Behavior checks
Positive, negative, and boundary probes
- 01
One place remains in the selected tier
Confirm the request and consume the last place.
Positive case at the capacity edge.
- 02
The selected tier is sold out
Waitlist the request instead of rejecting or confirming it.
Negative capacity case proves the no-oversell rule.
- 03
A second request uses the same email
Merge into the existing registration and do not issue another badge.
Positive case for deduplication and badge safety.
- 04
A request uses a different email
Evaluate it as a separate registration.
Negative case prevents unrelated attendees from being merged.
Approval gate
Questions the prompt leaves open
The prompt does not define email normalization, so case, whitespace, and alias handling must be approved before the same-email merge is deterministic.
The allowed lifecycle transitions and refund side effects are not stated; the approved specification must expose them instead of inventing behavior during generation.
This is where a spec-first workflow earns trust: unresolved boundaries remain visible until a human approves them. Read the seven-step implementation guide or see how the same review boundary fits an agency handoff.
Continue reading
Related resources
Move between the agency workflow, implementation guide, proof, reference scenarios, and comparison.