What Is the Audit Trail on dice.run?

Updated

dice.run is a dice roller for tabletop RPGs and game design that parses standard dice notation and returns rolls "with full audit trails." In practice, that means a roll isn't just a final number — it's a record you can go back to and check. This is useful when a result matters (a death save, a crit confirmation, a contested check) and someone at the table wants to verify how it was produced rather than take the number on faith.

What the audit trail covers

Based on the site's own description, the audit trail is tied to how dice.run handles a roll from expression to result. The relevant pieces:

  • The expression you entered — the standard notation string, e.g. a multi-attack array or an attack-plus-damage roll.
  • The roll itself — the individual dice outcomes behind the total, not only the sum.
  • The resulting distribution context — dice.run computes the exact odds (mean, range, and full distribution) for the expression as you type, so a roll can be read against what was expected.

The site frames this as "roll with full audit trails," alongside parsing standard notation and analyzing probability distributions. Those three features are presented together, which is the point: the trail is what connects a specific roll to the notation that generated it.

Why it matters at the table

A bare total ("you rolled 17") is hard to dispute but also hard to reconstruct. An audit trail changes the question from "do you believe me?" to "here's the record."

Concrete cases where that helps:

  • Verifying a past roll. A session ends mid-combat; next week you need to know whether the crit actually confirmed. The trail lets you review rather than re-roll.
  • Reviewing a sequence. Multi-attack as an array and roll-mode switches (normal / advantage / disadvantage) produce several dice at once. The trail keeps those grouped so you can see which die belonged to which attack.
  • Game design and balance work. When you're testing whether a mechanic feels right, you want the distribution and the sample rolls side by side. The trail supplies the sample side.

How it fits with notation and distributions

The three features aren't separate tools — they reinforce each other:

Feature What it gives you How the audit trail uses it
Standard notation parsing Turns a text expression into a rollable instruction The parsed expression is the anchor the trail records against
Probability distribution Exact mean, range, full distribution as you type Lets you judge whether a rolled result was typical or an outlier
Full audit trails A reviewable record of the roll The thing you actually go back and read

So if you type an expression and roll, you get a number and the machinery to explain it. The distribution tells you what should happen; the trail tells you what did.

What to check before relying on it

The site's public description confirms the audit-trail feature exists and pairs it with notation parsing and distribution analysis. It does not, in the material available, spell out retention limits, export formats, or whether trails persist across sessions. If your use case depends on long-term records — a campaign log, a design test log — verify those specifics on the site itself rather than assuming.

For most tabletop use, the practical takeaway is simple: dice.run is built so that a roll can be reviewed, not just announced. If you regularly need to justify or reconstruct results, that's the feature to lean on.