IndieBiz OS

The shared warehouse — a media network for the age when AI does the reading. And the personal AI OS that fills and reads it.

Homepage | English | 한국어

IndieBiz OS has two axes. One is an AI agent system — a personal OS that compiles plain language into an action language (IBL) and hardens frequent work into apps you own. The other is the shared warehouse — something that doesn't exist anywhere else, and simple enough to explain in a paragraph. So this README starts with the warehouse.

The shared warehouse — a media network without platforms

You put a file in a folder. That is the entire act of publishing. The 공유창고/0..4/ folders on your disk are served live at your node's public address — no index, no conversion; the filesystem is the truth. Humans open it in a browser; other people's AI agents read it through /manifest (JSON).

Platforms were shelving for humans

YouTube, blogs, Twitter, and shopping malls exist as separate services not because the data differs in nature, but because humans can't handle raw data, so someone had to pre-build — and monopolize — a different shelf (UI) for each kind. The moment an AI stands on the reading side, that premise dissolves: rendering happens at visit time, on the reader's side. So one warehouse becomes whatever you put in it:

What you put in	What the warehouse becomes
videos	YouTube
writing	a blog · Twitter
a product catalog	a shopping mall
a list of services	a freelance network

A broadcast station and a shop at once — and format-free (schema-on-read): the warehouse serves bytes (a PDF as a PDF, a spreadsheet as a spreadsheet), and interpretation is the reading AI's job.

The asker pays

The old web made the host pay for querying, rendering, and delivery — which is why a crowd of visitors melts the owner's server. The warehouse inverts it: the owner only places files; the searching, filtering, and rendering are computed by the asker's AI, on the asker's hardware. Serving costs the owner ~nothing. That's also why there is no CAPTCHA: the web blocks bots as a symptom of server-pays economics, but here a reading AI brings its own compute, so the door never asks "human or bot?" — only "who are you?" (identity and level).

The number on the folder is the gate

A visitor's level (0 → 4) is the same scale as their grade in your neighbor CRM — promote someone once and it applies to messaging, portal membership, and the warehouse alike. A viewer sees levels 0..their level merged into one flat list (same name: higher level wins), and a file above their level returns 404, not 403 — existence itself is information. The one deliberate leak is a single has_restricted flag, a smell: "there is more here," with no names or counts. Since the security is the level, the address needs no hiding — the front door stays confidently open.

`/manifest` — the machine face, and a very small protocol

Beside the human page, the same listing is served as JSON — a title, files with sizes, mtimes and direct URLs, has_restricted, a self-describing about, and a login block stating exactly how to authenticate. A foreign AI agent reads your node without scraping HTML or reverse-engineering anything.

And that is the entire contract of the face: GET /manifest + GET /f?path= + a cookie login. Just HTTP and files — no IBL, no cognitive pipeline, not even IndieBiz OS itself is part of the contract. Any AI system can implement the same face in an afternoon, and that's the point: like RSS and TCP/IP, the interfaces that win are boringly small.

The reading half — a neighbor feed, and reposts as files

Register a neighbor's warehouse and a poller fetches their /manifest every 30 minutes, diffing paths and mtimes into a timeline — seed on the first poll (their back catalogue, like seeing past posts right after a follow), then new and changed. The retained snapshots double as a filename index of your whole neighborhood, so one search sweeps every neighbor's warehouse at once. This layer is pure machine — zero model calls, zero tokens: collecting the scent is mechanical; interpreting it is the AI's job.

A neighbor doesn't have to run IndieBiz OS. Under the poller sits a dialect-adapter layer that normalizes nginx/Apache directory indexes, RSS/Atom feeds (auto-discovered from HTML), Nextcloud public shares, and even the file links on an ordinary web page into the same manifest currency — someone becomes a neighbor without installing anything. A blog's RSS or a file server's index subscribes as-is, so the entire existing web is a potential first neighbor — the network doesn't start in an empty room.

Once adapters existed, the problem inverted: the world is already full of warehouses and there was no way to look at them. So finding neighbors now has two halves — an inbox for people who introduced themselves, and browsing: a genre-tagged directory of warehouses you don't know yet (a live parse plus a seed list you can edit). A neocities adapter joined the dialect layer, which makes 1.69 million personal homepages warehouse candidates. And you can hand one neighbor to another: a public recommendation where the machine fills in only the facts and you rewrite it before it goes out — the body follows a small convention (Warehouse : <url>), so on the receiving side an "＋ add" button appears right there in their neighbor-finding tab.

A warehouse address isn't a separate address book — it's stored as one more contact type on a neighbor, right beside their email and Nostr key (someone you only know by address is still a proper neighbor). A repost is a standard .url shortcut file dropped into your own warehouse; when your manifest is served it resolves to the original, so a subscriber's click goes straight to the origin warehouse, never through you. Friend-of-a-friend discovery, implemented not as a protocol but as a file.

Subscription doesn't stay anonymous (level 0), either. Warehouses serve a join page; sign up or log in through the in-app browser and the credential is captured on the spot — no copying it anywhere by hand. From then on the poller logs in through the manifest's login contract, so files at your granted level flow into your feed and search. Expired or revoked cookies re-login automatically, and if login fails the poll continues anonymously (the feed never stops). There is no separate key exchange: the credentials you made at signup are the key.

The AI fills it — production is publication

