Twenty-five tools.
None of them knows what the others did.

Your life is one system. Your software isn't.

This step is four moves:

(a) The problem gets named.

(b) The tools to solve it get listed.

(c) The families to sort the tools into get created.

(d) Each tool gets moved from the list into the table, under its family.

The problem is none of these tools knows what the others did. They don't talk to each other. So today, to see your full picture, you copy numbers out of each one into a spreadsheet and connect them by hand; and that spreadsheet is only as current as the last time you typed into it.

So who sends you all that data?

Every job has more than one company.
You pick yours.

A tool is a job. A provider is a company you hire to feed that job.

This step is four moves:

(a) Start from the table Step 1 built.

(b) Go tool by tool and ask one question: does this tool's data arrive from outside — someone else telling you what happened?

(c) If yes, pick the company that sends it. That company is a provider.

(d) If no, the tool stays home: the system will be that tool, and its data gets born here.

TINTED = STAY HOME

Nine tools take providers. Sixteen stay home. Count them; it is twenty-five. For the sixteen, nobody sends an API — not for your tasks, your invoices, your budget. So this system does not import those tools; it IS those tools, and their data gets born here. Our AI belongs to no tool; it serves every step. For the nine, you pick yours and your neighbor picks theirs. The system does not care; a provider is one row in the rule book — a code file, checked at build — and one enum value: the pipe gains no new tables and no new logic. More join over time. Each one is one new row!

So how do we actually get their data?

Store what arrived.
Then decide what it means.

Now we ask the providers we picked for their data.

This step is four moves:

(a) Start from the menu Step 2 built — the providers in the TODAY column.

(b) Ask each provider for its data.

(c) The answer comes back, and it gets stored as one row, word for word, before anyone decides what it means. That row is an arrival.

(d) Each row gets stamped: who sent it, what it is, its fingerprint, when we asked, when it arrived, when we read it, and how far it got.

Every part of a row is named at the top of the table, and nineteen rows are shown. Read across plaid's row — from your Chase connection — and you have read one whole arrival.

ONE ARRIVAL PER PROVIDER — AN EXAMPLE

And here is the real size of it: on August 24, 2026 we counted 121 feeds from 20 providers — one of those providers, xAI, has left since. We will show you a small example, so the idea stays small enough to hold. One more honest line: a few things we fetch are not data at all — handshakes, like the token that opens a bank connection. Handshakes are not data; they are how we knock on the door. They never enter the tables. And this table makes three promises: (1) nothing was ever edited — if a provider corrects something, the correction is a new row; (2) nothing was ever asked twice — if our reading of a row fails, we just read our stored copy again; (3) nothing was ever claimed — the fingerprint proves we stored exactly what they sent, but that does not necessarily mean they were right!

Now — what kind of thing is each one?

One rule per feed.
Written down.

Now we examine the data that we just imported in Step 3, and we give every feed a label.

This step is four moves:

(a) Start from the arrivals table Step 3 built.

(b) Fold the rows into feeds: one provider, one resource, one feed. Plaid's two connections are one feed.

(c) Ask of each feed one question: what IS this thing, really? The answer is one of six kinds.

(d) Write the answer down as one rule row — the feed and its kind — and the system applies it to every arrival of that feed, forever after.

A feed is one provider-and-resource pair; like Stripe's payouts, or Plaid's transactions, or TastyTrade's quotes.

Plaid alone sends more than one feed. So the rule book here shows two more of Plaid's — your accounts and your holdings — so you can see every kind a feed can earn.

Here is what makes this step different from every software you have ever met: each kind is given by a rule, and a rule is one written row in a table. Anyone can read it. Anyone can argue with it. It is not a guess buried in code. When a new provider shows up, it is one row in the rule book — a code file, checked at build — and one enum value; no new logic, no new tables. And the line is who did the math: if we ordered it or ran it, it is derived; a provider's own published math is reference. And there is a sixth kind; but no feed ever earns it. We will meet it soon.

So how many tables are there?

The kind picks the table.

Now we take every labeled arrival and move it into a table; one table per kind.

This step is four moves:

(a) Start from the rule book Step 4 built.

(b) Create one table per kind: six tables, six names.

(c) Send every feed's arrivals to the table its kind names.

(d) Look at what landed. The outside world fills four tables. Math we ordered fills derived. Posting stays empty.

THE RULE BOOK — SORTED BY KIND

