The sovereign operating system for an AI-run estate

fall-os

One core. One conductor. An estate of 1,548 repositories that runs on hardware you own.

Every serious AI system today is rented: someone else's weights, someone else's datacenter, someone else's memory of your work. fall-os is the opposite bet, built to completion — a runtime where you direct a conductor in plain language, it runs on your own models, reasons over your own corpus, builds what you ask and proves it before it ships. Every agent carries a signed identity and a budget it cannot cross. Nothing leaves the machine unless you send it. This is not a prototype of that idea — it is an estate of 1,548 repositories already standing on it.

Play — own your Didy → Use the conductor now Explore the estate How it works ↓ Deck (PDF) ↓ Prospectus (PDF) ▶ The 90-second film
1,548 repositories in the estate 6-tier local-first model cascade 90/10 machine / human operating split 5 runtime modules, mutation-tested Ed25519 identity · bounded budgets offline · zero-dependency
Play it — become an estate

Download an empty Didy. Feed it your history. Level up into your own OS.

This whole page is one game and one save file. You hatch an empty Didy, give it your own past, and level it up through the estate's real systems — memory, verify, skin, budget, mesh — each one a zone inside here. Nothing installs, nothing uploads, and nothing links out: every organ is nested in this one page, and each level is a real capability your Didy earns.

your didynot hatched
level0
xp0
knows0
caps0

Every zone is a real, gated system in this one repo — the memory (seed.mjs, mutation gate 67/67) and the signed capability wallet (kard.mjs, 49/49) both run right here, offline. The Dreaming draws on dream-state design Gary W. Floyd shared with the estate: Gary W. Floyd, Lumiea Systems Research Division — ThunderStruck Service LLC, “Dream State Architecture: GEP-Guided Memory Consolidation and Entropy Regulation in Artificial Consciousness Systems,” 2025. fall-os is forked from Thomas Frumkin’s assos (ASSOSIGNITION), used with permission, and built on the Konomi architecture he created. fall-os’s own code is MIT-licensed; the cited works above remain their authors’ own.

Use it right now — nothing to install, nothing to sign up for

Everything below runs inside this tab, on your own input. No account, no key, no upload. Cut the network and it keeps working.

Network: on calls to any other server: 0this page’s own files: 0

Talk to the conductor

Type a real decision you are facing. The conductor runs its five phases over the shared core and hands you a scored field — it commits nothing until you author it.

Tier 0 · built in

Optional. Tier 0 above already works with nothing installed. Loading a model downloads it once from a public CDN — the only time bytes come in, and you will watch the counter move for it. After that it runs on your GPU in this tab, offline, and it only rewrites the stances in the words of your decision: it never changes the scores, the order or the gate. Nothing you type is ever uploaded.

EXPLORE RESOLVE VERIFY BUILD REMEMBER

What this is, honestly. With no model loaded, the conductor does not read your sentence — it finds signals it can name, and scores a fixed taxonomy of stances against them. Every score shows the cue word that produced it, and when it finds nothing it says so. That is tier 0 of the cascade: no key, no download, no network. Point it at your own model host or key and the higher tiers phrase these stances against your specific decision — the field, the gate and the shadow are this same code either way.

Open a real tool

Not a demo of a tool — the tool, running on your own data.

loading standards…

What it remembered

Authored builds, and the roads you did not take.