What this system's agents produce is published the moment it is made. Daily schedules use checked, stored IBL functions to drop the morning newspaper, an AI trend report, and the latest blog post into the warehouse, and business items (Sharing · For sale · Can do …) are auto-materialized from the DB into garage-sale shelves — each item becomes a document plus photos in a warehouse folder, so an outsider browses your whole catalog without ever asking. The intro document ends with an automatically attached way to reach you (your Nostr address). To subscribing neighbors, all of it flows past like tweets.

The easiest live example — a sharing economy

Put something you're giving away under Sharing: it appears in your neighbors' feeds → a neighbor's AI recognizes the match → one DM → hand it over. The whole loop closes with no payment layer — the first practical case. Selling and commissioning are the next chapter, to be built on top.

Filling this warehouse — and reading and interpreting your neighbors' — is ultimately an AI's work. From here on, this README is about that AI: the second axis, the agent system.

IndieBiz OS X-Ray Body Map
X-Ray: Your system's vital signs — cognitive nodes, action health, and self-check status, all alive.

In one minute

IndieBiz OS turns plain language into a real action language — IBL — that runs on your own desktop and phone, and lets the things you do often harden into one-tap apps you own. No app store, no cloud account, no code.

You say what you want. How you say it depends only on how often you do it:

You want to…	You get…	Surface
"Find lease listings near Gangnam under 500M and put the top 5 in a report" — a one-off	the AI discovers the steps and just does it	Autopilot
the same kind of task, repeatedly	a lightweight model translates it into a reusable program you inspect and keep	Cockpit
a task you do every day	it crystallizes into an icon you tap — 0 tokens, instant — even on your phone	App

One system, one person, from a one-off question to a superapp you authored just by using it. It starts minimal and grows only what you ask for; an AI agent is the blacksmith who keeps forging it to fit you.

New here? → What it actually is · See it on a phone · Install in 3 lines

The one idea

Most AI harnesses get more capable by reaching for more intelligence — a bigger model, a longer prompt, more tools. IndieBiz OS makes a different bet:

Handle complexity with structure, not more intelligence — because structure is the one layer no foundation model absorbs.

A better model keeps absorbing how to produce an action. It never absorbs where the action lives, who owns it, how often it repeats, or whose body it runs on — that's the life around the generation, and it's where IndieBiz OS works.

That bet rests on two generative cores. Almost everything distinctive about the system falls out of them — so instead of listing fifty features, this README shows the two roots and lets the features hang off them as consequences:

There is a real language underneath — IBL. A small, regular vocabulary that every part of the system compiles to.
A clean seam between the vocabulary and the body. What a capability is stays separate from which machine runs it.

If you grasp those two, you can re-derive the feature list yourself. That's the point.

What it aims to be — a wearable robot, not an autopilot

Most harnesses aim at autonomy: give a destination and the AI drives there on its own — you specify, you receive. IndieBiz OS aims to be a cognitive exoskeleton you wear. It absorbs your settled judgment so repeated work happens almost unconsciously, freeing your conscious attention for what doesn't repeat. And it doesn't need a clear destination up front: for the deepest work — research, writing, building, deciding what you even want — the goal isn't given then pursued, it's discovered in the pursuit. Autonomy treats the destination as a precondition; an exoskeleton treats it as a product — co-authored step by step, with you still holding the judgment.

So the development north star is fit (착용감): the exoskeleton disappearing into intention; trials made cheap enough that your taste drives a tight loop; your judgment reaching further — not you doing less. Success is the fruit you couldn't have made bare, never how little of you was needed. A self-driving car's endpoint is to delete the driver's seat; ours is to make the seat worth sitting in even when the system can drive itself. (Full vision: data/system_docs/vision.md.)

Philosophy — a system you raise, not one you're given

IndieBiz OS is not software you install and use as-is. It's a living system — like armor forged to fit your body, or a horse you raise and ride yourself. An AI agent sets up the skeleton, asks about your life, and starts building — but the system only becomes yours through use. Your habits shape it; your needs grow it.

No two installations are the same. A freelancer's system looks nothing like a small-business owner's; hand yours to someone else and it wouldn't fit. It starts minimal — only the core (IBL engine, cognitive pipeline, hippocampus) — and grows on demand: say "track my investments" and the investment package appears. No app store, no mandatory update, no one-size-fits-all. Your AI agent is the blacksmith who keeps forging it as you grow.

Only the body is hardcoded; the world is held provisionally. The only nouns this system fixes are the body's vocabulary (sense, self, limbs, others). Knowledge about the world — people, places, things, relations — lives not in a schema but in memory, as sediment that carries confidence scores and staleness marks and is allowed to be wrong. This is the opposite of enterprise ontologies, which model the world up front and then pay forever to keep the model current — here, use itself keeps rewriting the world-picture. (Constitutional clause: "The Place of Nouns" in data/system_docs/ibl.md.)

And one day these individually raised systems find each other — connecting over decentralized networks, each unique but speaking the same language. That is the vision.

Why this shape — the whole spectrum, not one end of it

People want two different things from AI, and the market sells them as separate products. One crowd wants autopilot: say it, the AI does it — fast, but you own nothing afterward and pay full price every time. Another wants the artifact: code-generation agents hand you something durable — but it's code, and code needs a production environment (terminal, server, hosting) to run.

A single person doing real work needs both — and a third thing between them — as one continuum, not three purchases:

