The dashboard is a view. The log is the memory

Your finance lead changed last quarter’s revenue cell because a customer paid late and the month now looks cleaner. Your ops lead overwrote the order status in the same sheet because the WhatsApp thread said delivered. Both people were trying to help. Both used an eraser on the only memory you had.

This week you decide what is allowed to be the source of truth for orders, payments, KYC events, and founder records. The dashboard is a view. The log is the memory. A view can be wrong and rebuilt. A memory that was overwritten cannot.

Why these three models

The decision is what may be overwritten and what must be appended. Quantities accumulate. An overwritten quarter does not walk back. Teams buy a prettier screen before the record is honest.

Three lenses, three outcome types. Stocks and flows give a complex answer: latest-per-key and full history are two different stocks, and compaction is an outflow you cannot reverse. Hysteresis gives a cycle answer: restoring the number on the screen does not restore the state, unless you kept the inputs and can replay them. Data-first gives an equilibrium answer: fix the record before you rent a prettier dashboard. Complex, cycle, equilibrium. That span is the point. LOOP is folded: the investor relationship is repeated, but the lever is the journal they can reconstruct, not a patience inequality. Single-writer ownership is governance and sits inside the levers. It names who may write. It does not change what the three models say about memory.

1. The two stocks: the latest row and the whole journal

Start with units. Most teams treat “the record” as one thing and then argue about which screen is right. A stock is a level. It changes only through inflows and outflows. The latest verified fact per key is one stock. The full history of every event that produced that fact is a different stock. They look similar on Monday morning. They do not obey the same outflows.

Ben Stopford draws the split as two topic types. By default a log is retention-based: messages stay for a configured time. A compacted topic keeps keyed facts and retains only the most recent event for each key, with older events for that key removed.² You can hold both and link them. He calls that the latest-versioned pattern. It costs extra storage and it is the only way to have a current view and an audit at once.²

Compaction is the outflow founders miss. Once V3 of a KYC row has replaced V1 and V2, those earlier states are gone. A compacted topic cannot rebuild a full audit.² Compaction is an irreversible outflow. The public credibility record can live as latest-per-key. The private log cannot.

Translate that into the week you are actually having. A WhatsApp order (“3 crates, tomorrow, Nakawa”) is an event. A MoMo callback is an event. A packed-and-left-the-depot ping is an event. If those facts die in the chat scroll, or land as overwrites on a single cell, you are running a compacted stock and calling it the books. The dashboard that reads that cell is a view of whatever survived.

Stopford’s claim for the log is stronger than convenience. Replayable logs give a central store that any application can fall back to: a shared source of truth.¹ Facts may be recast or applied in a new context, but they should tie back to a single thread of irrevocable truth.¹ A cell you can still edit last quarter is a view wearing a ledger’s clothes.

Stock-flow, the complex lens

• Assumes: latest-per-key and full history are two stocks. Overwrite drains the second.
• Fits because: orders, payments, KYC and founder facts accumulate.
• Breaks when: you needed the audit and compaction already dropped earlier versions, or superseded rows still linger and look current.
• Evidence: grade A for conservation. Compacted-topic mechanic is Stopford, folded in.
• Counteracts: treating the dashboard number as the stock.
• May reinforce: hoarding columns and calling the pile a journal.

2. The path back exists only if you kept the inputs

Hysteresis is system memory. After a threshold, putting the input back does not put the system back. The path out is not the path home.

An overwritten quarter is that threshold. Someone types the “right” revenue over the old figure. The screen now shows what they wish had been true. The surrounding decisions have already moved: commissions paid, tax reserved, an investor update sent, a hire justified. Restoring the old number later does not restore the quarter. The web of actions that used the false figure is the new state.

Stopford’s recovery path is the condition that breaks the trap. First you fix the bug. Then you rewind the log to before the bug was introduced, and you replay from the original stream of order requests. The store updates with corrected timestamps, and new events go downstream to correct the corrupted ones.³ That only works if the inputs were kept. A replayable log turns ephemeral messaging into messaging that remembers.³ If you kept only the compacted row, hysteresis stands. There is nothing to rewind.

