Skip to main content
When something can’t be done, Nexalytica tries to tell you plainly what happened and what to do next. This chapter is a reference for every error you might run into, organised by where it shows up. For each one you’ll find what you see, what it means, and what to do — plus the exact code, so you can quote it to support if you ever need to. Errors appear in four places:
  • Under a chat reply — when an AI agent can’t finish, its answer is replaced by a short message and a small grey code badge in the form NX:<number> · <category> (for example, NX:201 · AI Provider). The number is a permanent reference; the category tells you which system was involved.
  • As a toast (pop-up) — quick actions like sharing, uploading, or changing a plan show a brief message at the corner of the screen if they’re blocked or fail.
  • As a banner — organisation-wide states (trial ending, payment overdue, read-only) show a coloured strip across the top of the app.
  • As a dialog — a few states open a full pop-up you must read, such as “Credits Exhausted” or a suspended-organisation screen.
Behind the scenes every error carries a short machine code (like policy_denied or insufficient_credits) and a human message. You never need the machine code, but it’s included below so a support request can be precise. Raw technical detail (such as a provider’s internal message) is deliberately never shown to you — it stays in the server logs for administrators.

​
AI chat & agent failures — the NX codes

When an agent run fails, the reply carries an NX code. There are three families: 1xx = the agent itself, 2xx = the external AI provider, 9xx = the platform. This is the complete list.
NX:201 is the only failure that automatically notifies your organisation’s admins by in-app alert and email, throttled to one notice per organisation per hour so they aren’t flooded. NX:101 also gets special handling: before failing, the agent makes one final attempt to write up whatever it has, so you often get a partial answer instead of a hard error.

​
”Blocked by policy” — the Data Control Plane

If your organisation’s admins have armed a governance policy, an action that breaks it is stopped with a “Blocked by policy” toast (or, mid-chat, a note on the reply). The action simply doesn’t happen, the attempt is recorded for admins, and admins are notified. The machine code is always policy_denied. There are 25 possible policies, grouped by what they protect. Live-blocking policies (marked ●) stop the action in the moment; the others watch in the background and raise a flag or alert instead of blocking you.

​
Privacy

​
Security

​
Governance

​
Quality

If you hit one of these, the fix is usually to adjust your request (smaller query, allowed tool/model, non-external share) or to ask an admin, who can see and tune the policy in Settings → Control Plane → Policy Engine.

​
Account & billing states

These affect the whole organisation and are managed by billing admins. Most show as a banner across the top of the app; a couple open a dialog.

​
Common action errors

Everyday actions can fail for ordinary reasons. These show as a toast with a short message; the machine code is in brackets. Every one of these follows the same shape internally — a code, a plain message, and optional details — so the wording you see is always the specific, human explanation, never a raw technical dump.