---
title: "Data at the helm, then and now: the Brown Score, and an audit log with one entry for thirty-one jobs"
url: "https://toddpaulbrownjr.com/writing/data-at-the-helm/"
author: "Todd Paul Brown Jr."
description: "A usage score drove client retention at Banyan; an agent that never logged its own actions told nobody anything. Data steers only when it's written down and…"
kind: "article"
updated: "2026-09-26T02:50:27+00:00"
---

# Data at the helm, then and now: the Brown Score, and an audit log with one entry for thirty-one jobs

Data only steers when something is written down, and when what's written down is actually true.

## The Brown Score

At Banyan, between October 2015 and January 2017, I built a usage-score algorithm that correlated in-app actions with client satisfaction. The system became known as the Brown Score, and it gave account managers a number they could trust more than their instincts about who was about to churn.

The score worked because it measured real behavior — what users actually did inside the app — and tied it to whether they stuck around. Account managers checked the Brown Score every day. Entire workflows were built around proactive engagement with clients whose scores were falling, well before their 12-month contracts ran out. The success of that system was the single reason Banyan created a Business Intelligence function, which I moved into.

The Brown Score could predict with extremely high accuracy how likely a client was to churn as soon as their contract expired. No percentage exists on record, but the accuracy was high enough that account managers changed who they called and when, based entirely on what the score told them.

## The audit log that held one entry

In 2026, I built a job-search tool for a family member. The system discovers postings, scores them across 13 weighted dimensions, routes each into a pursuit strategy, generates tailored materials, and tracks every job through tiered approval gates. The whole thing runs on plain Python — two third-party packages, no database, no server process — with 15 named agent roles operating conversationally rather than through a traditional UI. Status: parked.

The project's own governance principle, written into its documentation: "Status is derived from artifacts present, not from any agent self-reporting. This prevents drift between reported and actual state."

That principle caught its own violation. The audit log held exactly one entry for 31 jobs already being tracked, because the code that initialized tracking state never logged its own actions. Fixing that gap — adding explicit state-change events — grew the log from 1 to 208 entries in the same session.

Visibility itself surfaced the deeper problem. Once the log had entries, status claims became checkable for the first time. It turned out 26 of the 31 tracked jobs had a step marked "done" that hadn't actually cleared its approval gate. The code checked only whether an output file existed on disk, never whether the step's upstream dependency had passed. I fixed it with an explicit dependency-enforcement pass and 6 new tests.

Status is now computed from what exists on disk plus whether dependencies are satisfied, never from what an agent reports about itself.

## What both examples do

The Brown Score and the dependency-aware status check are the same move: replace a guess or a self-report with something computed from real signal. At Banyan, the signal was in-app actions tied to renewal behavior. In the job-search pipeline, the signal is files on disk plus the approval state of their dependencies.

A dashboard that agrees with itself isn't proof the underlying data is right. The Brown Score needed to correlate with actual churn before account managers trusted it. The pipeline's status view reported 26 jobs as fully tracked when they hadn't cleared approval, and the system had no way to know that was wrong until the audit log existed and made the claim checkable.
Fixing visibility is sometimes what makes a deeper problem checkable in the first place. The audit log wasn't a separate step from fixing the dependency bug — adding the log made the bug visible. The Brown Score wasn't separate from the workflows that used it — the score only mattered because account managers acted on it every day.

Data steers only when something is written down, and only when what's written down survives a check against something outside itself.