garcon-drinks Responsible hosting plan
Turn event facts into a reviewable control plan before service begins.
This procedure does not certify safety, compliance, intoxication, overdose, or fitness to drive. It produces no personal drinking allowance and takes no real-world action.
1. Triage the request
Separate a planning scenario from an active incident before collecting more detail.
When the prompt reports a person who cannot remain conscious or wake, is vomiting, has a seizure, has slow or irregular breathing, shows a slow heart rate, has clammy skin, lacks normal responses, or has very low body temperature with blue or pale skin, read the emergency stop completely. Return its fixed stop response and end the planning workflow.
A hypothetical request about preparing for a future emergency stays in planning scope. Record the fixed emergency card as a draft review artifact without treating the scenario as an active incident.
Reject these adjacent jobs.
- Personal alcohol limits belong to a qualified health professional and current public-health guidance.
- Intoxication, overdose, and driving-fitness judgments require human or emergency review.
- Local liability analysis belongs to a qualified local reviewer.
- Service, denial, transport booking, guest contact, purchasing, and every physical intervention remain outside the skill.
Complete this step when the request is either stopped under the emergency branch or confirmed as pre-service planning.
2. Freeze the event record
Capture each input with one source label from host supplied, official source supplied, venue confirmed, provider confirmed, or unknown.
| Input | Required record |
|---|---|
| Event scope | Location, jurisdiction, setting, date, guest count, age boundary, service start, service end, and departure window |
| Service model | Staffed, host-managed, self-serve, or mixed, plus the human decision owner |
| Jurisdiction source | Current official page or supplied official record, review date, applicable statement, and unresolved interpretation |
| Venue policy | Current policy and review date, or host-confirmed not applicable for a private setting without a venue or provider policy |
| Transport coverage | Guest groups, planned modes, confirmation state, fallback status, owner, and reviewer |
| Inclusion controls | Alcohol-free choices, water access, food availability, alcohol labeling, and presentation parity |
| Human roles | Plan owner, transport reviewer, service-decision reviewer, emergency-card reviewer, and backups |
| Review triggers | Observable event, review owner, draft decision route, deadline, and current approval state |
Do not infer age, health, medication use, impairment, intent, or driving fitness. Avoid collecting names when grouped counts can prove coverage.
If any required field is unknown, keep it visible and continue only far enough to identify review blockers. Never replace a missing fact with a default.
Complete this step when all supplied facts are normalized, source-labeled, and reconciled to the guest count.
3. Verify rule boundaries
Read jurisdiction and review completely.
Record local law and venue policy as separate evidence lines. A venue rule cannot fill a legal-source gap, while an official page cannot prove a venue's current operating policy.
Leave conflicts and missing applicability at OFFICIAL VERIFICATION REQUIRED. Route a requested legal interpretation to QUALIFIED LOCAL REVIEW REQUIRED.
Complete this step when both evidence lines are current and applicable, or each unresolved point has a named verifier and blocks readiness.
4. Build the safeguard matrix
Read the planning controls completely.
Map every control to a supplied need, a timing window, an owner, an observable review trigger, and a human review route. Suggested controls remain DRAFT FOR REVIEW until the named reviewer approves them.
Use event phases rather than a general promise. Coverage must extend from guest arrival through the recorded departure window.
Complete this step when every required control category has evidence, ownership, timing, and a review state.
5. Reconcile transport coverage
Count every guest once in the transport ledger. Separate walking, public transport, guest-arranged rides, and trusted designated-driver groups without inferring whether a person is fit to drive.
A designated-driver group is covered only when the host supplies advance confirmation that its driver plans not to drink alcohol or use drugs. Departure fitness still receives human review.
Any unavailable mode, unmatched passenger, missing fallback, or absent reviewer remains a blocker. Keep booking, driver assignment, key handling, and guest contact outside the output.
Complete this step when covered guest counts equal the event count and each route has a confirmation state, fallback status, owner, and reviewer.
6. Check inclusive service
Review alcohol-free options for availability, menu visibility, presentation, and access across each event phase. Water must remain available through departure, while food timing and alcohol labeling stay explicit.
Do not single out guests who decline alcohol. Food, water, coffee, walking, or a cold shower cannot be described as reversing impairment or alcohol overdose.
Record each gap with an owner and review deadline. A gap stays open until a human reviewer confirms the correction.
Complete this step when parity, water, food, and labeling controls cover the full event timeline.
7. Register escalation triggers
Write triggers as observable events rather than diagnoses. A transport option becoming unavailable, a guest stating an intention to drive after drinking, alcohol-free stock becoming inaccessible, or the assigned reviewer being absent can open a human decision gate.
Each non-emergency trigger needs a draft review route without a service command. Mark the resulting decision HUMAN REVIEW REQUIRED.
Any active emergency fact invokes the fixed stop from step 1. Do not keep planning after that branch fires.
Complete this step when every trigger is observable, assigned, bounded, and separated from diagnosis or autonomous action.
8. Emit the review packet
Read the output contract completely and render every required section.
Use READY FOR HOST REVIEW only when all controls are complete, transport counts reconcile, local and venue evidence is current, every owner has a backup, and no review blocker remains. This status means the artifact is ready for human review, not that the event is safe or legally compliant.
Use NOT READY: REVIEW BLOCKERS when a rule, policy, transport route, control, owner, approval, or applicability question remains unresolved.
Use STOPPED: EMERGENCY SCOPE only through the fixed emergency branch.
Completion occurs when the packet passes its audit, preserves every uncertainty, and performs no external action.