StrataLedger

I could put an item into an accounting category, but that did not tell me which longer-term intention it served. That gap became StrataLedger. I wanted a ledger where a record could be connected to a principle, a strategy, a domain, and a project, while still being simple enough to enter and inspect. I was learning spreadsheets at the same time, so starting with a visible workbook made more sense than promising a complete automated platform.

The first proposal reduced the larger hierarchy to three sheets: accounts, categories, and a split ledger. Classifying a transaction once would let reports roll it up in several ways. Later I explored a web workflow with an inbox, review step, dashboard, and periodic comparison of intended and actual allocations. I also reported building a site and finding that the name was already in use. The story remains an experiment in making the meaning behind an allocation visible; this record does not show a finished, renamed product or expose the private examples used during its design.

The hierarchy

The larger concept used this chain:

Principle → Strategy → Domain → Project → Transaction

A principle expresses a general intention. A strategy describes how to pursue it. A domain groups a part of the system, while a project provides a more specific commitment. The transaction is the recorded action at the end of that chain.

The assistant explored mappings to existing software before proposing a custom build. Envelope-style categories, split transaction lines, documentation, and reports could each carry a piece of the model. The discussion treated those as implementation options, not proof that the complete concept already existed inside another product.

The three-sheet starting point

The minimum spreadsheet proposal was deliberately smaller than the full hierarchy:

The category table supplied the extra meaning. An entry assigned to a category inherited its domain and strategy through lookup columns, so those labels did not have to be retyped on every row.

The original sketch used the familiar lookup structure:

VLOOKUP(Category, Categories.$A$2:$C$100, 2, 0)
VLOOKUP(Category, Categories.$A$2:$C$100, 3, 0)

Here, Category was schematic notation for the selected category value, not a claim that a finished workbook already contained a defined named range. The second and third returned columns represented domain and strategy.

Three pivots would then summarize the same ledger by category, domain, and strategy. That was the core learning exercise: enter data once, attach consistent meaning, and compare several views of it.

The web-app direction

A later discussion translated the idea into a browser workflow. The proposed first version used manual or CSV input, followed by a transaction inbox, classification review, an allocation dashboard, and a periodic review screen.

The important interaction was the classification step. The user would connect an action with the domain it served, the strategy it supported, and any relevant project. The dashboard could then compare stated priorities with actual allocations.

I also responded strongly to a plain-language question from the discussion: “Did my money go where I wanted my life to go?” That phrasing made the purpose easier to understand than a screen full of abstract hierarchy names.

What changed before a finished product

The project moved among a spreadsheet exercise, explanatory documents, and a web-app concept. In a naming discussion I reported that I was building the website, while also discovering that the StrataLedger name was already in use. Alternative names were explored; there was no final rename established in this material.

I could describe a first workflow: enter a record, classify it once, and inspect it by category, domain, and strategy. The name conflict and movement between spreadsheet and web designs remained open in this material. A small set of test records flowing through that complete path would have been the proof the idea still needed.