Turn a person's own words into person-fact fields, for confirmation

This is an extractor, not a decision. Prose in, the structured facts /v1/eligibility/search accepts out, each with the exact words we read it from and a flag saying whether a human should confirm it. The response contains no status, no bucket, no credit union and no URL, and it cannot be made to contain one: there is no property in the response schema in which a verdict could be returned.

The intended flow is two calls. Send the person's sentence here; show them what we read; then send person_search_body - plus whatever they confirmed - to POST /v1/eligibility/search, where the deterministic eligibility graph decides, exactly as it does today.

How the model is contained. Its only output channel is a closed enum of field names generated from the search endpoint's own schema, a raw string this API coerces itself, and an evidence quote that must appear verbatim in your text. A quote we cannot find in your text means the fact is dropped. The worst case for hostile prose in text is therefore a WRONG FACT, flagged for confirmation - never an assertion about a credit union.

Privacy. text is never stored: not in usage logs, not in object storage, not in an error payload. Logs carry a truncated hash of it, its length, and the NAMES of the fields extracted - never values. Responses are Cache-Control: no-store.

Cost. Billed as 3 API units per call, because one model call is roughly three times the marginal cost of a deterministic lookup. This is an Enterprise Routes operation. It is separately capped at 20 calls per key per rolling hour to bound inference spend against a looping agent; that cap is independent of your plan quota and returns 429 with scope: "endpoint_burst".

Failure is always silent about eligibility. If extraction is unavailable you get 503 with facts: []. Ask the person for the fields directly; never read a failure as a negative answer.