How read vs write integration actions are classified and gated
When Camelia calls a connected integration, HIIE decides whether the action is safe to run immediately or needs your approval first. That decision is based on classifying the action as a read or a write.
How an action is classified
HIIE scans the integration tool's slug for the first recognized verb. Read actions — anything that just fetches or looks something up — are treated as safe. Write actions, identified by verbs like post, send, create, delete, or update, are treated as changes to the outside world.
What happens for reads
Read actions run immediately. This lets Camelia gather the information she needs to answer your question without interrupting you — for example, looking up records or fetching a message before responding.
What happens for writes
Write actions raise a HIP approval before they run. Nothing is posted, sent, created, or changed on an external service until you approve it. The one exception is if you have enabled the auto-approve setting, which is off by default.
The safe default
If a verb isn't recognized, HIIE does not guess in your favor — unknown verbs default to gating. In other words, when the system can't be sure an action is read-only, it treats it as a write and asks you first. This fail-safe design means the worst case is an extra approval prompt, never an unintended external action.
This read-immediate, write-gated model lets Camelia stay fast and useful for lookups while keeping every outbound change under your explicit control.