When Trust6 blocks a send, it is not a malfunction: it is the fail-closed rule doing its job. When in doubt, the app refuses to send rather than risk a leak. Every block has a precise cause, a clear message and an audit trace.

Causes and fixes

The analysis is missing

You have not run the analysis yet, or you edited the text since. Fix: click Analyze (or Enter), review, then send. The app compares the analyzed text and the outgoing text down to the hash: a single changed letter requires a re-analysis.

The dictionary changed

Any change to the dictionary invalidates current analyses: the masking rules just changed, so the approved preview is no longer trustworthy. Fix: re-analyze, it takes a second.

An attachment is “Unusable”

A corrupted or unreadable file is attached to the conversation. While its red card is there, nothing leaves: content the app cannot read will never be sent as-is. Fix: remove the file card (or replace the file with a readable version), and sending works again. See Attaching files.

The analysis failed

The local engine could not finish. Fix: try again; if needed, restart the app (see Analysis is slow or seems stuck).

The level is “Highly confidential”

You declared the message at the last notch, and the model aimed at is not the local one. At that level the message does not leave your machine: it is the rule, not a warning. Fix: pick the local model, or lower the level if your file allows it. See The six confidentiality levels.

The provider’s commitments are not all verified

You declared the message “Very confidential” and the provider aimed at is one whose processing location, or the reach of its agreement, could not be confirmed. Fix: pick a direct provider, take the local model, or confirm the send knowing what you are doing. Your decision is recorded in the audit trail.

Account session required

Send features require a valid session, with a 7-day offline grace period. Fix: sign back in.

A block is never silent

Every blocked send is shown as such in the conversation and logged in the audit log with its reason. No network call happens: the block occurs before the network boundary, not after.

If a block seems unjustified and persists, write to us with the exact message shown.