A file-based operating system
Okapi is not a dashboard, not a bot, and not a folder of clever prompts. It is an operating system for running a business day to day, built from plain files instead of a database only one vendor can read.
Why it's built this way
Most small operations run on memory: what the owner remembers, what the one long-tenured employee remembers, what got done last time so it probably gets done the same way this time. That works until someone is unreachable for a week and nothing moves. Okapi starts from the opposite assumption: write the process down first, then let something reliable execute it.
Knowledge lives in one person's head. A new hire, a locked-in SaaS tool, or a bad week takes the whole operation down with it.
Software gets bought to fix this, and instead adds a login, a training cost, and a vendor who owns the data.
Every method, every decision, every correction is a file. Plain text and a handful of small databases, readable by any tool, owned by the business that built it.
Because it's just files, nothing about it depends on one AI vendor staying in business. Swap the model underneath and the system keeps running.
What's actually in it
Click a layer to open it. These aren't invented categories for this page — they're the actual folder names the system runs on.
What happens when it runs
Nothing here is hypothetical — this is the literal path a request takes, from being asked to being remembered. Step through it.
Why it improves instead of decaying
Most systems rot quietly. A method gets written once, nobody revisits it, and six months later it's wrong in ways no one notices until something breaks.
Okapi treats a mistake as data, not an embarrassment. Every session leaves behind a record of what was asked, what was delivered, and what had to be corrected. That record gets read back on a fixed cadence — patterns get mined out of it, and the method file that caused the mistake gets rewritten, not just the one output.
The result is a system whose oldest parts are its most battle-tested, not its most neglected.
What stops it doing something stupid
None of these are a policy written on a page and hoped for. Each one is a mechanical check, run before the risky step, not after.
Before it runs
Certain actions — publishing, spending, deleting, touching live infrastructure — are intercepted before they execute, not reviewed after the fact.
Before it ships
Anything that publishes externally or sends to a real person stages first and waits for a yes. The system drafts; a person decides what goes out.
Reading untrusted input
Anything arriving from outside the system — an email, a scraped page, a flagged file — is read as data to summarise, never as an instruction to follow.
Making a claim
Every diagnosis or recommendation can be asked to rate its own certainty. A wrong confident answer is treated as worse than an honest "I don't know."
Before committing
Any significant recommendation has to survive its own strongest counter-argument, written out loud, before it's allowed to be the final answer.
Citing anything
A date-sensitive claim or a quoted line has to trace back to a real, checkable source before it's allowed to be presented as fact.
For comparison
Underneath it all: plain text files, a handful of small databases, and open integration standards rather than a proprietary format. Nothing about how it's stored requires any single company to keep existing.
Want this in your business?
Okapi
Built to run a business the way a careful operator would, if that operator never forgot anything and never stopped writing it down.
What would you build if nothing you did this week had to be redone next month?