one-off, exploratory work → autopilot (let the model discover the steps)
recurring work → functions (natural language compiles to an IBL program you keep)
daily work → an app (an icon that runs deterministically, 0 tokens)

No single task needs all three; a single life does. The market doesn't sell the continuum not because it's unwanted, but because it only collapses into one product at personal scale. In a company the three stages split across three roles — developers generate, ops run automation, users tap apps — three people, so three products. Put all of it in one pair of hands and it has to be one system. Single-user isn't a limitation here; it's the condition that makes the spectrum coherent. That is what "IndieBiz" means.

It arrives as a link, and installs anywhere

The clearest demonstration is IndieBiz OS on the device already in your hand — and you get it there with a link, not an install. The remote launcher serves the same surfaces the desktop has — autopilot, cockpit, apps, your shared warehouse, and the foraging browser — to any browser: Android, iPhone, iPad, an old tablet propped up in the kitchen, a laptop you borrowed for the afternoon.

Then, if you want, it stops looking like a browser tab. The launcher ships a web app manifest, so "add to home screen" makes it an app — its own icon, its own name, no address bar, its own entry in the app switcher. Two taps on Android or iOS. Nothing built per platform, nothing signed, nothing approved by a store, and nothing to update. The remote finder installs the same way as a second app, IBFind, for reaching your files. Neither one caches: both are live views of a machine you own, so their service workers pass every request straight through.

That matters because a phone is a sealed consumption device: no build toolchain, no server, no way to author-and-run your own app. A code-generation agent's output strands there — an app you cannot run. IndieBiz OS's "app" is not a compiled binary but a declaration over the IBL the runtime already speaks — declare an instrument once and it renders on every surface at once, and one of those surfaces is a browser on any device you own. Authoring and running collapse into one moment, and the hardware stops mattering.

And the browser is a client, not a screen. Files cross both ways — upload from the gallery, download to the device. Audio plays out of the thing in your hand, not out of the machine that fetched the stream. The clipboard reaches your PC in one tap. The one honest condition is that your own machine has to be awake: this is your system reaching you, not a cloud renting it back to you.

The closest existing thing — Apple Shortcuts, Tasker — proves the demand is real, but it's only the bottom of the spectrum: you still hand-author each shortcut in a fixed visual language, nothing crystallizes from use, and it's bound to the OS's actions, not your context. IndieBiz OS is that on-device execution plus an autopilot on-ramp plus a vocabulary that's yours. Not "like a superapp" — the first superapp a person builds for themselves, without being a developer.

Core #1 — There's a real language underneath (IBL)

Every capability — a web search, a file write, a phone notification, a chart — composes into a program in one language, IBL (IndieBiz Logic):

$news = [sense:search]{query:"AI news"}
[self:write]{path:"result.json",content:json($news)}

Six nodes (sense, self, limbs, others, engines, table), one composable vocabulary. The point is not the size of the action list — it's that it stays small (down from 332 at its peak; current counts live in Under the hood, regenerated by the build), because related tools keep getting folded into single actions with parameter/op branching (45 bespoke Android actions became one [limbs:android]{op}). The language got smaller as it got stronger — and it is still shrinking: a 2026-08 compression pass took it from 163 to 144 while adding expressive power. Fewer, more composable verbs that a human or a small model can write one line of and have work. Because everything speaks one vocabulary, your accumulated experience forms a single coherent corpus instead of a pile of incompatible tool calls.

Three moves do the shrinking, and they are worth naming because they're the opposite of how tool catalogs usually grow:

Delete a compound, add a universal. [sense:pew_research] (one hardcoded URL) retired in favor of [sense:feed]{url} — the dictionary is net −1 +1, but the possibility space grew to any feed, and a duplicate parser collapsed.
Fold same-shaped words onto an axis. Five search verbs became [sense:search]{source}; four business-ledger verbs became [self:ledger]{store, op}. The axis has to be honest, though: contacts got folded into [others:neighbor]{op} rather than [self:ledger]{store:"contact"}, because store is the axis of peer ledgers and contacts are a child collection — putting them there would have made the axis start lying.
Procedures aren't words; they're sentences. Anything that's only an ordering of existing verbs gets frozen as a registered script ([self:script]) or an app instance instead of a new verb. That makes "should I add a word for this?" default to no — an anti-vocabulary-inflation device built into the language.

Once a word is justified, implementation is still only half the job. description and ops.values put what exists into the catalog every agent reads; hippocampus examples (natural-language intent → IBL code) teach which phrasing should recall it and which arguments to use. Only arguments observed in the corpus and real executions become the catalog's ⟨args: …⟩ shape. A new capability is therefore complete only when body (handler), dictionary (catalog prose), textbook (corpus), and observation (argument/return shapes) close together. Description without examples is visible but hard to recall naturally; examples without a body cannot run.

One measurement lesson from that pass, since it generalizes: a call count is not a life sign. A retired action had 19 recorded calls and had never once returned a result — the count said "invoked", not "worked". The test that survived is to open the handler and measure the replacement path.

Here is what falls out of having a real language:

→ Three surfaces for every task (the trilemma)

Because there's a compile target, the same IBL expression can be reached three different ways. Each surface takes two of {speed, expressiveness, sovereignty} and gives up the third:

