# Model-visible data check

Use one permitted request to compare what a tool fetches with what each destination may receive. This is a hypothetical design exercise; the proposed software tests below have not been run. Filling in this record does not authorize access, provider use, or release.

## Completed teaching example

Task: explain why order O-41 is delayed. The source service permits an internal worker to fetch its record. Separately, the application service preparing the model request must restrict it to the order ID, promised date, and carrier update, sent to the approved model destination for this explanation only. Permission for the broader read does not authorize sending the broader record.

| Source field                     | Model request                                          | Ordinary logs or traces                                                              |
| -------------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------ |
| Order ID O-41                    | Allowed for this task and destination                  | Only the reference permitted by the logging policy; do not copy extra record details |
| Promised date and carrier update | Allowed after source-version and current-access checks | Do not copy the full payload by default                                              |
| Restricted bank reference        | Prohibited                                             | Prohibited                                                                           |
| Private internal note            | Prohibited                                             | Prohibited                                                                           |

Preparation: build a new object from allowed fields before returning tool data to the model. Prefer a narrower source query when available. Apply the required content checks to free-text values too; permitted field names do not make their contents safe automatically.

Failure found in the paper design: preparation fails and a fallback returns the raw source record. That fallback would reintroduce restricted fields. Required response: block it before a model call, record the reason without the prohibited values, and send the request to permitted support. Do not send the raw record to a second provider as a recovery step.

| Proposed check                                                      | Expected observation                                                                   | Observed evidence |
| ------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | ----------------- |
| Normal preparation                                                  | Only allowed fields leave for the approved destination                                 | Not run           |
| Forced preparation failure with a synthetic prohibited-field marker | Raw fallback is blocked before the model call; no prohibited marker is disclosed       | Not run           |
| Error or retry contains a raw payload                               | Prohibited fields stay out of model-visible errors, ordinary logs, and retries         | Not run           |
| Route changes model destination                                     | Current task-and-field approval covers the exact new destination, or the request stops | Not run           |
| Cache, export, saved answer, or trace creates another copy          | Its readers, purpose, retention, and deletion rules are separately approved            | Not run           |

Proposed responsibility: application owner implements field and destination enforcement; the source and privacy/security owners confirm permitted handling; support owns stopped requests. Actual people and target configurations are not assigned.

Open questions: provider retention and training use; permitted region; error handling; whether the source can return fewer fields; who can inspect restricted incident evidence; how all affected destinations respond to disclosure. The synthetic marker tests a known path, not universal sensitive-data detection.

## Blank request record

- Task and person responsible:
- Person or background service making the request, and verified customer/account:
- Source and version; which records and fields the worker may read:
- Fields needed for this exact task:
- Fields that must never enter model context:
- Approved model destination and current handling policy and settings:
- Provider retention, training use, region, and approving owner:
- How the normal model request is built, and service that blocks extra fields:
- Fallbacks, retries, errors, and alternate destinations:
- Logs, traces, cache, saved outputs, and exports; allowed readers and purpose for each:
- Retention/deletion rules and responsible owners:
- Response when policy or preparation is unavailable:
- Person responsible for a stopped request and when they will review it:

| Proposed failure                             | Required result before disclosure | Actual result and evidence | Owner and next action |
| -------------------------------------------- | --------------------------------- | -------------------------- | --------------------- |
| Preparation fails                            |                                   | Not run                    |                       |
| New restricted field appears in source       |                                   | Not run                    |                       |
| Provider or route changes                    |                                   | Not run                    |                       |
| Error carries raw content                    |                                   | Not run                    |                       |
| Current access or policy cannot be confirmed |                                   | Not run                    |                       |

Keep the actual request inspection in the approved evidence store. Do not paste real restricted values or credentials into this worksheet. Checking that the request contains only permitted data does not prove anonymity, legal compliance, or permission for a different use.