Twenty-five tools, six tables; because we sorted by what a thing is, not by which tool it came from. But notice something strange here: (1) the outside world only ever fills four of the six — reference, registry, event, and snapshot; (2) derived is filled only by math we ordered, our AIs included; (3) and posting? Nothing from the outside world ever lands there. Nobody sends you debits and credits — the bookkeeping step builds those, from your own events. Remember that; it matters soon. We did not guess this. We classified every one of the 121 feeds — August 24, 2026 — and posting took zero. The data agreed!

Everything so far arrived from the world.

Today the six are views over the feed tables — event: transactions, investment transactions, bookings; reference: securities, places, the law corpus; registry: accounts; snapshot: holdings; derived: none yet; posting: empty by law.

So where do the things you do live?

Some things happen to you.
Some things you make happen.

For everything the system holds — did the world hand it to you, or did you make it?

This step is three moves:

(a) Take everything the system holds: the six tables' feeds, and the sixteen tools that stayed home in Step 2.

(b) Pull out each one's source — did the world hand it to you, or did you make it?

(c) Route it: world-given lands in OBSERVED, you-made lands in AUTHORED.

Today 5 of the sixteen keep their own table: Tasks, Time, CRM, Bookkeeping, Tax. The other 11 don't yet. One table for all of them is the blueprint.

Derived and posting your system computes — no draft. The sixteen you draft, then commit.

So how exactly do you make something happen?

Every tool runs the same four beats.
Discover. Decide. Commit. Record.

Book a flight, place a trade, send an invoice, post an entry, file with the state; same loop, different nouns.

This step is four moves:

(a) Discover — look at your options.

(b) Decide — pick one; the pick becomes a draft.

(c) Commit — pull the trigger; the world moves.

(d) Record — it is written down forever.

The blueprint: twenty-five of twenty-five — every tool runs these same four beats.

→ Step 8

Twenty-five tools. Twenty-five loops. One shape!

This loop is the blueprint — the shape we're building every tool toward. Today 6 tools run all four beats — discover, decide, commit, record: Tasks, Time, CRM, Expenses, Travel, Bookkeeping. Hotel and flight bookings commit for real, and an accepted task fires its build — for the repo owner today; the route refuses anyone else.

Twenty-five loops. Where do all the commits land?

One table holds
everything you do.

Every authored thing — a booking, an invoice, a trade, a filing, a budget — is stored as one document in one master table.

This step is three moves:

(a) Take every record the loops wrote — one per tool, twenty-five, still with no home.

(b) Give each one the same shape: a document with four fields — what it is, its life story, its pieces, who did it and when.

(c) Store all twenty-five in ONE master table.

The blueprint: twenty-five of twenty-five — every loop's record lands here.

EVERY DOCUMENT CARRIES THE SAME FOUR THINGS

Different names, same shape. That is why one table can hold them all!

The master table is the blueprint. Today each tool that has a table keeps its own; one table holding every document is the shape we're building.

You committed. The world moved. But how do you know the money really landed?

The deposit meets the invoice.
The fill meets the order.

Now observed meets authored.

This step is three moves:

(a) Take what the world said happened — the observed money events.

(b) Pull out the key from each: amount, date, reference.

(c) Find the document in the master table with the same key — and match them.

amount + date + reference → one match.

Click; one match.

The deposit found its invoice. The fill found its order. The card charge found its booking. Nobody hunted through statements!

Matched means real; the world just confirmed what you did.

(Two pieces of this are already alive today: card charges find their bookings and propose the match — you approve it; and you link a routine occurrence or a task to the journal entry that settled it.)

The other eleven move no money and need no match — they're real the moment you commit.

Matched and real. So who writes the debits and credits?

Nobody sends them.
Rules write them.

It is the same trick as Step 4. A rule is one written row that makes one decision. There, the rules gave kinds. Here, the rules write lines.

This step is three moves:

(a) Take the matched money events from Step 9 — fourteen, each confirmed by the world.

(b) Pull out each one's rule: which account takes the debit, which takes the credit.

(c) The rule writes the two lines into the posting table. You never type them.

Four quick glosses before we go on: A/R means money owed TO you. A/P means money YOU owe. Clearing means a holding bin that must end at zero. Withholdings means tax held back from a paycheck before it reaches anyone.

ONE SALE, THREE LINES

stripe payout — debit Cash + Fees · credit Clearing

Now watch it work. One sale for $100.00. Stripe keeps a $3.20 fee. $96.80 lands in the bank. The rule writes three lines:

And the deposit matches the bank to the penny!

