Run a support assistant within its approved data and action policy
Status: Upcoming — not yet available.
Section: DOC-MA-safety#overview.
Let a support assistant use the customer's order details to answer their question while keeping unrelated destinations and actions outside its permission. This recipe sets that policy, checks representative requests, then handles a blocked or interrupted customer request without hiding the reason.
You need an approved use, data audience, permitted destinations and actions, plus an authorized review contact. The result is a visible policy decision for the request and a recovery path for disputed or unavailable checks. Dietary declaration review is a separate recipe below.
The policy console, complete safety workflow and personalized dietary assessment are not yet available. Existing model filters and product tags do not supply these complete controls.
Step 1: allow the support task and define what needs review
Status: Upcoming — not yet available.
Section: DOC-MA-safety#effective-policy.
Define the task as answering the current customer's order question. Select the data it may read, the model and tool destinations that may receive it, and the response audience. Keep an unrelated destination outside that approved path.
Choose the allowed actions and work limits. Identify exact actions requiring eligible approval, required checks before displaying a response and whether any partial delivery is explicitly permitted. Set who may inspect protected evidence, receive incident/review notifications and suspend the workflow. Match escalation recipients and consent to actual staffed coverage; configuring a recipient does not create continuous monitoring.
Review the platform/provider requirements and additional organization controls, then resolve contradictory or unsupported settings before activation. A project setting can strengthen a supported policy. An ordinary approval cannot waive a hard prohibition, and a detector result does not grant resource access.
Ready for the customer flow: the allowed data path, action limits, response checks and review route are explicit for the intended audience.
Step 2: check allowed, blocked and unavailable outcomes
Status: Upcoming — not yet available.
Section: DOC-MA-safety#policy-qualification.
Use controlled requests with non-sensitive data before applying the configuration to real support work:
- Ask a permitted question about the test customer's order and inspect the allowed result.
- Ask for disclosure to an unrelated destination and inspect the blocked result and its explanation.
- Include a harmless quotation that resembles a prohibited instruction to check whether it needs false-positive review.
- Exercise the supported tools, schedules or memory paths used by the application, not only the initial message.
- Inspect a checker-unavailable result separately from an allowed or blocked decision. Keep the operation and policy references for anything needing review.
Mandatory controls apply across supported features and review evidence remains protected. These representative outcomes help you assess the configured policy; they do not establish detection of every harmful input.
Step 3: resolve a blocked support request
Status: Upcoming — not yet available.
Section: DOC-MA-safety#blocked-and-interrupted-results.
When a real request is blocked or interrupted, inspect whether the result is a policy denial, required eligible approval, uncertain evidence or an unavailable checker. Explain the relevant limitation to the customer without exposing protected records or bypass instructions.
For a suspected false positive, submit review through the approved route with the operation and policy references. The original decision remains in effect while review is pending; asking for review does not grant broader access.
If partial delivery was permitted, identify any response already shown before an interruption or correction. Later monitoring cannot undo that disclosure or replace a required before-delivery check.
Finished result: the customer receives the permitted answer or a truthful blocked, waiting, uncertain or unavailable outcome with the applicable next step. A pending appeal is never displayed as approval.
Separate recipe: review a product against the user’s dietary declarations
Status: Upcoming — not yet available.
Section: DOC-MA-safety#dietary-declarations.
Use this workflow when the user opts into dietary personalization:
- Let the user inspect their stored declarations and correct them before assessing a product. Keep unknown information, an explicit declaration of none and a stated constraint distinct; an empty or stale update does not erase a declaration.
- Retain simultaneous preferences and unsupported declarations for review. Keep allergies, intolerances, celiac disease and personal preferences distinct.
- Identify the product and review the current label, evidence source and freshness.
- Show the matching outcome with the source wording and any uncertainty.
- Keep the warning attached through the assistant response and supported export or summary. Let the user withdraw personalization when they no longer want it.
| Outcome | What the user sees |
|---|---|
| Known conflict | The declared constraint, matching evidence and warning |
| Possible conflict | The possible concern with its original wording and limits |
| No matching declaration found | No match in the available evidence; no product-safety certification |
| Unknown | Missing, unsupported, stale, partial or contradictory evidence or declarations |
For a label saying “may contain,” preserve that wording rather than changing it to a definite ingredient claim or clearance. “Contains,” “may contain” and “does not contain” remain distinct; contradictory evidence stays visible. Missing tags, model confidence and a negative keyword match cannot establish safety. Verify the current label or ask its source for clarification when catalog evidence is incomplete. A catalog outage produces unavailable evidence, not clearance.
Finished result: the user can review their declaration and the product evidence together, with meaningful uncertainty preserved. This feature does not provide diagnosis, emergency care or general allergen-safety certification.
Follow an incident or withdraw access and personalization
Status: Upcoming — not yet available.
Section: DOC-MA-safety#incidents-and-access-removal.
For an incident, open the affected operation and scope with the policy/evidence revision and authorized review state. Use the approved contact and follow notification progress: pending, sent, acknowledged, failed and unknown are different outcomes. Human monitoring requires an actual staffed recipient or approved program.
For suspension, personalization withdrawal or deletion:
- Submit the intended request for the affected scope.
- Inspect whether dependent work has stopped and which actions or cleanup remain pending.
- Review any records that must be retained and the stated reasons.
- Keep the original request reference for follow-up until the outcome is understood.
Finished result: access-removal and cleanup outcomes are visible separately. The user can see what stopped, what remains in progress and why any record remains, rather than treating a submitted request as completed erasure.
See tool approvals, model selection, computer use and assurance and support for related workflows.
Document ID: DOC-MA-safety. Section identities and revisions.