He puts the accounting rule in one sentence. Event Sourcing records every state change, much like version control. “As the saying goes, ‘Accountants don’t use erasers.'”³ The event, not the mutated database record, is the source of truth.³

Hand-editing last quarter’s row is not a correction. It is an eraser.

Same-day is different. A typo in this morning’s invoice, caught before anyone paid against it, is still inside the window. Append the correction if you can. Overwrite if the event has not yet been read by another person or another system. Last quarter is outside that window. So is a KYC name you “fixed” after the photo was already filed with a partner. The filed photo is an input. Keep it. Replay from it if the mapping was wrong.

A MoMo retry on a dropped connection is the same test in a smaller costume. The callback arrives twice. If your books treat the second copy as a second debit, you invented a payment. If they treat it as the same payment id, you have a journal. Retries produce duplicate processing, and taking a payment twice leaves an incorrect balance.⁴ Idempotence here is just deduplication.⁴

Hysteresis-memory, the cycle lens

• Assumes: after a threshold, restoring the input does not restore the state.
• Fits because: typing last quarter’s old number back in does not undo the decisions already taken on the false figure.
• Breaks when: you kept the inputs and can replay from them. A replayable log is that condition.
• Evidence: grade B+. Shape established; founder transfer analogical. Stopford supplies the Breaks-when.
• Counteracts: the belief that a quiet edit returns you to the truth.
• May reinforce: refusing a same-day typo fix that nobody has yet read.

3. The lever: fix the log before you rent the view

The third lens is the one that stops you spending money on the wrong layer.

A curated, smaller record can beat a complete one. In the DataComp benchmark, models trained on a carefully curated 30 percent subset beat models trained on the complete set.^{5, 6} The authors’ own baseline is the same shape: smaller, more stringently filtered datasets generalized better than larger ones from the same pool, and the CLIP-score filter’s best training set sat near 30 percent of the pool.⁶ That result is about training sets, not ledgers. The transfer is the ordering, not the percentage. Fix the record. Then, if you still need it, rent the prettier apparatus. Founders invert that order every quarter. The sheet is a mess, so they buy a CRM, then a dashboard. The dashboard is a view of the same overwriteable cells, now with colour. The binding constraint was the journal.

This is also where staff get misread. The person who overwrites last month’s row is usually trapped, not choosing. The sheet is the only tool, the cell is the only place a status can live, and the weekly meeting punishes a number that looks wrong more than it punishes a number that cannot be reconstructed. Lecturing them is a DEPTH error. Change the write rule and the place a correction is allowed to land. The habit follows the structure.

The Breaks-when on this lens is honest. If the log already exists, two people can reconstruct last week’s GMV from it, and the team still cannot see the business, then the view is the constraint. Buy the dashboard. Until that test is passed, the next shilling spent on software is a decoration of a hole.

Data-lever-first, the equilibrium lens

• Assumes: a curated, correct record beats a larger or prettier apparatus built on a dirty one.
• Fits because: the binding constraint is the journal, not the charting layer.
• Breaks when: the view is genuinely the constraint: the log exists, two people can reconstruct from it, and nobody can read it.
• Evidence: grade B. DataComp is the measured result. Heritage reset: training sets, not ledgers.
• Counteracts: buying a CRM to fix a record problem.
• May reinforce: endless cleaning and never shipping a view the team will use.

Where the memory sits, and what flows out of it

Draw the boundary before you pick a tool. Inside: the company’s own records of orders, payments, KYC events, and founder facts. Outside: the bank’s ledger, the mobile-money provider’s settlement file, WhatsApp’s message store. Those are counterparties’ logs. You may request an export. You do not own the retention policy. If MTN or your bank later refuses last year’s callbacks, that is a gap you agreed to the day you called their file “the backup.”

You cannot set a stock. You can only change its flows. Stop the outflow on closed periods. Start the inflow: every new fact is an appended event. The latest-per-key stock is allowed to move. The history stock is not allowed to drain.