Surface	How you reach the IBL	Trade-off
Autopilot	A flagship model takes your intent and discovers the steps, emitting IBL as it goes. Best for new, exploratory work.	speed + expressiveness − sovereignty
Cockpit	A lightweight model translates natural language into IBL. You statically check it, review effects, and run it; system state, model gear, run history, and supervisory intervention live here too.	expressiveness + sovereignty − speed
App	An icon invokes a fixed IBL expression directly — 0 tokens, deterministic. Fastest, most discoverable.	speed + sovereignty − expressiveness

No other harness can offer this, because no other harness has a compile target: there is nothing for the Cockpit to translate into, no stable expression to check, and nothing for an icon to invoke. The three surfaces are not a UI menu — they are a property of having a language.

→ Crystallization

Frequency moves a task between surfaces. Autopilot explores it once → its IBL trace seeds the Cockpit → a proven, high-frequency flow crystallizes into an App icon (0 tokens) on a 2D desktop you own and return to. A saved shortcut is not the same as an icon you keep — the difference is placement, and most harnesses have no launcher surface at all, so a proven flow has nowhere to live. This survives cheaper models: what you want from a daily task isn't a lower token bill — it's determinism, instant response, and control. Crystallize only what's proven.

(The Cockpit obeys two rules: side-effecting steps are gated behind explicit confirmation while read-only steps run friction-free, and the hippocampus learns only the results you approve. App instruments are declaration-driven — each is an app: block on an IBL action, and one declaration renders identically on the desktop, the remote launcher, and the phone.)

→ The place you work is an app too — documents, spreadsheets, code

Frozen IBL calls are not the only thing on the App surface. Three workspaces open as their own windows, where you and the AI handle the same file or repository in the same place:

Documents — edit DOCX, ODT, RTF and PDF in their original format (a local ONLYOFFICE editing server), and HWP/HWPX in theirs (a local open-source engine that makes no external font requests). Rotate, delete and reorder PDF pages; correct OCR and save a searchable copy; preview and export Markdown and source documents.
Spreadsheets — workbook editing, CSV/TSV import that doesn't mangle identifiers, phone numbers or text that merely looks like a formula, format-conversion copies, printable forms, and tables that flow from a pinned sheet snapshot into a document report.
Coding — open a repository and each task gets its own isolated workspace; an executor (a native CLI such as Codex, or a plain API model — swappable) makes the change, then it closes through verification command → diff review → approval → apply and commit.

One rule ties the three together: the engine only writes drafts; only your explicit save replaces the original. If the original changed underneath you, the save is refused; a late save from an editor window you already closed is dropped; versions and drafts can be restored. An AI proposal is bound to the selection you saw on screen and arrives as a tracked change — it never quietly rewrites the file. And no new vocabulary was added for any of it: agents join the same editing session through the self:document and self:sheet actions that already existed.

