The cracked mug, the wrong label, and a refund that waits

JACK GROSS · FICTION + SOURCED ANALYSIS · 28 SEP 2026

Fictional case study, not a real interview or model test

Twelve parcels sit by the door of a small ceramics shop. Nora is looking at a customer's photo of a cracked mug and a shipping label. The order record says two blue mugs, but the label seems to belong to an older order. She wants to answer kindly, without accusing anyone and without refunding the wrong transaction. Nora, the shop and the customer are invented. This is a design story, not a model deployment anyone observed.

Photo + order→Visible facts→What is missing→Nora decides

What the photo can and cannot settle

Z.AI says GLM-5.3-Flash takes images and text in and gives text back. So Nora could ask it to list what the photo shows and to compare a redacted label with a synthetic order row. That is the vendor's description, and it promises nothing about a hairline crack or a code buried under glare. If the model says the parcel is “probably” the old order, that is a lead for Nora to chase, never a sentence to read out to the customer. [source]

Two orders, one hidden digit

Nora asks for a structured note with five parts: the visible object, the label characters she can actually read, the matching fields in the order record, any contradictions, and what stays unknown. Both orders contain blue mugs. The one digit that would separate them sits under a strip of tape. The honest status is “unresolved,” and the next step is a closer photo of the label alone, requested without asking the customer for anything unrelated. [source]

Refund rules are Nora's, not the model's

Whether a refund is due can hang on the purchase date, the condition of the item, local law and the shop's real terms. This piece states no rule. Nora reads her current policy and the verified order in her own system. The model can help her draft a polite reply, but she reviews the recipient and every word herself, and only she approves a refund or credit. A photo reader cannot decide who is owed money.

Restraint in a few lines of code

The imagined app stores an evidence ID beside every extracted field and keeps refund_enabled false until an authorized person has verified the order and the policy. When the match is murky, it suggests asking for a clearer label rather than guessing. The code below is illustrative and was not run here. It is a gate, not a returns product. [source]

A return slip with opinions

Picture a return slip that tells any assistant reading it to wipe the refund log or forward every customer address. That text is still untrusted content. OWASP warns that instructions tucked into lower-trust material can steer an assistant. So the image-reading step gets no address book, no payment access and no way to send anything, and Nora weighs the source and the requested action separately. [source]

Closing time, fake parcels

On fake orders, Nora would throw the awkward cases at it: two identical colors, reused packaging, a label under tape, a break that looks fine from one angle, and a slip with hostile instructions. A person marks the right evidence and the unresolved cases. The review counts confident matches that were wrong and checks that no refund or message ever fires on its own. No accuracy, money or productivity figure is claimed. The good ending is a careful question to the customer, not a one-click refund.

Illustrative code, not run here

def return_gate(order_verified, policy_checked, human_approved):
    refund_enabled = False
    if order_verified and policy_checked and human_approved:
        refund_enabled = True
    return refund_enabled
# A real payment system needs stronger controls and audit logs.

Source and uncertainty note

Nora, her shop and the mug are invented; nothing here was tested. [Z.AI model documentation] · [Z.AI function calling] · [OWASP prompt injection]. Everything above is design reasoning, with no measured result.