Kairos is the AI. The LifeOS is the data architecture it operates on.
They are two separate pieces of work, and this is the one that usually stays invisible.
Fifteen domain modules plus an identity layer model one person's whole operating reality as queryable data: what they hold, what they owe, how they sleep, what they decided and what they promised.
For a buyer it is the concrete answer to what the thing does for their week.
For an interviewer it is the engineering underneath the AI.
Every block below is a real module with a declared schema. What appears here is the area it owns, what it captures, and what it gives back in practice.
Who you are: identity, values, how you operate, what stops you.
The agent does not know you in general, it knows you. You do not explain from scratch every time.
Sleep night by night plus naps, a whole-day body summary, intake, episodic health events, training sessions and the exercise and machine catalog.
When the body is not in a condition to decide, the system holds the decision instead of pushing you into it.
The design of your day, versioned, and the real execution of each habit, day after day.
The difference between the day you designed and the day you lived, measured rather than felt.
Accounts, transactions, recurring items and debts, with the financial phase detected before any advice.
Balance is derived from the ledger and never from memory, and the system knows what is due before you promise that money to something else.
Every work session, with clock in, clock out and each break subtracted one by one.
What your hour is actually worth after the break, rather than what you think it is worth.
Every goal and sub-goal, tied to the life area it serves.
A focus gate on buffett's 5/25: few active at a time, the rest go dormant and stop charging you attention.
The tasks, simple ones inline in the index and complex ones with their own note, prioritised by weight.
What to do now, ordered, instead of a list that only grows.
One immutable entry per decision, with the date, the why, what was expected and what was traded away.
When the outcome arrives it returns to the original line. That is how you find out whether you decide well, instead of remembering that you do.
The registry of every person and entity in your orbit, and what is open on each side.
Reciprocity becomes data: who showed up, what is outstanding, and in which direction.
What you hold now and the history of what ran out, deliberately kept apart.
It answers what is in the house and what can be cooked with it, without you opening a cupboard.
The fleet, every fill-up, every ride and every maintenance item, pending or done.
What your kilometre actually costs, and what maintenance will charge before something breaks.
Every item you want, in execution sequence, with a tier, a gate and an audit after the purchase.
A want joins a queue with a rule. You buy in order, not on impulse.
One row per trading day carrying the operator's state, plus the trade ledger, the executions and the journal.
It crosses how you were with what the trade returned, which is the correlation almost nobody measures.
The companies, the arms of each one, and which arm is the current spearhead.
One spearhead at a time. The other arms stay at concept until this one lands.
The catalog of what was published and the measurements per piece and per account, in separate files.
The measurement outlives the piece: delete the post and the historical series stays true.
Your life in eras, each one a closed node with a beginning, a turn and an end.
The system knows where you came from and does not treat you like someone who started yesterday.
Every module has four pieces with strictly separated jobs.
The driver is the machine SSOT and it is portable: schema, ENUMs, formats, procedures, gates, the cross-module key map, the NEVER list and the failure contract, with zero user data inside it.
The state is that person's operating reality, the data are their rows, and the cold start is the onboarding run once per user per module.
A driver never hardcodes a user path, and the loader assembles driver plus state plus data at runtime.
That is what makes this a product rather than one person's notes: build once, instance infinitely, across two axes, any user and any agent.
And the same separation decides WHERE each layer lives.
The framework stays as text permanently, because the driver and the cold start are pasted inside a system prompt and a system prompt is text.
Everything else is Postgres with pgvector: the rows, each module's state, the boards, the decision record, the eras and the identity.
The harness queries the database and injects the result underneath the framework.
This is not markdown waiting to become SQL, it is two layers whose formats were chosen separately.
Every item here exists because a real failure produced it.
Every column is required, optional or CONDITIONAL, and the conditional case is where the naive migration breaks.
Four columns in the transaction ledger are legitimately empty by design, so a DDL generated from the required markers alone rejects 33 valid rows on import.
That exception is documented before the migration rather than discovered during it.
Each file declares its own sort key, because a row in the wrong position parses cleanly and reads perfectly.
One file sorts on a key that is not its own date column, and nothing but the declaration would tell a reader that.
A file whose rows only ever arrive takes an integer id.
A file whose rows leave takes a stable slug, because a sequential id is freed when a row departs and silently rebinds every historical reference to a different entity.
That rule came out of a live bug where six foreign keys all resolved to the wrong item.
Field count per row against the header, primary-key uniqueness, sort order, foreign-key resolution and ENUM conformance.
It runs every time and not on suspicion, because a single unquoted comma inside a free-text field shifts every column after it and produces a row that still parses, with plausible values in the wrong places.
Balances, rates, totals and ratios are computed from the ledger at read time.
Prose that caches one is stale from the moment it is written.
Joined by a self-referencing key, because the amount changes crossing the currency and one row cannot carry both figures honestly.
A recurring defrag audits the system against its own contracts, module by module, hunting four named bug classes: a derived value copied into prose and left to rot, a change that reached a definition and never reached the queries that read it, a fact living in the wrong module, and a statement duplicated inside one structure.
It is data-integrity QA applied to a live system, and it has repeatedly found defects no mechanical gate can reach.
The largest of them: a headline metric returning 2.86 per hour against a real 14.11, because hourly employment had been typed with the payment shape of per-session work and 392 hours entered the denominator with nothing in the numerator.
Measured on 25 august 2026 by counting the files on disk. The system is alive and the count grows, so the date is here to make the number checkable rather than eternal.
The schema is designed and the database is not built yet.
Today the rows live in CSV, and that is exactly why the contract was written first: when the database is born, the migration executes a documented plan instead of discovering the exceptions during it.
It is dogfooded on one user and it is not multi-tenant in production.
What is on offer is the architecture, the contract discipline and the integrity practice, and all three transfer whole.
This is written up here rather than hidden because a page cut from an inflated source collapses under the first question, and it is precisely the declared scope that makes the rest believable.