prism-shadow Cedar Ridge Intake Coordination Portal — Intake Reconciliation
What these tasks are
Every task in this group is the same shape: you are handed a read-only
"Cedar Ridge Intake Coordination Portal" and asked to reconcile a named work
unit (a roster, a referral batch, a transfer batch, or a program candidate
list) against clinical/administrative data, then return one JSON object that
exactly follows the task's input/payloads/answer_template.json. The portal data
and the target vary per task; the method does not.
There are five recognizable task families. Identify which one you have from the
prompt and from the template's top-level keys, then follow that family's
playbook in references/task_families.md.
| # | Family | Prompt/target cue | Template top-level keys (distinctive) |
|---|---|---|---|
| A | New-patient access verification | "roster", roster_id, access/insurance verification |
roster_id, requested_service_date, service_line, patient_results, cohort_summary |
| B | Referral readiness audit | "referral batch", audit before scheduling | referral_reviews, icd_discrepancies, duplicate_groups, shared_insurance_anomalies, blocker_sets, ready_to_schedule, action_plan, summary |
| C | Dialysis transfer review | "transfer batch", packet/chair capacity | patients (keyed by transfer_id), packet completeness, requested_start, cohort_summary |
| D | Chronic-care enrollment panel | "program CODE", candidates/eligibility |
program_code, as_of_date, patients, summary |
| E | Referral-to-chart activation | "activation", which referrals move forward | readiness_by_referral, clinical_code_discrepancy_referrals, blocker_sets, duplicate_handling, ready_referral_chart_needs, correspondence_queue, priority_order |
Operating procedure (every task)
- Read the prompt and the template first. The template
(
input/payloads/answer_template.json) is the authoritative output contract: required keys, enumallowed_values, ordering rules, and constant/required values (e.g.task_id,batch_id,roster_id,program_code). Read any other payloads too (e.g. atarget_roster.jsonlisting patient ids). - Resolve the base URL. The prompt uses the placeholder
<TASK_ENV_BASE_URL>. The real base URL is inenvironment_access.md(GDPEVO_ENV_BASE_URL, e.g.http://task-env:9013/). Use only the endpoints listed there. No credentials are needed. - Identify the family (table above) and open its playbook.
- Pull the work unit's data. Prefer the read-only SQL endpoint
(
POST /query) to fetch all rows for the target in one shot — REST list endpoints paginate (defaultlimit~10) and can hide rows. Use the REST aggregators (/patients/{id},/chart/{id},/transfers/{id}) when you want everything about one entity at once. Seereferences/portal.mdfor the schema and the field→source map. - Apply the family decision rules to each row, drawing every value from portal data. Map only to the template's controlled vocabulary.
- Assemble the JSON in the exact shape, ordering, and key set the template specifies. Compute the summary/cohort counts from your own rows.
- Validate before returning against the checklist below.
- Return JSON only — no prose, no markdown fences, nothing outside the single JSON object (several prompts state this explicitly; treat it as universal).
Rules that hold across all families
- Constants come from the template, verified against the prompt. Fields with
a
required_value/constant/expected_value(e.g.task_id: "train_00X",batch_id,roster_id,program_code) must be emitted verbatim. The task id matches the task folder name; the batch/roster/program id matches the prompt's named target. - Controlled vocabulary only. Every enum/status/reason/code value must be one
of the template's
allowed_valuesfor that field. Never invent codes, never emit free text where an enum is required, never carry a raw DB value through unmapped (e.g. map coveragestatus/auth_statusto the template's enum). - Ordering is part of correctness. Honor each list's stated ordering:
ascending by <id>,alphabetical by code,highest priority first, or "treat as unordered set." For unordered-set fields, still emit each code at most once (deduplicate). Use the portal's IDs verbatim, preserving their exact uppercase form as returned. - Emit every required key, including zero counts. Count objects must contain
all enum keys the template lists, with integer
0where nothing matched. - Counts must reconcile. Totals equal the number of rows; per-category counts sum to the total; a referral/patient is counted once per breakdown. Derive counts from the rows you actually emit, not from a separate pass.
- Dates are
YYYY-MM-DD. Take service/requested dates from the record the prompt points to (e.g. the roster row), not from the prompt text. - Read-only. Only GET the allowed endpoints and POST read-only
SELECTstatements to/query. Do not attempt writes. - Distractors exist by design. Extra batches/rosters/programs, unrelated
"distractor" referrals, and misleading free-text
notes(e.g."possible duplicate") are planted. Filter strictly to the named target and decide from structured fields, not fromnotes.
Pre-return validation checklist
- Output is a single JSON object; nothing printed outside it.
- All
required_*/ top-level keys present; constants match the template. - Every enum/code value ∈ the template's
allowed_values; sets deduplicated. - Every list obeys its ordering rule; IDs use the portal's exact case.
- One row per required entity (roster patient / batch referral / transfer / candidate); none missing, none duplicated, target filter applied.
- Summary/cohort objects include all enum keys (zeros included) and reconcile with the emitted rows.
- Dates are
YYYY-MM-DDand sourced from portal records.
Reference files
references/portal.md— endpoints, the read-only SQL interface, the full table schema, and the field→data-source map.references/task_families.md— the per-family playbooks: recognition, data to pull, decision rules for each output field, and the output contract.