WHO NEVER TOUCHES MONEY

One more truth: some tools never touch money. Calendar, Tasks, Time, CRM, Contracts, Mileage, Budget, Trade Log, Bookkeeping, Compliance, FP&A never write a line. Your hours reach the books one way only; through Payroll.

The posting view is the blueprint — today it holds zero lines by design — the ledger already has its lines. The rules writing them is the bookkeeping pipe we're building.

So what do all those lines add up to?

Every answer is math
on the lines.

Four questions, answered at any moment.

This step is three moves:

(a) Take the lines Step 10 wrote — the accounts, and the reference feeds an answer needs.

(b) Each answer is a lens: its math pulls exactly the lines it reads, and only those.

(c) The answer is computed from them — never typed, never stale.

Never typed. Never stale. This is the product!

And look at what these steps really are: Steps 9 and 10 are the bookkeeping system. Step 11 is the tax module and the runway screen. We did not bolt tools onto the pipe — the back half of the pipe IS the tools.

THIS IS THE PRODUCT.

These four lenses are the blueprint. Today all four compute — tax and the business result from the journal entries you commit by hand, runway from Plaid's account balances against those entries, trading from the positions and lots you committed, with no live quote in the number. The rules-written lines and the live quotes the blueprint reads wait on the posting pipe.

Four answers. Where do you look?

One Ledger. One Calendar.
All twenty-five.

There are two windows, and every one of the twenty-five tools shows up in both:

This step is three moves:

(a) Take every dated thing the pipe made — the lines Step 10 wrote, the documents from Step 8 that carry a date, the real deadlines.

(b) Pull out WHEN it is: a moment — a dot — or a span — a bar.

(c) It appears in both windows at once: as a row in the ledger, and on its day in the calendar. Same thing, two views.

Bars are things that last. Dots are things that happen.

Twenty-five tools. Two windows!

Two windows over one set of rows is the blueprint. Today the calendar window is live in the cockpit, and the ledger window is live in Books, showing the committed lines; the posting pipe will land more.

Can you watch one dollar run the whole machine?

One $100.00 sale runs the machine.
Then every other door opens.

This step is three moves:

(a) Take one sale — the $100.00 sale from Step 10 — and run it down all eight beats.

(b) Open every door — all twenty-five tools — and run their records down the same eight beats.

(c) Watch where each lane throws a shadow: fourteen write lines; eleven run the whole loop and write none.

SAME MACHINE, SAME EIGHT BEATS

The blueprint: twenty-five of twenty-five — every lane reaches YOU LOOK; eleven write no lines.

Nobody typed a debit anywhere in this story!

Read the no-line lanes twice! Eleven tools run the loop — and the project lane runs it all the way to a match — writing zero lines, because no money moved. The loop is bigger than money; money is just the loops that get a shadow.

Two more truths from this drawing:

Alive today: two matches — card charges find their bookings and propose the match, which you approve; and you link a routine occurrence or a task to the journal entry that settled it. The project lane is wired end to end: a task lands for your review, and accepting it fires the build that answers it — for the repo owner today; the route refuses anyone else.

Beautiful. But why should you believe any of it?

Click any number.
Walk it back.

Every figure traces to the exact words the provider sent — and the fingerprint still matches.

This step is three moves:

(a) Take one number off the screen — the $96.80 on "How long can I last?" — and walk it backwards.

(b) At every layer, name the record it came from and the check that proves the hop: the line, the rule, the match, the document, the arrival.

(c) End at the fingerprint — the code made from the payload the moment it arrived. Recompute it: it still matches.

SEVEN HOPS BACK TO THE PROVIDER'S WORDS

seven of seven hops checked at build — a failed check is a failed build.

Nothing between the screen and the provider's words was edited.

That is why you can believe the screen: every number walks back to its source — the exact words a provider sent, or the document you committed — and the rule that wrote the line.

Alive today: the fingerprint, on the rules and the audit log — every regulation pull is hashed the moment it lands, and the audit log hash-chains every entry it records; the citation re-check is written, but the hash it compares against is stored empty today, so it proves nothing yet. Today the Plaid feeds land in that table — every answer word for word, fingerprinted: 9,092 transactions, 712 investment transactions, 247 securities, counted September 7, 2026 — and so do LiteAPI's bookings, cancellations, booking reads and webhooks, and Stripe's webhook events. The other providers still land parsed; the same table is the shape they're moving into.

Twenty-five tools. And now every one knows what the others did.