Check the record yourself

Radical transparency only means something if you can actually verify it. You do not have to trust a screenshot or a marketing curve. The record is designed so a skeptic can audit it end to end.

How the record is kept honest

The honest-mark rule

The pipeline never fabricates a price. If a symbol cannot be priced on a given day, its last known mark is carried forward and the record says so, or the run fails loudly rather than book a wrong value. A single paper book will show small vendor-to-vendor price differences of a few cents, and that is expected. The point is not fake precision. The point is that the number you see is the number that was recorded, tagged with how it was made.

What to look at

Each book keeps its own record directory. The NAV histories are plain text, one JSON object per line:

  data/books/client-zero-aggressive/nav_history.jsonl   # Ballast Aggressive
  data/books/balanced/nav_history.jsonl   # Ballast Balanced
  data/books/conservative/nav_history.jsonl   # Ballast Conservative
  data/books/systematic-aggressive/nav_history.jsonl   # Ballast Systematic Aggressive
  data/books/systematic-shortvol-watch/nav_history.jsonl   # Ballast Short Vol Watch
  data/books/crypto-basis-carry/nav_history.jsonl   # Ballast Crypto Basis Carry

Read a line and you get the date, the timestamp, the net asset value, and the source that priced it. Line up a statement's NAV with the matching NAV history row and they agree, because both are built from the same marks. Walk the git history of any of these files and you can watch the book accrue day by day.

Try it yourself: recompute one NAV point

This is a real worked example from the committed record, not a mockup. Ballast Balanced (book id balanced) was marked on 2026-09-02. Its holdings and that day's marks are two small files:

data/books/balanced/holdings.json
data/books/balanced/marks/2026-09-02.json

For each position, multiply shares by that day's mark, add cash, and sum:

QQQ         12.0000 shares  x  $709.24  =  $8,510.88
SPY         20.0000 shares  x  $765.16  =  $15,303.20
MTUM        18.0000 shares  x  $297.04  =  $5,346.72
TLT        275.0000 shares  x  $81.95  =  $22,536.25
GLD         22.0000 shares  x  $402.78  =  $8,861.16
DBC        304.0000 shares  x  $31.93  =  $9,706.72
SHV        246.0000 shares  x  $110.06  =  $27,074.76
VIXY       176.0000 shares  x  $17.28  =  $3,041.28
cash                                     $1,141.28
----------------------------------------
total                              =  $101,522.25

Now open the NAV history and find the line for the same date:

grep '"date": "2026-09-02"' data/books/balanced/nav_history.jsonl
{"date": "2026-09-02", ..., "net_liq": 101522.25302124, ...}

The recomputed total and the committed net asset value agree. That is the whole trick: nothing on this site is a number we typed in, it is always this same arithmetic over files you can read yourself.

Confirm the git timestamp

The NAV history line above was not added today. Ask git when it actually landed:

git log -1 --format="%H %aI" -- data/books/balanced/nav_history.jsonl
5f43d5506d19 2026-09-02T13:15:59-07:00

That commit predates this page. A record that could be quietly rewritten after the fact would not have a git history that lines up with when each figure was actually produced.

Forward record: does reality match the backtest?

The hardest promise a paper track record can make is that it will keep being honest once real time passes. Before a single live mark exists, each book freezes a forward claim from its backtest (the honest, deflation-consistent baseline Sharpe and worst historical drawdown, not an unproven overlay uplift). That claim is immutable: it carries a hash of its own contents, so editing it after the fact is detected. As live net asset value accumulates, we compute the realized forward record and compare.

The comparison is deliberately unflattering to us. If realized performance falls below the frozen claim beyond a pre-registered tolerance for a pre-registered window, the book automatically loses a trust rung with no human in the loop. Promotion, by contrast, is never automatic: a healthy record only becomes eligible for the top rung when a human grants it. That asymmetry is the point.

Each book's full forward record, including the exact pre-registered gate and the frozen claim hash, lives at data/books/<book>/forward-record.md.

The research ledger cannot be quietly rewritten

The kill log's pre-registration ledger is an append-only file with one row per strategy variant ever scored, 97 rows so far. Alongside it we commit a hash chain: every entry's hash folds in the hash of the entry before it, and the chain head commits to the entire ordered history. Edit any past row, drop one, or swap two, and the head you recompute stops matching the committed one. The check runs in one command:

python -m ballast.scripts.verify_trial_ledger
# current committed head: 54a3d1d5e7b80b2e... over 97 entries

The head is also anchored externally with OpenTimestamps, which binds it to a Bitcoin block time. Once the proof confirms, not even we can pretend a pre-registration existed earlier than it did: backdating would require rewriting a public blockchain. The committed anchor record carries the proof file and the exact command to verify it. It covers all 97 rows. The newest proof is pending: it has been submitted and accepted by the timestamp calendars and is waiting on a Bitcoin block to attest it, which takes hours.

Honest limits, stated plainly: the chain proves the integrity and order of what is committed, and an anchor proves the head existed by its block time. Neither proves a pre-registration preceded the researcher's knowledge of the outcome. That is what the forward record above is for, and it is why both mechanisms exist side by side.

The short version

Open the repository. Pick a date. Find that date's marks file, run the same public math over the holdings, and you will land on the NAV the record already shows. Nothing on this site is a number you have to take on faith. See the kill log for the same discipline applied to strategy research rather than the NAV record.