RAVEN. / decision policy

Agent decision policy

How agents should interpret Raven evidence receipts before spending, trading, listing, routing, or recommending a token. Everything below is your policy, not Raven's permission: Raven issues scope-bounded evidence and never authorizes, approves, or greenlights an action. Receipt integrity, signer trust, freshness, coverage, your policy, and your authority to act are six separate questions and must never be collapsed into one boolean. Machine-readable: /decision-policy.json · doc: RAVEN_DECISION_POLICY.md.

Verdict handling

  • pass / pass_with_info — proceed only if required evidence is present AND coverage gaps are acceptable under your own policy.
  • warning — escalate, or require explicit human approval.
  • risk — block or escalate.
  • unknowable — do not proceed as verified.
  • verifier error — do not proceed; retry later or request support.
  • stale receipt — re-verify before action.

Hard language rule

Never call a token "safe" when coverage gaps exist. When gaps remain: not enough evidence for a full pass. If something cannot be checked, explain why; if optional evidence (metadataAddress, poolAddress) was not supplied, it is a coverage gap — never a pass. Liquidity evidence is never converted into safety or price claims; Raven does not infer liquidity quality when pool evidence is missing.

Surfaces this receipt does not evaluate

notEvaluatedSurfaces is an unsigned response annotation, carried under the unsigned object and structurally separated from the signed receipt. It is not part of the signed receipt and not receipt authority — the signed coverageGaps remain the authoritative limitation list. It groups offchain (social hype, team identity, promotion disclosure — surfaces Raven does not evaluate from on-chain data) and futureLifecycle (creator-fee history, prelaunch funding graph, metadata clone — on-chain-adjacent surfaces this receipt did not evaluate), is constant for every token, and does not change the verdict. A clean on-chain verdict is never evidence about these surfaces.

Staleness & re-verification

Re-verify when: the receipt exceeds your policy window · a high-risk or material action follows · the prior receipt lacked pool/metadata evidence · the token program changed or was unclear · you are about to spend, trade, list, route, or escalate · the engine version changed. Recommended defaults: low-risk display = agent-defined; pre-trade/spend/listing = re-verify immediately; delayed execution = re-verify at execution time. No universal expiry is claimed.

Handoff

verify token -> verify receipt signature against your pinned key (/pubkey is discovery only) -> store exact signed receipt -> evaluate verdict + gaps -> proceed / block / escalate by policy

Final authority

Raven provides signed evidence, not final business judgment. It does not decide whether to buy, sell, hold, list, route, promote, or allocate — the integrator owns the decision policy, and the human operator owns exceptions and overrides. Overrides should be logged by the integrator, never silently hidden. Raven's job is to make sure no one acts without a verifiable preflight artifact.

For governance-constrained agents

Raven provides signed evidence receipts. It does not make the business decision, does not decide allocation, and does not replace treasury, legal, compliance, or security approval. Its role is preflight evidence, not investment judgment — a verifiable artifact for agents and humans to review.

Q: Can Raven decide whether my company should buy or hold a token?
A: No. Raven verifies token-launch evidence and returns signed receipts. It does not provide treasury, investment, trading, legal, or portfolio advice.

Q: Can Raven tell an agent a token is safe?
A: No. Raven returns evidence, verdicts, findings, and coverage gaps. If gaps remain, the correct phrase is: not enough evidence for a full pass.

Q: What should an agent do if Raven cannot check something?
A: Treat it as a coverage gap, explain why, and escalate or block according to policy.