Surfil

Best practices

Surfil works out of the box, but a few habits get you more from it - and keep you on the honest path the product is built around.

Simulate before you enforce

Never turn on blocking blind. Run Guard in simulate mode, read the redacted close-call report, tune until false positives are gone, then enforce. At fleet scale, the same rule applies through policy simulation - one over-broad rule can halt every developer.

Benchmark on your repo, then route

Don't pick a model from a generic leaderboard. Bench measures models on your tasks and signs the result; let that drive Cap's routing. Re-run it periodically - the best model for your repo changes as the repo does.

Capture facts as you go

  • Run surfil mind remember when you settle a convention - the next session starts informed.
  • Let staleness work for you: a fact whose code_hash stops matching is auto-flagged, so stale guidance surfaces itself.
  • Add never-remember rules for anything sensitive - it's dropped before any write, not stored then hidden.

Export signed results, not screenshots

When you need to show savings or a security posture to a client or auditor, hand them a signed export, not a screenshot. They verify it offline - which is far more convincing than a dashboard image, and stays valid forever.

Talk in tokens, not invented dollars

Savings are reported in tokens because that is the measured fact. When you translate to money, use your own rate on the measured token floor - don't inherit an invented dollar figure. The honest number is the durable one.

Every practice here reduces to one idea: measure, sign, and show the measurement. That is what makes a signed-proof product credible - see Signed outputs.