Accepted values
| Field | Accepted values | Default |
|---|---|---|
data_classification | synthetic, phi | Synthetic in demo/staging; PHI in live if omitted. A healthcare key always enforces PHI policy. |
use_case | administrative_support, document_summarization | administrative_support |
Synthetic means no real patient data
Use entirely fictional prompts in demo and staging. Synthetic requests are screened for a small set of obvious identifier patterns, including email addresses, SSN-like values, and labeled medical-record identifiers. Generated synthetic output is also checked.
Healthcare keys enforce healthcare policy
PHI requires live mode, an eligible key, current customer and provider agreements, approved route and region, verified retention, infrastructure/policy approvals, and permission to operate the managed customer gateway. If any check fails, dispatch is denied.
A healthcare key cannot be downgraded by sending "data_classification": "synthetic". A synthetic-only key cannot promote itself to PHI.
If synthetic output is withheld
Synthetic-mode identifier-pattern checks cover text, schema and tool input, tool arguments, and refusals. Streaming synthetic text uses a 512-character holdback to detect patterns split across chunks; short answers may arrive together. These checks are limited pattern checks, not a comprehensive PHI detector. Authorized PHI routes do not apply synthetic-mode pattern blocking.
Structured JSON and tool arguments are checked after completion. A streaming consumer may have received partial text before an output validation failure; wait for the terminal outcome before using it. A failed output validation with reliable usage is charged and marked output_invalid. Refusals are returned explicitly and remain billable.