Support: who to write to, what we promise, and what every refusal means

For the admin who owns the integration. The table in section 4 has a row for every refusal your SDK, your Executor, the decision API and the Policy Engine can give you: sdk.md section 5, the Executor's alerts, and the names the API and the engine answer with.

---

1. The two ways to reach us

Chat and email reach the same people. A refusal is not an incident. A refusal is the system working; section 4 says what each one means and who moves next.

To know the state of our deployment, write or use the chat: we answer in the times in section 2.

2. Severity, and what each one buys you

Severity is set by what you can no longer do, never by how the request was written. We will move a ticket's severity up or down and say why in the ticket.

Working hours are 09:00 to 18:00 Paris time (Europe/Paris), Monday to Friday, except French public holidays.

What "paged on our side" is not. The alert classes in section 4 are raised to the audience your own signed bundle names in its alert_targets.json, one entry per class, and a class naming nobody is refused when the bundle is loaded. That audience is yours. Our being paged is a separate arrangement over our own deployment, and it is not a substitute for yours: if your alert_targets.json names an address nobody reads, nobody reads it.

By class, on our side:

SIGNING_SUBSTRATE, BUNDLE_INVALID and ATTESTATION_QUEUE_DEPTH are three of the twelve classes your bundle must name an audience for. They are not in section 4's table because neither onboarding document publishes them as something you can be handed: they are raised inside our perimeter.

3. What to put in a report

Five things. With them a refusal is usually answered on the first reply; without them the first reply asks for them.

1. Your tenant. The label, exactly as it appears in your bundle's manifest.
2. The attestation id, if the action got as far as one.
3. The receipt, base64 or as bytes, or the proposal if no receipt came back.
4. The refusal name: the clause id or the alert class, spelled as section 4 spells it. This is the machine-readable half. The message beside it is for a human and is not part of the contract, so quote the id and not the sentence.
5. When, in UTC, and what you were doing.

Never send a private key, a seed, or an API key. Nothing we ask for needs one, and a report is not a channel we treat as secret.

4. Every refusal, what it means, and what to do now

How to read "who fixes it". It names who owns the fix once the cause is known, not who reports it. you means the change is in your configuration, your build or your data. us means the change is in ours. you and us means the first move is yours and the fix is likely ours, or the cause genuinely sits across the boundary.

How to read "refusal" and "Rule". A refusal your SDK's verify raises is listed by its name, the first word its error prints; its Rule is the rule of the specification it was refused under, linked to that rule's section, and the error prints it last, in brackets. Every other row is listed by the name or the rule it arrives with.

How to read "documented in". The first rows are refusals your own code raises: what your SDK's verify refuses on (sdk.md section 5) and what your Executor alerts about (the Executor's alerts). The rows below them are ours. the decision API is what a call to our API answers with, in the error member of a 4xx or 5xx body. the Policy Engine is the clause a rule refused under, and the clause an approval is refused under: the API does NOT serve it (the caller may be the AI agent being contained, and a clause served one decision at a time maps your rules), so you read it in the console and in your audit chain. the refusal category is what the API serves in its place, in a decision's refusal_category member: four names that say whether to try again and nothing about which rule.

Most of these must not be retried, and the ones that may are marked. A refusal is deterministic on the same input: asking again gets the same answer one round trip later. What is not a refusal in that sense says so in its own row — QueueFull, RateLimited and FeedbackRateLimited name the seconds to wait in a Retry-After header, and GatewayUnavailable, AdmissionUnavailable, FeedbackUnavailable and DP-37 are something on our side failing to answer rather than answering no. A dependency that could not answer on YOUR side is a different thing again, and is not in this table: there the Executor reaches no verdict, reports nothing, and the work stays queued for the next poll.

5. Two things that look like refusals and are not

A dependency that could not answer. If the audit service, the Context Store or the ledger cannot be reached, no verdict is reached, nothing is reported, and the work stays queued. The next poll asks again. That is not in the table above because there is no refusal name to act on. If it persists past a few minutes, it is a severity 2.

The same receipt arriving twice. Delivery is at-least-once and execution is not. A poll marks nothing, so work comes back until you complete it. Being handed the same receipt twice is normal. Executing it twice is what CL-2 and LEDGER_REPLAY exist to stop.

6. How we answer

• Ask us about the state of our deployment. Write to hello@ziffer.io or use the chat.
• The times in section 2 are commitments about answering, not about availability, and nothing here is a service credit.
• We answer in working hours, as section 2 defines them.
• One address, not a named individual. hello@ziffer.io reaches whoever is on the rota, so an answer never waits on one person being available.