How to keep a DeFi decision journal for risk control

A DeFi decision journal is a running, tamper-evident record of the calls you make and the reasoning behind them. Routescore is a read-only, non-custodial decision-support workbench — it never takes custody of your keys, never moves your funds, and never tells you what to trade — so the journal's job is to capture why you acted, not to act for you. This guide walks through keeping one for risk control: what each hash-recorded decision record captures, the run-save-review-label workflow, and how later outcome labels turn a pile of notes into a calibration signal. None of this is investment advice.

Why a decision journal improves risk control

Risk control is mostly a memory problem. The trade that hurts is rarely the one you thought hard about — it's the one you forgot you had already reasoned through, or the assumption you never wrote down. A journal externalizes that memory so your process survives contact with a busy week.

It also separates the decision from the outcome. Without a record, you cannot tell whether a loss came from a bad assumption, stale data, or plain variance — they all feel the same in hindsight. A decision journal lets you audit your process instead of just your P&L, which is the only audit that actually changes future behavior.

There is a second, quieter benefit: it defends against hindsight bias. Once you know how a trade turned out, your memory of what you believed beforehand rewrites itself to look smarter. A record fixed at decision time — and made tamper-evident — is the antidote. Because each entry is append-only and hash-recorded, you cannot quietly edit yesterday's reasoning to flatter today's result. That discipline is the whole point: the journal is only useful for risk control if you trust that the past entries really are the past entries.

What a hash-recorded decision record captures

A decision record is a structured snapshot taken at the moment you make a call. For a route check, it captures:

• Route and notional — the candidate swap route you evaluated and the trade size you modeled it at. Routescore normalizes its components per-trade, so the notional is part of the record, not a footnote.
• Score and component breakdown — the 0–100 Routescore plus its parts: modeled MEV risk and slippage as subtracted penalties, gas efficiency and liquidity depth as added quality terms. A higher Routescore means a better execution-adjusted route; the record keeps the breakdown so you can later see why the number landed where it did.
• Methodology and feature versions — the version of the scoring methodology and of the detector that produced the number (for example, the MEV detector version). When the methodology changes, old records still state which version scored them, so a six-week-old entry stays interpretable.
• Source freshness — whether the inputs were a fresh live quote, cached, or a static sample. A score off stale inputs is not the same evidence as a score off a live quote, and the record says which.
• Caveats — the published caveats that applied: supported tokens only; modeled and point-in-time; the risks the score deliberately excludes (oracle, bridge, and smart-contract risk, surfaced separately). The journal carries the disclaimer alongside the data so a future reader does not over-read the number.
• Confidence — the modeled confidence label (high / medium / low) Routescore attached, which is downgraded for private-intent flow and unmapped dependencies rather than assumed away.

Every record is hashed with SHA-256 and chained to the entry before it, which is what makes the journal tamper-evident: change one field and the hash no longer matches the chain. It is a tamper-evident hash record, not a wallet-key signature — Routescore does not hold a key on your behalf.

The journal workflow: run a check, save the record, review, attach an outcome label

The loop is short on purpose, so it survives real use:

1. Run a check. Score a route — or run a what-if, stress, or yield scenario. You get a number, a component breakdown, and the caveats that apply to it.
2. Save the record. Append it to the journal. The entry is written append-only and hash-recorded the instant you save it, so the snapshot reflects the inputs and methodology version as of that moment — not as of whenever you next open the page.
3. Review. Periodically read back through recent records. The value is not in any single entry; it is in the pattern — which assumptions you keep making, which caveats you keep waving away, and where stale data crept in.
4. Attach an outcome label. Once a decision has played out, or once an external label updates, go back and mark what actually happened. Labels are evidence states, not verdicts: confirmed-benign, confirmed-malicious, suspicious (high or low confidence), inconclusive, or a reported false positive / false negative. A "confirmed" label is only as strong as the evidence behind it, so the journal keeps confirmed and suspicious separate rather than collapsing them into a win/loss tally.

When you attach a label, the record also notes how the outcome was reconciled — an exact transaction, a similar transaction class, an external label update, or an explicit review. Storing the reconciliation type means a later reviewer can see how firm the label is, instead of treating every label as equally certain.

How outcome labels feed calibration

Labels are where the journal stops being a diary and becomes a feedback loop. Each labeled record turns into a calibration sample: a pairing of what the model showed at decision time with what was later observed. Aggregate enough of them and you can ask the one question that actually matters for risk control — when Routescore showed high MEV risk, how often did MEV actually show up?

Calibration partitions these samples by order flow — public-mempool versus private-intent — because a model that is well-calibrated on one is not automatically calibrated on the other. The output is a calibration curve, not a promise: it tells you how much weight a given score deserves, and no score promises an outcome. The discipline of labeling honestly — including the false positives you would rather forget — is exactly what keeps that curve trustworthy. A journal full of only flattering labels calibrates to nothing.

Exports: JSON and CSV

Your records are yours and portable. Export the full journal as CSV for a spreadsheet, or as JSON for a notebook or your own analysis. Each row carries the score, the component breakdown, the model versions, the source-freshness state, the caveats, and any outcome label you have attached.

Because the export includes the SHA-256 hash for each entry, a third party can recompute the hash and confirm the record was not altered after the fact — that is what "tamper-evident" buys you outside the app, not just inside it. And nothing in the export touches a key or a balance: it is read-only data about decisions you already made, on a workbench that stays decision-support only.

Where to go next

• DeFi decision journal — what the feature captures and how the hash chain works.
• route check — run a route and produce the record you will save.
• journal — open your append-only, hash-recorded journal.
• pricing — where the hash-recorded journal and CSV export sit across tiers.