(The honest scope: the editing engines listen only inside your own PC, so original-format editing is desktop-only, and the Coding app's write boundary is currently guaranteed on macOS only. What is still unfinished — full fidelity on complex Hancom documents, for one — is written down as-is under "implementation status" in docs/DOCUMENT_APP_DESIGN_2026_10_02.md, SPREADSHEET_APP_DESIGN_2026_10_02.md and CODING_APP_DESIGN_2026_10_02.md.)

→ A currency algebra

The table node carries domain-agnostic transformers — filter / sort / take / select / compute / dedup / groupby / join / union / merge / rename / flatten. Lists and records flow as explicit values, and emitters (chart / spreadsheet / document / structure) turn those values into artifacts. Any search result can therefore compose through >> without glue code:

$rows = [{id:"a",score:3},{id:"b",score:7},{id:"c",score:5}]
$rows >> [table:filter]{where:($row)=>$row.score>=5} >> [table:sort]{by:"score",descending:true} >> [table:select]{columns:["id","score"]}

Coverage is the nouns; depth is the currency verbs. A language with an algebra is what turns a search into a report.

→ Sentences, not just pipes

A pipe can only say "then". Real requests also say "for each of those", "only if", and "keep at it until". Current IBL expresses these as values, expressions, and blocks, not sentence strings or implicit slots:

[table:each] { … } receives each input row as $it and $i. mode:"map" returns one result per input, flat_map flattens one level, and effect returns no value; parallel still preserves output order.
Blocks — [if:Bool expression] { … } [else] { … }, [case:expression] { … }, [repeat:…] { … }, and [try] { … } [catch] { … } [finally] { … }. Conditions, arguments, and callbacks share one expression language, and an undecidable value is never guessed to be false.

Adding grammar exposed a useful failure class: places where the system couldn't tell and reported something definite anyway. Those became explicit failures, and the pattern is now deliberate: anywhere there is a fallback branch, check whether "I don't know" is being rendered as "no".

→ One sentence, one program

The current grammar treats explicit values, functions, repetition, and failure as one system. A newly saved program begins with #!ibl edition=2, and check:true runs the same compiler without effects before execution:

Values — a list is always a list; it has no virtual .items. Only a tool that declares a Record result is projected through fields such as .items or .text. String interpolation is explicit as f"${value}".
Functions — define [def:name]($first,$optional=default){…} and call [fn:name]{optional:value}. The first argument is the pipe slot; free variables and recursion are rejected.
Failure and repetition — sequential execution stops on failure. Recovery is written with try/catch; per-item failures become values only through each{on_error:"collect"} and Result. Repetition explicitly states a count, while, or until condition.
Evidence and resume — values, source completeness, and evidence remain separate. Large results are read by reference, and an interrupted run resumes with resume:{run_id} plus the same code and inputs, without repeating completed external work.

The line is deliberate: domain procedures still freeze into registered scripts ([self:script]) or reusable functions rather than multiplying vocabulary.

Saved programs use that same function contract. A checked definition is stored through [self:workflow]{op:"save",edition:2,code:...} and called as [fn:name]{argument:value}. Compatibility adapters preserve old stored programs, but there is only one writing language for new code. data/system_docs/ibl.md and data/guides/ibl_composition.md are the authoritative contract and examples.

→ Publishing to the open web, at personal scale

The same language that runs a private action can also expose one to the public internet. A small family of others actions turns an IBL flow into a real web address anyone can open — no server to rent, no framework to deploy:

[others:portal] — personal portals at /h/<slug>/: give family, friends, or neighbors a login and a level (0 guest → 4 family), and they borrow your instruments and content through the browser, without installing anything. Members are your neighbor CRM, unified — no separate account system.
[others:family_news] — a family newspaper at /n/<slug>/, typeset from your phone's photos, with a guestbook and photo uploads.
[others:bulletin] — login-free bulletin boards at /b/<slug>/; anyone with the address posts text and photos.
[others:showcase] — public file shares at /s/<slug>/, served straight off your disk.
report faces at /r/<slug>/ — a recurring-report folder rendered to HTML on view, so a fresh report every morning never needs a fresh link. (Configuration only, no verb of its own.) Separately, [others:publish] pushes a piece you wrote out as a Nostr long-form article (NIP-23) and hands back a shareable link.

This is the first step of the larger vision — individually raised systems finding each other. The principle is "one node per community": your system is the node, and the people around you are browsers reaching it, speaking the same language from the outside.

→ The shared warehouse — the node's front door

If the surfaces above are destinations you make, the front door — the node itself having an address, with its publishing folders, level gate, machine face, neighbor feed, and reposts — is covered at the top of this README. One thing belongs here, from the language's point of view: all of it cost IBL zero new verbs. Publishing composes out of vocabulary that already existed (self:copy, table:document, self:delete); the outermost discovery ring — a Nostr profile whose website is your warehouse, plus an #IndieNet note carrying only a greeting and the address — is [self:ledger]{store: "document", op: "publish"}. A stranger finds you on an open relay, then reads you out of your own warehouse.

Core #2 — A clean seam between the vocabulary and the body

A capability's meaning ([sense:here] = "where am I?") is body-independent; how it runs depends on the machine. Keep those two apart with a clean seam, and a second consequence falls out.

→ One verb, three questions: what, which body, which surface

Three questions look like one and are not. What does this mean? [limbs:radio]{op: "play"} means "play this station" everywhere. Which machine can do it? Only one with speakers, or a camera, or the disk holding your files. Where should the result land? Wherever you happen to be looking. Collapse any two of those and you get a system that quietly does the wrong thing on the right machine.

The seam keeps them apart. runs_on tags mark each action honestly — anywhere, or bound to a machine that actually has the capability. Nothing in the vocabulary names a brand: your hub can be a Mac or a Windows PC (the tag is pc_only, meaning compute-class, not macOS), and an action that reaches for a camera says camera, not phone. The senses that are inherently indexical — where am I, what do I see, what do I hear — mean the same thing on every body; only the answering differs, and a body without the hardware says so instead of guessing.

→ Bodies with separate dictionaries, talking by calling card

The seam cuts one layer deeper than "which machine runs it": each installed body owns only its own vocabulary. The distribution ships the whole dictionary; an install keeps what it actually has, and both the action catalog and the hippocampus filter for ownership — you don't learn someone else's words. (What a body "has" is not a folder but a per-body activation ledger over the full dictionary it holds — see What's core vs what's yours.)

So how does one body get another to do something? Not with a privileged pipe. Each body serves a calling card (GET /nodes/card) — a description-only projection of what it can do, exchanged automatically when bodies register each other, ~70 tokens of scent. Then one body simply asks in plain language ([others:ask]): the receiving body compiles the request with its own dictionary, runs it, and returns the result — or honestly declines if the words aren't in its vocabulary. Nothing imitates the other side's action names, so neither body has to know the other's dictionary.

What makes a body special isn't wiring, it's rank: bodies are neighbors in the same CRM, at a level you granted. Your phone is simply your highest-level neighbor, and a stranger's ask is refused by the same gate that governs everyone else. ([others:delegate] hands work to a persona; [others:ask] asks a body for a capability.)

And a body can be temporary: plug a USB stick into an unfamiliar PC and it becomes a thin limb for as long as you want ([self:limb] issues, [limbs:guestpc] commands). The brain and the identity stay on your hub — the stick carries one revocable limb key, never your password — and the little helper dials out to your hub, so nothing on that PC's firewall has to change.

The third question is the surface, and it is genuinely separate. Press play in the desktop launcher and the sound comes out of that machine. Press the same instrument in a browser on your phone and it plays there — because the request carries which surface asked, not which machine executed. One line of IBL, no branch in the declaration that renders it. The same axis sends a download to the device in your hand while the work happened on the hub, and sends the clipboard the other way.

The seam also splits memory cleanly: your world-data (contacts, business, calendar, health) is shared and synced (CRDT union merge), while each body's subjective memory (conversations, hippocampus, self-state) stays private.

The split mind — define the problem, then execute it

Most systems plan and act as a single agent. IndieBiz OS separates problem framing, execution, supervision, and evaluation into distinct roles:

User message
   ↓ association: hippocampus + deep memory
   ↓ reflex: EXECUTE or THINK
   ↓ world map: a small clue-set of relevant names, methods, and tools
   ├─ EXECUTE/reflex → direct execution → finish
   └─ THINK → consciousness defines the problem and achievement criteria
                    ↓
                 executor
                    ↔ consciousness supervises only when needed
                    ↓
        tool-free final evaluation → at most one minimal repair
                    ↓
     after delivery, select durable execution/relational/spatial memory

The two branches do not validate in the same way. Only THINK has achievement criteria authored by consciousness, and the final evaluator judges only those criteria. If they are unmet, all identified defects are handed back together for at most one repair, followed by evaluation against the same criteria. EXECUTE and reflex add no evaluator call to a normal short lookup. A NULL episode evaluation therefore means “not evaluated,” not failure; UNKNOWN means the criteria could not be decided from the available evidence.

The consciousness agent reframes the raw request into a well-defined problem before the executor ever sees it. Because the two are different subjects, the executor solves an already-framed problem: the off-target or unsafe paths a single plan-then-act agent would have to consider and reject are largely kept out of its frame from the start. This is containment, not alignment — safety dissolved into the goal rather than bolted on as a rule. And it's a property a single agent cannot have, because it cannot un-ask its own question — which is exactly why a more capable reasoning model doesn't absorb it.

Three model tiers serve this cheaply — lightweight, midtier, full — but which tier each cognitive role uses isn't hardwired. An automatic transmission (the unconscious classifier) already picks a tier per task; on top of it sits a manual gear lever (Save / Balance / Max) that shifts the whole system at once, the way a car's gearbox does. The four cognitive axes — classify, evaluate, execute, consciousness — each map to a tier through the chosen gear, so one lever rebalances cost vs. quality across the entire mind without restarting. (Models — and their API keys — flow from the gear, not from any per-agent setting.)

Memories that learn you — and your spaces

Several memories learn from you automatically and keep themselves clean:

Hippocampus (procedural) — a fine-tuned 768-dim embedding model maps your natural language to past IBL code (retrained locally on Apple Silicon whenever the corpus grows; the current generation's Top-5 scores and corpus size live in the hippocampus table of data/system_docs/memory.md). Successful runs distill into reusable examples, so the system gets faster at your recurring tasks. A closed loop records whether a recalled example actually worked, so proven patterns rise and bad ones sink.
Deep memory (relational) — after each conversation a lightweight pass extracts durable facts about you (preferences, decisions, key dates) and recalls them, with their last-seen date, when relevant.
Forager memory (spatial) — every time the AI forages the disk, web, or codebase, it accumulates what it learned about that space across sessions: folder identities, search conventions, dead ends, and an owner-model of whose files live where. A model built foraging the disk disambiguates a web search, and vice versa — a compounding loop. It borrows the vocabulary of Information Foraging Theory; what's new is treating it as the persistent faculty a stateless model lacks, and adding only that memory — no controller, no stopping-formula. ([self:forage], the Mac self.)
World map (knowledge cues) — a structured vocabulary catalog pointing toward what the AI already knows and what it can look up. It supplies a small set of relevant fields, names, and problem–method–tool relations while leaving the knowledge itself in models and primary sources. Every working agent selects one relevant fragment, surfacing otherwise unmentioned methods without forcing alternatives that change the user's goal.

A periodic consolidation pass (part of the immune patrol below) merges near-duplicates, prunes stale or proven-bad entries, and resolves contradictions, so memory stays sharp instead of bloating. Long-term writes happen after the final response is delivered, in one pass that selects only durable value from the user's original words; saving nothing is a normal outcome.

The system watches itself

World Pulse — hourly: economy, weather, news (every 6h), user activity, system health.
Self-Check — once a day, a deterministic sweep: static consistency, a currency probe over every action's fixture, and a set of golden pipelines (no model calls — the AI patrol it replaced was retired). On /self-inspect, the system AI retries failures to classify them transient vs reproducible and rate fix difficulty (easy / medium / hard).
Commit-time guards — the checks that hold the vocabulary together (a three-way match between source, tool schema, and handler) were extended to the seams — the things that aren't actions: an auth gate that fails closed rather than open, a check that every publicly-exposed route really has its own gate (the oracle is the live route table, not a re-parsed list), a scan for blocking calls inside async code (this server calls itself often enough that a blocked loop is a self-deadlock), a Unix-only-import scan for Windows portability, and a fresh-clone CI — because main once passed only on the machine that wrote it.
Boot observability — the subsystems a server may start without are wrapped in "log it and carry on" blocks, which is correct; the problem is that three days later the answer to "why did nothing get scheduled?" is somewhere off the top of a terminal. Every one of those blocks is now instrumented, and a failed boot step shows up in the health endpoint.
Self-repair — when you tell it to, the system fixes its own code. Not on top of its living self, though. Every change is made in an isolated working copy, and only the exact bytes that passed the relevant checks in that copy are applied to the canonical tree. Applying, restarting, and rolling back on failure belong to a restart controller that lives outside the backend — a step that must run after your own death belongs to a process that outlives it. There is no fallback that writes to the canonical tree when isolation fails. Facts a machine can verify (real test reports, candidate and environment fingerprints) are no longer re-approved by another AI reading prose; the evaluator is asked only where a judgement of meaning is needed. The authority is bound to the one run a person commanded: schedules, delegation chains and external channels never get it, and another run under the same agent name cannot borrow it.
Prompt composition — the system runs many kinds of LLM agent (system AI, project agents, consciousness and its supervisor, the unconscious classifier, the evaluator, the experience distiller, the IBL translator …) and each assembles its prompt differently. A Prompt composition window in the launcher's glasses (logo) menu shows, per agent, the assembly as layers — system prompt / turn context / user message — piece by piece with source, condition and size; the variable pieces (execution memory, IBL environment, project memory, world state) are produced by running the real builders on one sample message, so the sizes are actual (embedding search only, no model call). Its sibling Guide files window lists every guide in data/guides/ with its registration, freshness and budget marks, and lets you read and edit them in place.

Agents you design, teams that delegate

You don't just say "act as a doctor" — you define who an agent is and how it communicates, and it remembers your context (medications, preferences, past conversations):

agents:
  dr_kim:
    role: |
      You are Dr. Kim, an internal-medicine specialist of 20 years.
      You acknowledge the patient's concern before asking questions,
      explain terms in everyday language, and always end with clear next steps.
    allowed_nodes: [sense, self, limbs, others, engines]

You define who an agent is, not which model runs it — model and API key are decided centrally by the gear lever above (with an optional per-agent pin to override one agent's tier). Agents form teams and delegate — synchronously (call_agent, wait for the result), on a schedule (hand a task to another agent's clock), or via a written plan (create_plan → execute_plan, each agent runs its part and hands off). Agents with a communication channel (Nostr, Gmail) can take orders remotely and reach other people's agents over IndieNet (Nostr; DMs use modern NIP-17 gift-wrap encryption).

Under the hood (reference)

6 nodes, 178 composable actions — one tool (execute_ibl), one vocabulary, not 178 schemas:

Node	Actions	What lives here
sense	43	Retrieval — web/news search (one verb, `source`-branched), any RSS/Atom feed, finance, real estate (official prices + live listings), accommodation, second-hand markets, freelance marketplaces, legal, statistics, classic literature, performances, academic papers/dissertations/researchers, entity resolution (Wikidata), AI grants & contests — plus the indexical senses each body answers its own way (notifications, location, mic, camera; no hardware → an honest `no_hardware`, never a guess)
self	59	System management, workflows, triggers, goals, files (read/write/edit/fill, plus surgical edits to a live spreadsheet), deep + forager memory, ledgers (business catalog, personal/company finance, health records), grounded Q&A over your own document piles, registered scripts, phone sync, my music library, USB-limb issuance, the web-app registry, slides & decks, library install (approval-gated)
limbs	14	UI automation (browser, Android, desktop screen), phone-native actions, a guest PC reached by USB limb, media playback (YouTube, radio), window opening, maps
others	20	Collaboration, delegation, asking another body in plain language, messaging (DM/feed/board/Nostr NIP-17), neighbor CRM (contacts are ops on a neighbor — a warehouse address is just another contact type), auto-response — and the public-web surfaces others can reach: personal portals, family newspaper, login-free bulletin boards, public file shares
engines	19	Pure media generation — images (generate + vision read/critique), icons, the morning newspaper, websites, web components, TTS. Slides and video moved to `self` in the 2026-08 consolidation
table	23	Currency algebra — transformers (filter/sort/take/select/dedup/groupby/join/union/merge/rename/flatten), the higher-order `each`, and emitters (chart/spreadsheet/document/structure). Split out of `engines` so the grammar survives even when heavy media generation is off

IBL's definition lives in a single source of truth (data/ibl_nodes_src/, built to data/ibl_nodes.yaml via scripts/build_ibl_nodes.py), and a commit-time check matches source ↔ tool schema ↔ handler three ways. Tool packages (51 installed, plus 5 backend core modules) are folders — drop one in and it's recognized, independent of the language; an AI agent can build, install, or modify them for you. Per-agent allowed_nodes restricts what each agent can reach.

(The numbers in this section are regenerated from the registry by scripts/build_ibl_nodes.py — don't edit them by hand.)

Getting started (recommended)

The easiest way to install IndieBiz OS is through Claude Desktop.

Open Claude Desktop and switch to the Claude Code tab.
Tell Claude:

"Install IndieBiz OS from https://github.com/kangkukjin/indiebizOS on my PC"

Claude clones the repo, installs dependencies (Python, Node.js), asks about your needs, and sets up a system tailored to you.

Why Claude Desktop? IndieBiz OS is a living system, not a static npm install. The agent that installs it becomes the blacksmith who keeps forging it to fit you.

You'll provide: an LLM API key (Anthropic, Google, or OpenAI) — or a Claude Code / Codex subscription login, which needs no key; answers to a few questions about what you want; external API keys only as you actually use those features. To also turn on the public surfaces — Shared Warehouse, remote access — you'll additionally need a Cloudflare account + your own domain; the full setup map is in the Getting Started guide.

Alternative: download the desktop app (no Claude Desktop)

Don't have Claude Desktop? Download a prebuilt desktop app. It bundles everything (Python, Node, all runtimes) inside the app, so nothing has to be installed on your machine and installing costs nothing — you just enter your own AI API key (Anthropic / Google / OpenAI) on first launch.

Get it from the app-latest release:

macOS (Apple Silicon): IndieBiz-*-arm64.dmg
macOS (Intel): IndieBiz-*-x64.dmg
Windows: IndieBiz-Setup-*.exe

Open the .dmg and drag IndieBiz into Applications (macOS), or run the installer (Windows). The apps aren't code-signed yet, so the first launch may need right-click → Open on macOS, or More info → Run anyway on Windows SmartScreen.

Language: the AI replies in whatever language you write to it, so no setting is needed. The interface language is chosen in the launcher (한국어 · English · 日本語). Korean is the source and the others are generated at build time and shown offline — interface text is never sent anywhere for translation at runtime, and your conversations, file names and inputs are not translated at all. Adding a language is one line in frontend/i18n/languages.json. (The bundled guide documents are currently Korean.)

The canonical path: source install (macOS · Windows · Linux)

This is the canonical install path — CI verifies this exact recipe on all three OSes on every push (clone → bootstrap → boot → /health 200). The Claude Desktop path and the desktop app are both wrappers around it.

git clone https://github.com/kangkukjin/indiebizOS.git
cd indiebizOS
python3 scripts/bootstrap.py     # Windows: py scripts\bootstrap.py
python3 scripts/update.py        # upgrade later (keeps your package on/off choices across git pull)

The bootstrap creates .venv (auto-selecting Python 3.10–3.13), installs backend dependencies (core strictly; tools and semantic-memory extras best-effort — without the latter, recall degrades to keyword search), seeds .env from .env.example (put your LLM API key there), and installs the Electron desktop UI if npm is present — backend-only otherwise (remote launcher/REST still work).

Optional dependency: LibreOffice — needed only for ledger (xlsx) rendering with formula recalculation ([engines:render]{op:"xlsx"}): macOS brew install --cask libreoffice / Linux apt install libreoffice-calc / Windows official installer. Without it, only that feature fails — honestly, with the install hint.

Run:

./start.sh                              # macOS/Linux (backend + desktop UI)

Windows: .venv\Scripts\python.exe backend\api.py

You configure agents, packages, and preferences yourself on this path. The Claude Desktop path is more comfortable because the AI handles all of it for you.

What's core vs what's yours

IndieBiz OS ships a standard core — the IBL grammar, the function-word nodes, the backend/frontend engine, and a catalog of tool packages and apps — but the moment you install it, it becomes your instance. You add vocabulary, install or author apps, accumulate conversations and settings. The line between the two is a single source of truth: data/core_manifest.json, derived from what's committed to the repo (scripts/build_core_manifest.py), so nothing has to be hand-tagged.

Two guarantees follow:

Install doesn't dump everything on you. Many packages need their own API keys; installing them all would bury you in things you can't use. The whole catalog ships, but only a curated set is active by default — the rest sit available, ready to switch on when you want them. Since 2026-09 that switch is a per-body activation ledger over the full dictionary you hold: waking or putting a word bundle to sleep changes the ledger and the prompt cache, never a folder or a rebuild, and a sleeping bundle keeps its files, settings, examples and vectors. You do it in My vocabulary (launcher glasses menu, right under Settings) — an icon desktop where bundles sit in folders, a storage vault, and a trash — and a bundle travels as a single .iblpack file: import through the vault, export from the bundle's own menu; an imported bundle arrives asleep and runs only once you wake it (format: docs/IBLPACK_FORMAT.md). Every package carries an origin (core / user), and the desktop-app packaging is built from the manifest, so your own committed apps and personal files never leak into a distribution. (Committing a personal package for backup? Mark it origin: user and it stays out of the core.)
Updates never overwrite what's yours. A reinstall or update refreshes only core-owned files. Which packages you've turned on or off, the vocabulary and apps you authored, your settings, and your conversation history all survive untouched — the updater respects the folder placement you chose rather than re-imposing the bundle's defaults.

This is the same substrate/superstructure seam that separates the standard grammar from your personal dictionary — pushed all the way out to packages, apps, install, and update.

Technical Stack

Backend: Python FastAPI (port 8765)
Frontend: Electron + React (TypeScript)
AI Providers: Anthropic (Claude), Google (Gemini), OpenAI (GPT), DeepSeek, OpenRouter, Ollama (local) — plus two subscription-login CLI harnesses, Claude Code and Codex, that need no API key (Codex's model and reasoning effort are picked from the installed Codex's own model catalog, so new models appear without a code change)
Database: SQLite
Document engines (optional): ONLYOFFICE Docs (a local container, published on this PC's loopback only) for original-format office documents and spreadsheets · RHWP for HWP/HWPX · Tesseract for OCR. The system starts without them; only those editing features are off.
Deployment: Local-first, optional Cloudflare Tunnel for remote access

Running

# Development mode
./start.sh

# Or separately
cd backend && python3 api.py        # Backend (port 8765)
cd frontend && npm run electron:dev  # Frontend (Electron)

start.sh runs the backend through the repo's .venv only (create it with python3 scripts/bootstrap.py; there is no silent fallback to system Python). backend/api.py is the restart controller: start is the default action, and status / restart --wait / shutdown --wait are the operating verbs.

Change history

The running record is git log and data/system_docs/changelog.log. The long documentation-update digests this README used to carry (2026-06 → 2026-10) are archived in docs/README_CHANGE_HISTORY.md.

IndieBiz OS — An AI system that grows with you, not one that's given to you.