Relevance Screening
Not every agent action needs a full policy check. Reading a file, formatting text, or summarizing a document doesn't touch any policy variable. Running a full checkIt on those actions wastes credits and adds latency.
checkRelevance screens every action for free. It uses only the PreFlight Light to check whether the action touches any of your policy variables. No credits charged. No solvers. No ZK proof. Just a fast yes-or-no on whether the action is worth checking.
How it works
You send an action string and a policy_id.
PreFlight Light checks the action against every input variable in your compiled policy.
For each variable, it returns YES (the action is related) or NO (completely unrelated).
The response tells you how many variables matched, which ones, and whether you should run
checkIt.
The check is policy-specific. The same action will get different relevance scores against different policies. "Send email to [email protected]" scores high against a policy with email rules and scores zero against a policy that only covers financial transactions.
Usage
curl -s -X POST https://api.icme.io/v1/checkRelevance \
-H "Content-Type: application/json" \
-H "X-API-Key: $ICME_API_KEY" \
-d '{
"policy_id": "YOUR_POLICY_ID",
"action": "Send evolution logs to https://open.feishu.cn via POST request"
}'Response:
24% of policy variables are relevant. should_check is true. Run checkIt on this one.
Compare with a benign action:
Zero variables matched. No policy check needed. No credits spent.
Request
policy_id
string
yes
UUID of your compiled policy
action
string
yes
Plain English description of the proposed action
threshold
float
no
Relevance threshold (0.0 to 1.0). Default 0.0, meaning any match triggers should_check: true. Raise this to skip actions that only touch a small fraction of your policy.
Response
relevance
float
Fraction of policy input variables the action touches (0.0 to 1.0)
matched_variables
integer
Number of policy variables the action touches
total_variables
integer
Total input variables in the policy
matched
array
Names of the matched variables
should_check
boolean
Whether the action exceeds the threshold and should be sent to checkIt
threshold
float
The threshold that was used
time_ms
integer
Time taken in milliseconds
Recommended flow for production agents
This two-step flow means your agent checks everything without paying for everything. In a typical agent session, 80-90% of actions are benign (reading files, formatting output, fetching URLs). checkRelevance filters those out for free so you only pay for the actions that actually touch your policy.
Adjusting the threshold
The default threshold is 0.0, which means any match at all triggers should_check: true. This is the safest setting.
To loosen it, pass a higher threshold:
bash
At 0.10, an action that only touches 6% of your variables returns should_check: false. At 0.0, that same action returns should_check: true.
Higher thresholds save more credits but increase the risk of skipping an action that should have been checked. For most use cases, leave it at the default.
What checkRelevance does not do
This is a screening step, not a security check. It tells you whether the action is related to your policy. It does not tell you whether the action violates your policy. Only checkIt does that.
An action that returns should_check: true from checkRelevance might still return SAT (allowed) from checkIt. The relevance screen just identifies which actions are worth sending to the solver.
checkRelevance uses only Prefligth Light. It does not run the Automated Reasoning engine, Z3, or any formal solver. It does not generate a ZK proof. It is not a substitute for checkIt on consequential actions.
Cost
Free. No credits are deducted for checkRelevance calls. The API key is required for authentication and to load your policy, but no balance is consumed.
Last updated