The lag is why the habit survives. An overwrite feels free on Tuesday. It is discovered at diligence, at a dispute, or when a customer swears they paid and your sheet says they did not, often months later. The person who edited the cell has already been thanked for cleaning the numbers. The loop that dominates is reinforcing: overwrite hides the error, which makes the next overwrite easier. The balancing loop is reconstruction from independent rails (bank, MoMo, delivery pings) on a fixed cadence. Most teams never install it, because the dashboard still looks fine.

Left outside this boundary, on purpose: whether two screens must agree this second, and how to change a field’s shape without breaking last year’s counterparties. Those are real. They are not this week’s source-of-truth call.

What you can change this week without buying software

Cheapest and most reversible first. Ruin sits on KYC and on payments. A silent edit there can end you with a partner, a regulator, or an investor who reconstructs the rail and finds a different story. Cap any write-policy change so it cannot touch those two classes until the rule is written down.

1. Classify the four records. Orders, payments, KYC, founder facts. For each, write overwrite or append-only. Latest-per-key is legal for a public profile and a current stock count. Full history is mandatory for money, identity, and anything you will later have to explain.
2. Freeze last quarter. Closed periods become append-only today. A correction is a new row that points at the old one.
3. Give every payment and every MoMo callback a stable id. A retry is the same fact. A second debit is a defect. If customers tap pay twice on a flaky network, the books must produce one receipt.⁴
4. Name the single writer per class. Sales may request. Finance may request. Only one owner writes the entity.⁴
5. Keep both stocks where you need both. Compacted for the current verified state. Full history for dispute and replay. Link them, even if the “topics” are two tabs.
6. Do not buy the dashboard yet. The log can be a dated sheet with one row per event and a ban on deleting rows. If two people cannot reconstruct last week from that sheet, a paid view will not save you.

What to lock before the next overwrite

Do now, by T+3, one afternoon, effect visible the same day. Write the overwrite-versus-append classification for the four record classes and freeze last quarter. Reversible: you can reopen a class that has no history yet. The effect arrives when the next person reaches for a closed cell and finds the rule.

Hedge, by T+14, premium is a week of double-entry, cover live before the next retry storm. Stand up an append-only log for orders and payments. WhatsApp orders and MoMo callbacks become rows: Order Requested, Payment Seen, Packed, Delivered. No deletes. The cover has to be live before the next dropped-connection weekend, or the hedge is a note to self.

Defer and trigger, size declared when the trigger is set. A new CRM or investor dashboard is irreversible spend on the view layer. Pre-commit the observable: thirty days of complete events in the log, and two people independently reconstruct last week’s GMV from it. When both are true, you may buy the view. Not before.

What a diligence file usually finds

Name the shape first. Reconstructability looks stable, then it falls off a cliff the week someone asks for last quarter as it actually happened. That is overshoot and collapse, not a gentle fade. The dashboard was the overshoot. The cliff is the first independent reconstruction.

Has a rule changed, has an actor entered or left, has a measurement become a target? The last one fires often. If the number on the wall is what people are paid on, overwrite is the system working. Last year’s “we always cleaned the sheet on Friday” then describes a target, not a book.

The class to match is any party asked to prove a history it stored as a mutable latest-row: the trader seeking a facility on reconstructed books, the founder whose GMV exists only as a cell, the operator whose KYC file is whatever the last clerk typed. Across that class, the reader reconstructs from the rail they trust (bank, mobile money, delivery confirmations) and treats your dashboard as a view to be checked.

The directional base rate does not need a percentage. Diligence does not take the dashboard’s word. It takes the journal’s, or the counterparty’s. MoMo and bank exports already timestamp the rail, which makes an honest log cheaper to keep and a quiet edit easier to catch. A month that “tied out” after three overwrites became consistent with itself. It did not become true.

One flag. If a regulator, a bank, or a lead investor requires a named ledger format you do not yet keep, the write-policy still holds and the storage mechanic may not. Rebuild the view from the log into the required shape. Do not start overwriting your log to look like their template.

What this read cannot see

