---
title: How to read the decision log and check a track record
url: https://tideswell.xyz/docs/decisions/decision-log
description: Sort, search and filter every decision your business has recorded, then switch to the track record to see what worked.
---

> Documentation index: fetch https://tideswell.xyz/llms.txt to discover every page before exploring further.

# How to read the decision log and check a track record



**Decisions** in the sidebar holds two tabs: the log of everything recorded, and the **Track
record** of how those decisions turned out. See <Ref to="decisions" /> for the concepts.

## What is in the log? [#what-is-in-the-log]

A sortable table: **Decision**, **Affects**, **Who**, **When** and **Verdict**.

**Affects** is a chip naming the record the decision was recorded against. Clicking it opens that
record, which is usually where you want to be.

## How do you find something? [#how-do-you-find-something]

Sort by decision, person or date by clicking a heading. Search the affected record. Filter by
person, by date range, and by verdict state.

Three searches are worth knowing.

**By affected record**, to answer "what have we decided about this supplier". That is the one
you will use most, usually just before a call with them.

**By date range**, to reconstruct a season. Filtering to last spring produces the reasoning
behind a whole buying cycle in one screen.

**By verdict**, to see everything that missed. That is the most useful filter in the whole
product and the one nobody thinks to use.

The log shows the most recent decisions and tells you when it has reached that edge, asking you
to narrow the date range rather than quietly showing a partial list.

## What is on the Track record tab? [#what-is-on-the-track-record-tab]

The same decisions grouped by **Supplier**, **Person** or **Team**, showing how many commitments
closed, how many were met, missed or could not be measured, and the hit rate.

Only decisions with a committed outcome appear, so this is a smaller set than the log. See
<Ref to="decisions/outcomes" />.

Somebody in two departments counts in both rows of the Team view, and the screen says so rather
than leaving you to wonder.

## How should you read a hit rate? [#how-should-you-read-a-hit-rate]

With the count next to it, always.

A hit rate over four closed commitments tells you almost nothing. Over forty it is a genuine
signal, and it is the sort of signal most brands have never had.

A dash rather than 0% means nothing could be judged, which is a statement about your records
rather than about the decisions.

## What is this actually for? [#what-is-this-actually-for]

Three uses, in rising order of value.

**Answering "why is this like this".** Somebody finds an odd payment term or an unusual supplier
and the log says why.

**Preparing for a conversation.** Every decision about one supplier, with what was rejected,
before you talk to them.

**Learning what your business is good at.** Filter to missed verdicts across a year and read the
reasons. That is the closest thing to a post-mortem most brands ever run, and it costs a minute
per decision to have made it possible.

## Can you ask instead of reading? [#can-you-ask-instead-of-reading]

Yes. The analyst can answer what was decided, why, what was rejected and what was measured.

It needs the decisions view permission, and it reports decision and outcome side by side without
claiming one caused the other. See <Ref to="analyst/stock-suppliers-and-marketing" />.

## Why is the log empty? [#why-is-the-log-empty]

Because nothing has been recorded yet. The empty state points at your most recent real purchase
order rather than inventing an example, which is the obvious place to start.

Record one decision on your next significant order, per <Ref to="decisions/record-a-decision" />.
The log is worth exactly what people put into it.