Built

    Shadow index — 0 held open

      What it is

      An operating system for running an AI-operated estate on hardware you own

      Cloud AI rents you intelligence by the token and keeps the memory. fall-os inverts that: the models run on your machine, the memory is a corpus you own, and the orchestration is a deterministic runtime you can audit line by line. The conductor is the interface — you talk to it the way you would talk to a coding agent, except the weights, the context, the history and the outputs are all yours.

      The interface

      A conductor you chat with

      One conversational surface over the whole estate. It plans, expands options, calls organs, writes code, and reports back. Frontier-model quality is an option you can switch on — not a dependency you are locked into.

      The substrate

      Your models, cascaded

      Six tiers, local first: built-in heuristics, in-browser models, your own Ollama host (e.g. Qwen 14B), then optional free and frontier APIs under your own key. Each request lands on the cheapest tier that can answer it.

      The estate

      1,548 repositories, one field

      Everything built is addressable as a single retrieval corpus — the estate is both the product and the context the conductor reasons over. Nothing about your work is uploaded to train someone else's model.

      Compression beats scale. You do not need their datacenter — you need the right compression and hardware you already own. The design thesis: an operating system that owns its own intelligence, rather than a client for someone else's cloud.
      What it does

      Direct it in plain language; it builds, verifies, and operates

      The conductor is a general-purpose operator over the estate. The same loop that designs a module also drafts a customer reply, reconciles a ledger, or schedules a turnover — because every one of those is an organ registered against the same core.

      Build

      Ask for a tool, get a verified tool

      Describe what you need. The conductor expands candidate implementations, generates code, and runs it through the gate. Anything that fails verification is discarded — it never reaches you as working software. Specifications that are never needed cost nothing to hold.

      Operate

      Run the work, not just the demo

      Trained organs already run real operations: multi-channel reservations with a double-booking guard, offline housekeeping across a multi-unit site, encrypted bookkeeping, cited legal drafting, unified inboxes and reply drafting. These are deployed systems, not mockups.

      Delegate

      A 90 / 10 operating split

      90 % machine execution, 10 % human judgement. The system does the work; the person sets direction and commits the decisions that matter. Consequential actions stay authored — the conductor proposes and prepares, a human commits — and autonomy is granted per organ, never assumed.

      Constrain

      Agents that cannot overspend

      Every agent holds an Ed25519 identity that is its capability and its budget ceiling. Overrun is impossible by construction, not by policy — an agent cannot spend what its signed grant does not contain, and every transfer is signed onto a hash-chained ledger.

      How it works

      One core, one conductor, an estate of organs

      A conductor runs a single control loop. Every phase of that loop calls one shared core. Organs — the tools, engines and applications — register against phases rather than reimplementing their own logic. Improving the core improves every organ simultaneously; that inheritance is the entire reason to build an OS rather than a toolkit.

      1 · The model cascade — local first, frontier optional

      Requests descend the cheapest capable tier. Your key hits your provider directly; there is no intermediary service, no shared inference endpoint, and no token metering by us.

      T0
      Built-in deterministic logic

      Kernels, templates and gates — answers that need no model at all.

      on-device · free
      T1
      In-browser model (WebLLM)

      A small model running in the page itself. No install, no server, works offline.

      on-device · free
      T2
      Your local host (Ollama)

      Mid-size local models — e.g. Qwen 14B — served from your own machine over localhost.

      your hardware
      T2.5
      Large local / co-located

      Heavier local weights where the hardware allows, for work the mid tier cannot close.

      your hardware
      T3
      Free-tier APIs

      Optional external capacity for burst work, under your own account.

      opt-in · BYOK
      T4
      Frontier models

      Maximum capability on demand — used for the hardest reasoning, never required for the system to run.

      opt-in · BYOK

      Routing is a live component of the estate (fallrouter), not a diagram: it selects between a local Ollama host and frontier providers by task, quality and cost.

      2 · The control loop

      Every request the conductor accepts runs the same five phases, each implemented by the shared core.

      01ExploreExpand candidates at golden-angle offsets so options diverge instead of clustering on the obvious one.
      02ResolveScore every candidate against one shared acceptance threshold — the same bar in every organ.
      03VerifyRun proof — tests, gates, checks. Nothing is selected implicitly; commitment is authored.
      04BuildProduce the committed result and cache it by content, so identical work is never repeated.
      05RememberRecord the decision and index every alternative not taken, with a recurrence count.

      3 · The estate is the context

      Conventional assistants forget between sessions and rent you back a summary. Here, the estate's repositories are treated as a single addressable field: content-signed, graph-indexed, and retrievable by the conductor at reasoning time. Prior sessions are converted from dead exports into live memory; overnight consolidation reorganises what was learned without retraining any weights. Your corpus stays yours — it is context, not training data for a vendor.

      Field

      the wisp

      Points at the whole estate as one substrate — roughly a thousand repositories treated as a single retrievable field.

      Graph

      estate-nest

      The estate nested into an addressable memory: signed by content, organised into chambers, traversed by typed edges.

      Recall

      fall-remember · offramp

      Persistent memory plus a pipeline that turns dead chat exports into live, queryable recall.

      4 · The runtime modules

      ModuleResponsibilityMutation gate
      core.mjsThe shared engine: golden-offset expansion, the acceptance gate, deliberate commitment, content-addressed cache.10/12 · clean
      didy.mjsThe conductor: the five-phase control loop, the organ registry, grounded commitment.17/17 · clean
      shadow.mjsThe not-taken index: content-addresses discarded options, deduplicates across decisions, ranks by recurrence.10/10 · clean
      wire.mjsAdapters registering existing engines as organs without rewriting them.16/16 · clean
      depth.mjsSearch-depth control: how far the conductor expands before it resolves.8/8 · clean

      The conductor is generic and trainable. A fresh instance ships blank as didy; registering organs and signing it with an owner prefix produces a <prefix>-didy — a named instance on the lineage. The reference instance for this estate is private.

      The runtime

      All of it runs in a browser tab

      Not a marketing simplification — a hard architectural constraint the whole estate is held to. A tool is a single file you open. There is no installer, no server to provision, no container, no account. It works offline, it works on a phone, and it works on hardware a decade old. The browser has quietly become a complete operating environment, and almost nobody builds as if that were true.

      Cryptography

      Real signatures, no server

      Ed25519 keypairs, signing and verification run natively in the page. Agent identity, signed transfers and tamper-evident ledgers work with nothing behind them.

      Peer to peer

      Devices talk directly

      Browser-native peer connections let machines reconcile with each other rather than through a vendor's server — built on Konomi peer-to-peer (kp2p), Thomas Frumkin's work.

      Compute

      Near-native speed

      Compiled modules run in the tab, so signal processing, simulation and search execute locally instead of being shipped to a datacenter and billed back to you.

      Storage

      Your data, on your device

      Structured local storage holds the working set. Nothing is uploaded to be useful, and the tool keeps working with the network switched off.

      Audio & signal

      The machine can hear

      Real-time audio in the page is enough to diagnose a structure by its ring, sonify a system's health, and even pass work between machines as sound.

      Offline

      Installs like an app, isn't one

      Service workers make a tab a durable application — add it to a home screen, lose signal entirely, keep working. The file is the product.

      This is why the estate can be a hundred separate tools and still cost nothing to distribute: shipping is publishing a file. It is also why sovereignty is achievable rather than aspirational — if the tool never needed a server, there is no server holding your data.

      The trust rail

      Nothing ships on a claim; everything ships on a proof

      An assistant that writes code is only useful if you can tell whether the code is correct. fall-os treats verification as infrastructure rather than etiquette — the same gate that guards the runtime guards anything the conductor builds.

      Mutation gate

      witness

      Alters one operator at a time and requires the test suite to catch it. A passing suite is necessary but not sufficient — this proves the tests actually constrain behaviour. Runs in CI on every push, packaged as a GitHub Action any repository can adopt.

      Rubric

      acg-assessor

      Deterministic structural assessment of a codebase — reproducible scoring rather than model opinion.

      Reputation

      proof-of-play · earned

      Capability must be demonstrated against a pinned artifact and a canonical grader. A self-graded claim dies on re-grade, so reputation cannot be asserted into existence.

      Determinism

      Reproducible by construction

      No wall-clock and no randomness in the kernels. Identical inputs produce byte-identical output; content addressing makes repeated work free and makes every artifact citable by hash.

      Identity

      Signed by construction

      Ed25519 throughout: agent passports, signed transfers on a hash-chained ledger, signed content, and fork-lineage as identity. Provenance is verifiable without a registry service.

      The ecosystem

      One runtime beneath an estate of sovereign builds

      fall-os is not a single application. It is the runtime under a large body of self-hosted work — each build an organ that owns its logic, runs offline, and carries its own verification. The load-bearing organs, by faculty:

      1,548repositories
      1,503public
      45private
      101live builds, link-verified

      Private estate · 45 repositories

      A closed subset held privately — foundational architecture and research, the reference conductor and governance internals, mesh internals, and sensitive tooling. Not listed individually; details and access are available on enquiry (enquiries welcome). In summary, by area:

      Architecture & research 10 Conductor & governance internals 7 Agent & OS internals 7 Mesh & transport internals 5 Legal tooling 2 Other private tooling 14

      The organs above are the load-bearing ones, not the full set — the estate spans 1,548 repositories. A green marker denotes a live hosted build; a grey marker, a source repository.

      See it run

      The engine, live

      This is the actual module the tests verify, running in your browser. Choose a search mode: the core expands candidates on the golden offset, scores them against the acceptance threshold (dashed ring), and holds the field open. Nothing commits until you author it — and every option you pass over is recorded, so the alternatives you keep revisiting surface on their own.

      Above threshold

        Not taken · recorded

          Recurrence index

            Lineage

            Origins & acknowledgements

            fall-os consolidates ideas developed across a longer line of work rather than inventing them wholesale.

            Design line

            The assos line

            fall-os shares the governing principle of the assos line of sovereign systems: a system owns its own logic, runs self-contained and offline, and carries its own verification — no external service is required to trust it.

            Foundational work

            Thomas Frumkin

            The foundations are his: the assos line, the Konomi standard and its fold architecture, Konomi peer-to-peer, the Regulus engine, the guild discipline behind the estate's rubric, and the substrate contribution settles onto (github.com/teslasolar).

            Author & maintainer

            The estate

            Designed, implemented and maintained under sjgant80-hub, with mutation-tested verification on every change.

            FAQ

            Frequently asked questions

            What is fall-os, in one paragraph?

            A sovereign operating system for an AI-run estate. You direct a conductor in plain language; it runs on your own models through a local-first cascade (escalating to a frontier API only if you allow it), builds and verifies software, and operates trained organs across an estate of 1,548 repositories. Every agent has a signed identity and a hard budget; every build must pass a mutation gate. It runs offline on hardware you already own.

            How is this different from using a cloud AI assistant?

            Three structural differences. Location: inference defaults to your machine, and external calls are opt-in under your own key — there is no intermediary service. Memory: your estate is the context, indexed and owned locally, rather than a vendor-held history. Verification: generated code passes a deterministic mutation gate before it counts as working, instead of being trusted because it looks plausible.

            Do I need a GPU or a datacenter?

            No. The design thesis is that compression and orchestration beat raw scale: the lowest tiers are deterministic logic and a small in-browser model, which need no dedicated hardware at all. A mid-size local model (for example Qwen 14B via Ollama) raises quality substantially on ordinary hardware, and frontier capability remains available on demand without ever becoming a dependency.

            What is the model cascade, exactly?

            Six tiers, cheapest-capable first: built-in deterministic logic; an in-browser model; your local Ollama host; larger local weights where hardware allows; optional free-tier APIs; and optional frontier models. Keys are yours and hit your provider directly. Routing between local and frontier by task, quality and cost is a live component of the estate rather than a plan.

            Can it really run a business?

            It already runs parts of several. Deployed organs handle multi-channel reservations with a double-booking guard, offline housekeeping across a multi-unit site, encrypted bookkeeping, cited legal drafting, and unified inbox with reply drafting. The intended operating split is roughly 90 % machine execution to 10 % human judgement — with consequential actions authored by a person and each organ's autonomy granted explicitly, not assumed.

            What stops an agent going rogue or running up a bill?

            Structure, not policy. An agent's Ed25519 identity is its capability grant and its budget ceiling — it cannot spend beyond what its signed grant contains, and every transfer is signed onto a hash-chained, conserved ledger. Separately, the conductor never commits implicitly: it prepares and proposes, and an author commits.

            Are my repositories used as training data?

            They are used as your context, not as anyone's training corpus. The estate is indexed locally — content-signed, graph-organised, retrievable at reasoning time — so the conductor reasons over your own work. Nothing is uploaded to train a third-party model, and the memory layer consolidates what has been learned without retraining any weights.

            What is the acceptance threshold?

            Scores are normalised to [0, 1]; a candidate is accepted at or above a fixed hold threshold and rejected below it. Using one shared threshold across every organ is the point — acceptance behaves consistently system-wide, and raising the bar is a single change in a single place rather than an audit of every tool.

            Why the golden-angle offset?

            Candidates are generated at successive multiples of ≈137.5°, which yields near-uniform, low-overlap coverage of the option space. Practically: successive proposals spread out instead of clustering around the first obvious answer, which is what you want when you are asking for genuinely different approaches.

            How is correctness actually enforced?

            Each module has a deterministic assertion suite plus a mutation gate that alters one operator at a time and requires the suite to detect it. Both run in CI on every push for all five runtime modules. Surviving mutants are either killed with a new test or recorded in a baseline as reviewed equivalents with a written rationale — so “clean” is a measured state, not a claim.

            What are the dependencies?

            None at runtime. Pure ES modules, no build step, no packages. The page you are reading imports the same source the tests verify, and works offline as a PWA. Node is used for the test suites and CI.

            Can I extend it, or adopt just one part?

            Yes to both. Register an organ against the core — supply how it expands candidates, how it scores them, and optionally how it commits — and the conductor calls it in the loop. Existing engines are adapted rather than rewritten. Individual components also stand alone: the mutation gate is a GitHub Action any repository can adopt today.