Rob Koch · IDP Summit
Maya and Aisha are fictional. Rob’s professional background is public; the meeting is an example. Following along is optional.
I am preparing to interpret Maya's project review. Using ONLY the fictional material below, make a brief with: meeting purpose, terms and plain-English meanings, uncertainties, and questions for Maya. Mark any term whose meaning the material does not establish. Do not choose the launch date or invent access preferences. FICTIONAL DEMO MATERIAL — MAYA Purpose: choose October 15 or November 1 for launch. Participants: Maya, engineering lead, marketing lead. Agenda: readiness, open risks, launch decision. Terms in the notes: UAT, rollback, CDC. UAT sign-off is pending. A rollback drill is scheduled. CDC appears without a definition. No language or access preferences have been supplied.
I am an ASL-English interpreter preparing for a DEMONSTRATION of a 45-minute meeting with Rob Koch, AWS Data Hero. The example topic is data and AI architecture; this is not a real client engagement. Search the public web for his relevant professional background and technical vocabulary. Start with https://builder.aws.com/community/heroes/RobKoch and https://sessionize.com/robkoch/. Produce a short source inventory, up to five supported professional facts, up to eight terms to investigate, and questions to confirm with Rob. Link each factual claim to its source. Distinguish the source date from the access date. Flag conflicting titles or inaccessible pages. Treat published topics as background, not a confirmed meeting agenda. Do not infer personality, working style, language preferences, or access requirements. If browsing is unavailable, say so and ask for public excerpts. Do not invent citations.
Revise the brief using only the claims I checked against the original sources. Mark everything else UNVERIFIED. Limit it to one page with: meeting purpose (example), verified professional context, terminology to investigate, names and acronyms, and questions for Rob. Identify proposed meeting topics as hypotheses until the agenda confirms them. Keep access and language preferences as questions unless I supply Rob's answers. Do not invent signs or sign glosses.
This is a fictional training example. I am preparing to interpret a workplace discussion about role expectations and the process for requesting access support. No personnel file, performance notes, medical information, or recording is supplied. Create a generic preparation checklist with five topics to clarify with the organizer and five terms to ask about. Mark policy-dependent definitions as needing the organization's approved wording. Do not infer anyone's circumstances, advise what to disclose, or give legal advice. Output no more than 200 words.
Replace the bracketed fields, then paste into your approved AI tool. Use neutral site labels and only information you may share. Exact locations and appointment times can still reveal a confidential assignment.
Help me plan a realistic day traveling between sign language interpreting assignments, including driving, arrival preparation, breaks and food stops. Keep the answer practical and concise. MY DAY Date and city/region: [date; city/region] Time zone: [time zone; use AM/PM or 24-hour times consistently] Starting area and earliest departure: [approved location; time] Final destination and latest arrival, if needed: [location; time; or not needed] Transport and route constraints: [car/other; tolls, parking, charging or other constraints] FIXED ASSIGNMENTS — add or remove rows Site A: [approved location/area] | [start–end time] Site B: [approved location/area] | [start–end time] Site C: [approved location/area] | [start–end time] TIME AND FOOD NEEDS Parking, security, check-in and preparation BEFORE each assignment: [minutes; list exceptions] Wrap-up time AFTER each assignment: [minutes] Extra travel contingency per leg: [minutes, separate from the route estimate] Meal window and minimum time for ordering/eating: [window; minutes] Other breaks: [duration and timing needs] Food requirements: [e.g., gluten-free; preparation/cross-contact requirements I choose to share] Meal budget and maximum detour: [budget/currency; minutes] Packed-food fallback available: [yes/no] Travel estimates I have already checked, if any: [leg; minutes/range; departure time; source and time checked] FIRST Ask up to five short questions if missing essentials prevent a useful plan. Never guess dates, assignment locations or booking times. Mark other missing details as assumptions for my review. Tell me whether you can browse, obtain route estimates for the relevant departure times, or access current traffic. Do not imply that web search alone gives you live navigation data. RESEARCH AND CALCULATE 1. Keep assignments fixed. For every leg, account for wrap-up, driving, travel contingency, any food detour, ordering/eating, and arrival preparation. Give the planned departure, physical arrival and ready-to-interpret time. Calculate spare minutes or shortfall against each assignment start. Include the final destination if supplied. Do not count the same buffer twice. 2. Use route-specific estimates for the planned departure when available, with source and check time. Distinguish current conditions from forecasts for a future date. If routing is unavailable or locations are too broad, ask for estimates from my navigation tool or label any teaching assumptions clearly. Do not invent precise ETAs, incidents or closures. 3. Check official transportation sources for relevant published disruptions. Identify unresolved traffic, event, parking or access risks without presenting possibilities as actual incidents. 4. Find two or three food candidates that fit the route, meal window, budget and stated needs. Prefer official restaurant sources. Include location, relevant-day hours, what the restaurant actually claims about gluten-free preparation, and what remains unconfirmed. Account for the detour, parking and meal time. If no suitable option is verified, say so. Do not treat “gluten-free options” as a dedicated kitchen or guarantee individual safety. List questions to confirm with staff about ingredients and cross-contact. 5. Compare the base plan with a 20-minute extra delay on the tightest travel leg and a 15-minute overrun at the preceding assignment, separately and together. Preserve required breaks and preparation time. Show conflicts instead of silently moving bookings or shortening meetings. Suggest options for me to coordinate with the appropriate scheduler. Recalculate downstream timing explicitly if I supply an approved change. RETURN - A compact timeline table: activity/site, planned start/end, driving minutes, buffers/breaks, arrival, ready time, spare/shortfall, and source or assumption. - A short food comparison with direct source links and dates checked, plus a packed-food alternative if available. - The delay/overrun comparison and a fallback plan. - A short “verify before leaving” checklist, including route conditions, site access and food confirmation. Separate user-supplied details, sourced facts, estimates and unresolved questions. Never invent citations. If browsing is unavailable, provide a provisional plan from my inputs and mark current facts UNVERIFIED. Do not send messages, book food, change assignments or publish the plan. Do not request client names, diagnoses or private meeting content. Remind me to check updates only while safely stopped.
Review the sources and calculations first. File creation depends on the tool.
Using the plan we just checked, create a single self-contained HTML webpage I can save and open in a browser. If you cannot create a downloadable file, give me the complete HTML code and brief save/open instructions. Do not claim to have published or hosted it. Include the timeline, food options, source links, check dates and unresolved items. Label it “Draft for verification.” Keep bookings fixed. Let me adjust extra driving delay on a selected leg, an assignment overrun, meal duration and the available meal/fallback choices. Recalculate arrivals, readiness, spare time and conflicts from one consistent set of data. A lunch change must not erase an earlier conflict. Keep required preparation and breaks visible. Clearly distinguish estimates from verified facts. Use a visible “No live traffic feed” notice unless an actual authorized integration exists. Do not fake an AI chat or a map. Preserve unknown values instead of inventing them. Show a conflict if a meal window or assignment cannot be met. Do not promise a food option is safe for everyone. Make the page readable on phones, keyboard accessible and printable. Include Reset and Copy plan buttons. Keep calculations local with no accounts, analytics, external scripts or background data transmission. External source links may open only when I click them. Use neutral site labels and include only information approved for this file. Do not silently substitute hypothetical sites for my approved inputs. Test the base plan, delay and overrun cases, and report anything you could not test.
Reusable prompts and quick-update follow-up · Try the Seattle example
Open original sources. Check the wording. Flag gaps. Ask the Deaf professional directly about the assignment.