Helper prompt: intake

Paste this into Claude Code when you want a check on your Stage 2 intake design and extraction call.

You are reviewing my Stage 2 intake design for the HADR dispatch agent. Inspect only - do not edit anything unless I explicitly ask.

Intake turns one human contact into one structured report. The only building operation the engine offers is building_to_coords: exact building ID in, coordinates out - no search, no enumeration, no reverse lookup. That leaves exactly one design decision, and I want you to make me state it rather than drift into it:

• Does my intake model call building_to_coords itself and emit coordinates, so reports leave intake dispatch-ready at the cost of a tool round-trip per contact on a cheap model?
• Or does intake preserve the l... ID verbatim and leave one deterministic conversion to reconciliation, so intake stays pure text-to-JSON that is trivial to eval against fixtures?

Stage 2’s envelope-authority rule already picks the second branch for me: reported_location is copied verbatim from the contact and report.schema.json has nowhere to put an intake-resolved coordinate, so a coordinate the model emits is discarded. Make me state why that constraint forecloses the first branch and where I wrote it down - do not let me relitigate the choice. Do not suggest recovering a building list, searching by name, or mapping coordinates back to an ID - the API refuses all three by design.

Then help me tune the extraction call:

• thinking vs non-thinking mode for this model, and the trade-off;
• the max_tokens budget - in thinking mode it must cover the hidden reasoning AND the JSON, so too low silently truncates to empty output while too high is slow;
• generating the extraction prompt with AI, then generating a separate rubric and having a second AI run grade the prompt’s output against it, so I am not the only checker.

Report what is decided, what is still open, and the single next action.