What does a risk_level of unknown mean in VetAgent?

A critical check - liquidity or sellability - could not be completed. It is not a low-risk result and must never be used to justify a trade.

Should an AI agent retry an unknown answer?

Only when next_action is retry, which is exactly when an upstream of ours failed - unknown_kind infrastructure or mixed - and only once, after retry_after_seconds. A coverage unknown will not change on retry: abstain. A mixed unknown is that failure beside something else missing, and the rest of the answer was worked out without what the outage hid, so the retry can change any of it, in either direction.

Where does VetAgent say why an answer is unknown?

evidence.data_gaps lists each missing check with its reason. Every reason begins with one of three phrases: 'upstream request failed' (ours and temporary - retry once), 'our coverage gap' (ours not the token's - no retry you would make closes it, and the detail names an expiry when there is one) or 'about the token' (what came back does not contain it - do not retry).

What `unknown` means, and what your agent should do with it

unknown means a check the verdict depends on could not be completed. It is not a low-risk result, and an agent must never trade on it. It is also not an error: it is the product refusing to guess.

Why a risk check says "I don't know"

Two checks are critical: whether the token has a market you can exit into (liquidity), and whether it can be sold (sellability). If either could not be read, the answer is unknown — never low or medium, however clean the rest looks. A safety check that answers optimistically when it is broken is worse than no check.

Retry or abstain: read `unknown_kind`

`unknown_kind`	What happened	`next_action`
`infrastructure`	Our upstream data sources did not answer — usually rate limits. The token may be fine.	`retry`, once, after `retry_after_seconds`
`coverage`	The check could not be run for this token, and a retry will not change that. Either the token cannot be checked — no trading pair, no simulator record, a sell simulation that reverted, no pool priced in an asset whose value can be verified — or this tool does not cover the chain, which is our gap and says nothing about the token: no sell simulator covers Solana. The recommendation names which.	`abstain` — retrying will not change it
`mixed`	An upstream of ours failed, and something else is missing beside it: a chain we do not cover, or a fact about the token. The rest of the answer was worked out without what the outage hid — which chain the token is on, which pool to test — so the retry can change any of it, in either direction. The recommendation says which halves are in play.	`retry`, once, after `retry_after_seconds`

Retry at most once. An agent that retries every unknown until it gets an answer has turned "we could not check" into "we checked", which is exactly the mistake the verdict exists to prevent.

Reading the reason

evidence.data_gaps says which check was missing and why, in the upstreams' own terms:

"data_gaps": [
  {"dimension": "liquidity", "source": "dexscreener+geckoterminal",
   "reason": "upstream request failed (dexscreener 429, coingecko 400, geckoterminal 429)"},
  {"dimension": "sellability", "source": "rugcheck",
   "reason": "our coverage gap: the sell simulator does not cover solana"}
]

Every reason opens with one of exactly three phrases, and that phrase is the whole of what your agent needs to decide what to do next. The detail after it is for a human reading the log.

Reason begins with	Means	Worth retrying?
`upstream request failed`	Ours, and temporary: a source did not answer. The parentheses say what each one returned.	Yes, once
`our coverage gap`	Ours, not the token's, and it takes three shapes: we do not run this check here, or the one source that carries it has nothing for this mint, or what it sent is not yet usable. No sell simulator covers Solana, and honeypot.is covers only Ethereum, BSC and Base — on any other chain the sell test is a gap of ours and says nothing about the token. The detail after the prefix says which shape, and names an expiry when there is one.	No — not on any retry you would make
`about the token`	What came back does not contain it. A finding, or the absence of one.	No

Some details you will see after those prefixes:

Reason	Means
`about the token: the sell simulator has no record of this token`	The simulator has never seen it.
`about the token: simulation failed: …`	The simulator ran and the trade reverted, often on a router it cannot drive. Unverified, not dangerous.
`about the token: no pool's depth is priced in an asset we can verify`	Pools exist, but every one is priced in a token whose value no independent market sets — so the depth it claims cannot be checked.
`upstream request failed: no distinct-seller count`	The simulator calls it a honeypot while sells are completing, and the number of distinct sellers — which tells real exits from one wallet trading with itself — could not be read.

Before 2026-09-20 only the first two prefixes existed and everything else was bare, which meant "a fact about the token" was whatever was left over. A gap that forgot its prefix changed meaning silently: a transfer fee we could not read was published as an upstream outage, and a real outage on Solana was published as a permanent coverage gap telling callers not to retry. The third prefix exists so that no reason can mean something by default.

When the absence is the answer

On a chain we know we searched, no pair, drained pools, or pools with neither a stated depth nor observed sells can support the signal "Nothing about this token can be verified" when no simulator can trade the token and the gaps are about the token. That finding is high. Pools listed with sells in the last day, whose depth no source states, are not an absence. Such a token keeps its critical liquidity gap and comes back unknown unless a separate finding requires high. Buys alone do not count as sells. The rule never applies to our own outage.

How often

The benchmark's rate is on the method page. Production refuses more often than the benchmark, because the benchmark replays cached data and cannot see live rate limits; a daily reading of the live rate is in the scorecard.

What unknown means, and what your agent should do with it