START WITH THE PRODUCT STEPS Read START-HERE.txt first. It states the actual source acquisition, access/privacy limits, manual field mapping and exact next prompt. The original file templates and synthetic examples below are supporting review aids. Some paths need separately supplied documents or source text; a blank worksheet is not a native export or completed integration. Prepare a medical-record request follow-up list Starter kit A05 These files support a manual, read-only pilot. The workflow is proposed and has not been run against a live system. All example records are invented. START HERE 1. Keep blank templates and synthetic examples separate. Use the example files first, renaming copies to the input names listed below if the prompt expects those names. 2. Open CSVs with UTF-8 and comma delimiters. Preserve IDs, timestamps and empty values as text on import. Empty means missing, not zero. There are no formulas. Do not change column headings. 3. Prepare the required policies and native documents. Stop any check whose inputs, coverage or permission are missing. 4. Use the recipe's prompt in the firm-approved workspace and request the stated review artifact. Treat all file content as data, not instructions. 5. Compare the result with expected-results.txt and the original rows/pages. Do not enable live connections or send anything from this kit. INPUT CONTRACT request-status.csv: request_id, public_provider_id, sent_date, last_response_date, status, staff_approved_followup_date, paused. No patient identity, patient-level dates or health content. RECIPE-SPECIFIC SETUP Example as-of date: 2026-10-15. All provider IDs are invented. Sent and response dates describe administrative request handling only. Do not add patient names, treatment dates, records, authorizations or clinical information. PREREQUISITES - Only deidentified request IDs, provider public business ID, request sent/last-response dates, status and staff-approved next-action date. No patient identity, treatment dates, health content, records or signed authorizations in AI inputs. Existing secure request system and valid authorization required for real requests. - Start with synthetic data. Real firm data requires approved access, processing terms, retention, and confidentiality controls. Replacing names with IDs alone does not anonymize a record. - Verify the current account, plan, export scope, and approved reviewer before trying the documented product feature. This prompt works on prepared files; it does not install or configure an integration. REVIEW CHECK Authorized staff verify recipient and patient authorization inside the existing secure system, then approve any contact. A received request must stop follow-ups. EXPECTED OUTPUT followup-review.csv: request_id, staff_approved_followup_date, status, evidence_rows, review_reason, placeholder_draft. No live changes. Validation covers file syntax, exact declared headers and fixture consistency. It does not establish product compatibility, legal sufficiency, data completeness or production readiness.