C.W.K.
Stream
Lesson 01 of 05 · published

The Snapshot Bet

~11 min · data-model, domain-modeling, scope-discipline, non-goals

Level 0Open Gate
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"A ledger tries to remember every step you took. A snapshot just tells you where you're standing. Pick the one that answers your real question."

Two ways to model money

There are two fundamentally different ways to model a portfolio. A ledger records every event — each buy, sell, dividend, fee, and split — and reconstructs your current position by replaying that history. A snapshot stores your current state directly — you hold N shares of this, this much cash — and doesn't keep the trail of how you got there. Keep is deliberately a snapshot system. Each owner has one position per ticker, a seed amount, and a stored cash balance. That's the whole shape.

Why choose the snapshot?

Because it matches the actual question. Keep exists to answer "what does the family hold right now, and how is it doing?" — not "reconstruct every transaction and compute the tax consequences." A full ledger is enormous surface area: tax lots, cost-basis methods, wash-sale rules, dividend reinvestment, fee accounting. Every one of those is a place for bugs, and none of them serve the low-trigger monitoring goal. So Keep names them all as explicit non-goals: no tax-lot accounting, no dividend/fee ledger, no transaction history. Scope is a feature.

Model the question you actually have, not the most general one you could imagine. A ledger is more 'complete' in the abstract, but completeness you don't need is just surface area for bugs. The snapshot is a smaller, sharper model that answers the real question exactly — and refuses the ten questions you were never asking.

What you give up, honestly

This isn't free. A pure snapshot can't tell you your realized gains for the tax year, or reconstruct why your cost basis is what it is, because it never stored the transactions. Keep accepts that trade-off on purpose — those are exactly the ledger features it declared out of scope. If you genuinely need tax-lot accounting, a snapshot is the wrong model and you should know that before you build. Choosing the snapshot is choosing to answer one question extremely well instead of ten questions adequately.

The scope-creep trap: 'while we're at it, let's track transactions too.' It always sounds reasonable — you're already storing positions, why not the trades that made them? Because that one addition drags in tax lots, fees, reconciliation, and an entire accounting engine, and quietly turns a calm snapshot tool into the trading ledger it was built to avoid. The non-goal is the guardrail.
Snapshots still get history — just not a transaction log. Keep isn't frozen in the present. It keeps a time axis through append-only daily value snapshots (next lessons), so you can see how the total moved over time. That's history-of-state, not history-of-transactions — the calm middle path between 'no past at all' and 'a full ledger.'

Code

Two models, two shapes (illustrative)·python
# LEDGER model: store events, replay to get the current position.
transactions = [
    {"date": "2026-01-05", "action": "buy",  "ticker": "TICK", "qty": 10, "price": 100},
    {"date": "2026-03-02", "action": "sell", "ticker": "TICK", "qty": 4,  "price": 130},
    # ... every event forever, then reconstruct + compute tax lots + fees
]

# SNAPSHOT model (Keep): store the current state directly. Done.
position = {"owner": "owner_a", "ticker": "TICK", "shares": 6, "seed": 1000}
cash = {"owner": "owner_a", "balance": 250.00}   # stored, authoritative

# Keep answers 'what do you hold now?' from the second shape,
# and deliberately never builds the machinery the first one needs.

External links

Exercise

Pick a domain you might model — a pantry, a book collection, a savings goal. Describe the 'ledger' version (store every event: bought, ate, lent, returned) and the 'snapshot' version (store current state: what's on the shelf now). Which question does each answer well? Then decide which your real use case actually needs — and name what you'd be signing up to build if you chose the ledger.
Hint
The ledger tempts because it feels more powerful, but ask: do you actually need to reconstruct the past, or just know the present? If the honest answer is 'I only ever look at what I have now,' the ledger is expensive machinery for a question you never ask.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.