Implementation Notes

An implementation can start small. The first useful receipt usually records the requested alias and exposed model identifier, the tool categories used, whether fallback happened, and which view redacted the record.

Returning API responses

For APIs, either return a receipt object beside the response payload or expose a receipt URL keyed by the response identifier. The receipt should be generated at serving time, not reconstructed later from partial logs.

Keep auditor-only fields out of 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.

Logs and dashboards for receipts

For logs, store the full receipt before redaction and use it to produce the narrower views. That keeps user views, developer dashboards, and audit exports consistent.

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

Compatibility with optional receipt fields

Providers can adopt the schema without exposing every optional field. A partial receipt is still useful when it clearly says what was not exposed, and missing data should not be ambiguous.