Implementation Notes

Route receipts are built for incremental adoption. The first production-ready receipt records the requested alias, the exposed model identifier, the tool categories used, whether fallback happened, and which disclosure view produced the record.

Returning receipts in API responses

For APIs, return a receipt object beside the response payload and expose a receipt URL keyed by the response identifier. Generate the receipt at serving time from the request, not later from partial logs.

Exclude auditor-only fields from the response payload. A user-visible receipt can include redaction markers and an internal receipt identifier that support staff or auditors can use to retrieve a stronger view.

Receipt logs and dashboards

For logs, store the full internal receipt before redaction and use it to produce narrower views. The same internal receipt drives user views, developer dashboards, and audit exports.

Dashboards should show not_applicable, unknown, and redacted as distinct states. Those three states lead to different debugging decisions.

Optional receipt field compatibility

Providers can adopt the schema without exposing every optional field. A partial receipt is useful when it states what was not exposed. Missing data should be represented clearly, such as with an explicit empty or unknown state.