Each headline number should answer one question: how many are confirmed, how capacity is counted, or how many confirmed people have recorded check-ins. Keep those denominators visible.
A fictional six-seat event
Original fictional data. Registration snapshot: October 13, 2026, 3:00 p.m., America/New_York. Capacity is six seats. The supplied rule says confirmed registrations consume capacity; there are no separate holds.
| Registration ID | Status at this snapshot | Counts against seats? |
|---|---|---|
| R01 | Confirmed | Yes |
| R02 | Confirmed | Yes |
| R03 | Confirmed | Yes |
| R04 | Confirmed | Yes |
| R05 | Waitlisted | No |
| R06 | Canceled | No |
There are six unique registration records: 4 confirmed + 1 waitlisted + 1 canceled = 6. Four consume seats under the stated rule, leaving 6 capacity − 4 confirmed = 2 seats. That does not automatically promote R05. An organizer must make and record the actual decision under the event's process.
If the real event has reserved holds or a different capacity rule, add those inputs before showing availability. Do not use this example's no-holds convention as a universal registration policy.
A separate event-day snapshot
Fictional event-day snapshot: October 16, 2026, 10:00 a.m., America/New_York. The example explicitly confirms that R01-R04 are still the confirmed set at this later snapshot.
| Confirmed ID | Check-in evidence by snapshot time |
|---|---|
| R01 | Recorded check-in |
| R02 | Recorded check-in |
| R03 | No check-in recorded |
| R04 | No check-in recorded |
The event log contains a repeated R01 check-in. Deduplicating by registration identity leaves two unique confirmed check-ins out of four confirmed registrations: 50%. The repeat is not a third attendee.
R03 and R04 have no check-in recorded by this time; that alone does not establish why or whether they will arrive later. R05 and R06 are outside the confirmed check-in denominator. Do not describe two of six capacity as the same attendance measure, or label 50% as an event-success result.
Let each total reveal its own records
The registration view should show the October 13 statuses, capacity rule and seat calculation. The event-day view should show the October 16 confirmed set, deduplicated evidence and check-in time. Switching views must update the heading and record dates as well as the totals.
Keep the repeated R01 event available as a flagged source entry so an organizer can inspect why it was excluded. Do not silently erase evidence from the log. If the confirmed set changed between snapshots, use the actual dated set for the attendance denominator rather than copying an older count.
The next action is specific: reconcile duplicate check-in events and confirm any requested waitlist change in the authorized registration system. An HTML review filter can display the corresponding IDs; it is not a real check-in or registration control.
Copy a reconciliation-focused dashboard brief
Create one complete, self-contained US-English HTML companion for “Six seats · event reconciliation”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for Registration snapshot; Event-day snapshot; All; Confirmed; Exceptions; Show supplied check-in log. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Prepare an event dashboard review in US English.
Registration snapshot date/time/time zone: [enter]
Unique registration IDs and exclusive statuses: [paste sanitized records]
Capacity, holds and seat-counting rule: [paste]
Event-day snapshot and confirmed set at that time: [paste separately]
Check-in event log with registration IDs: [paste]
Organizer's status-change process: [enter]
Reconcile status counts to unique records. Compute remaining seats only from
the supplied capacity/hold rule. Do not auto-promote a waitlist. Deduplicate
check-ins by registration identity while flagging repeats for review. Show
checked-in confirmed IDs over the confirmed population at the same snapshot. Keep dates/denominators visible and no-record distinct from inferred absence. Do not invent registrations, arrivals, cancellations, revenue, or success metrics.
Return snapshots, totals, exception records and organizer questions. If
requested, offer HTML read-only review views/filters linked to source IDs. View changes update dates and totals together. No registration/check-in writes,
reminders, live sync, payments, or saved personnel-data claims.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# Event Dashboard Template: Separate Registration, Seats, and Check-In Evidence
Six registration records do not mean six confirmed seats, and a repeated check-in does not mean another attendee arrived. Give the event dashboard unique registration IDs, exclusive statuses, and a separate dated check-in snapshot before calculating its totals.
Each headline number should answer one question: how many are confirmed, how capacity is counted, or how many confirmed people have recorded check-ins. Keep those denominators visible.
## A fictional six-seat event
**Original fictional data. Registration snapshot: October 13, 2026, 3:00 p.m., America/New_York.** Capacity is six seats. The supplied rule says confirmed registrations consume capacity; there are no separate holds.
| Registration ID | Status at this snapshot | Counts against seats? |
| --- | --- | --- |
| R01 | Confirmed | Yes |
| R02 | Confirmed | Yes |
| R03 | Confirmed | Yes |
| R04 | Confirmed | Yes |
| R05 | Waitlisted | No |
| R06 | Canceled | No |
There are six unique registration records: 4 confirmed + 1 waitlisted + 1 canceled = 6. Four consume seats under the stated rule, leaving **6 capacity − 4 confirmed = 2 seats**. That does not automatically promote R05. An organizer must make and record the actual decision under the event's process.
If the real event has reserved holds or a different capacity rule, add those inputs before showing availability. Do not use this example's no-holds convention as a universal registration policy.
## A separate event-day snapshot
**Fictional event-day snapshot: October 16, 2026, 10:00 a.m., America/New_York.** The example explicitly confirms that R01-R04 are still the confirmed set at this later snapshot.
| Confirmed ID | Check-in evidence by snapshot time |
| --- | --- |
| R01 | Recorded check-in |
| R02 | Recorded check-in |
| R03 | No check-in recorded |
| R04 | No check-in recorded |
The event log contains a repeated R01 check-in. Deduplicating by registration identity leaves **two unique confirmed check-ins out of four confirmed registrations: 50%**. The repeat is not a third attendee.
R03 and R04 have no check-in recorded by this time; that alone does not establish why or whether they will arrive later. R05 and R06 are outside the confirmed check-in denominator. Do not describe two of six capacity as the same attendance measure, or label 50% as an event-success result.
## Let each total reveal its own records
The registration view should show the October 13 statuses, capacity rule and seat calculation. The event-day view should show the October 16 confirmed set, deduplicated evidence and check-in time. Switching views must update the heading and record dates as well as the totals.
Keep the repeated R01 event available as a flagged source entry so an organizer can inspect why it was excluded. Do not silently erase evidence from the log. If the confirmed set changed between snapshots, use the actual dated set for the attendance denominator rather than copying an older count.
The next action is specific: reconcile duplicate check-in events and confirm any requested waitlist change in the authorized registration system. An HTML review filter can display the corresponding IDs; it is not a real check-in or registration control.
## Copy a reconciliation-focused dashboard brief
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Read each count with the organizer by naming its source IDs and date. Record actual status changes and attendance corrections in the maintained event system, then refresh the dated review from those records.