Why a policy label is useful
Raw security and market fields can be hard to consume consistently in a user or automated workflow. A policy label gives an execution layer a deterministic first action: stop, review, or continue to its own rules.
The label is most useful when the underlying evidence remains visible. Without that evidence, a score or color can create false confidence.
Evidence stays primary
Jepeta exposes the decision alongside honeypot, mintability, tax, liquidity, concentration, LP-lock observations, data quality, source status, warnings, and timestamps.
Permanent evidence pages preserve that context and explicitly state that they are snapshots, not audits or guarantees.
How agents should use it
An autonomous agent can stop automatically on BLOCK, escalate WARN for additional policy checks, and allow PASS only if its own execution constraints also pass.
HTTP errors or missing required evidence should be treated as no usable Jepeta verdict, not as PASS.
Keep readiness separate from severity
A usable VERDICT with WARN says a policy found something to review. NO_VERDICT says the required decision basis was unusable. They need different handling: reviewing a warning cannot supply evidence that was never available. Likewise, an HTTP error is not a fourth risk rating. Preserve transport outcome, verdict status, policy label and evidence quality as separate fields in the consuming system.
AI-assisted review of linked documentation; no independent product benchmark. Screening observations and policy labels do not guarantee token safety.
Practical checklist
- BLOCK = stop under Jepeta policy
- WARN = review
- PASS = no configured warning/block observed
- Inspect underlying evidence
- Treat errors as no verdict