These three models can tell you which stock you are draining and whether a path back still exists. None of them can tell you whether the mobile-money provider will still give you eighteen months of callbacks, or whether the person who has always cleaned the sheet will stop because you wrote a rule. You have agreed to be surprised by both. The honest belief that everyone remembers what the cell used to say is the behavioral layer. Naming it adds no lever the three cards lack, so it stayed out. Governance of who may write was folded into the lever list for the same reason.

One property no member models: once a journal exists, people start treating every WhatsApp ping as a fact that must be captured, and informal deals slow down. The chat was absorbing awkward cases (a crate on credit, a name spelled three ways, a delivery that was “basically done”). That absorption does not appear in either stock. You will notice it only when it stops.

The one action that survives the ignorance: before Friday, write which of the four records may be overwritten and which must only be appended. Then freeze last quarter. Investors trust a journal. Give them one, even if this week’s version is a dated sheet with a ban on deleting rows.

Who acts this week

The person who needs this is the one about to buy software, or the one about to tidy last quarter before a meeting. The cheapest first test costs an afternoon: classify the four records, freeze the closed period, and ask a second person to rebuild last week’s collections from the remaining rows plus the MoMo export. If they cannot, the dashboard was never the source of truth.

Sources and notes

1. Ben Stopford, Designing Event-Driven Systems: Concepts and Patterns for Streaming Services with Apache Kafka, O’Reilly, 2018, chapter 1, printed pp. 5 and 7. Replayable logs as a shared source of truth that any application can fall back to; facts may be recast but should tie back to a single thread of irrevocable truth. Book landing (login-walled): oreilly.com. Printed pages follow the book’s own pagination, confirmed against the text layer of the first-release PDF.
2. Stopford, ibid., chapter 4, printed pp. 24 to 25. Retention-based topics keep messages for a configured time. Compacted topics retain only the most recent event per key and remove older events for that key. Compaction is asynchronous, so superseded messages linger. The latest-versioned pattern keeps both a compacted topic and a full-history topic and links them.
3. Stopford, ibid., chapter 7, printed pp. 57 to 59. “A replayable log turns ephemeral messaging into messaging that remembers.” Recovery: fix the bug, rewind to before it was introduced, replay the stream of order requests. Event Sourcing records every state change, “much like a version control system. As the saying goes, ‘Accountants don’t use erasers.'” The event, not the database record, is the source of truth. Event Sourcing also keeps the state a service communicates and the state it saves internally the same.
4. Stopford, ibid., chapter 11, printed pp. 105 to 107, and chapter 12, printed pp. 112 and 115. Single-writer: responsibility for events of a type sits with one service, producing local points of consistency connected by the stream. Retries can duplicate processing and take a payment twice. Idempotence, in this context, is deduplication. Kafka-style exactly-once is not claimed here. Stopford limits that machinery to cases where both input and output go through Kafka (ch. 12, printed p. 119), which a MoMo callback and an HTTP retry do not.
5. Vijay Janapa Reddi, Introduction to Machine Learning Systems, Harvard, open textbook, Benchmarking chapter. DataComp (Gadre et al. 2023) “demonstrated that models trained on a carefully curated 30 percent subset of data achieved better results than those trained on the complete dataset.” Verified in the live chapter text. mlsysbook.ai/vol1/benchmarking.
6. Samir Yitzhak Gadre, Gabriel Ilharco, Alex Fang and 31 others, DataComp: In search of the next generation of multimodal datasets, NeurIPS 2023 Datasets and Benchmarks. “Smaller, more stringently filtered datasets can lead to models that generalize better than larger datasets coming from the same pool.” At the 12.8B scale the best filtering baseline raises ImageNet zero-shot accuracy 6.9 points against the unfiltered pool. “When filtering with CLIP scores, the optimal training set comes from selecting ~30% of the pool with the highest scores.” Abstract: arxiv.org/abs/2304.14108. Body (text layer): ar5iv.labs.arxiv.org/html/2304.14108.

Joshua Agonya Pi’Rwot, Founder.