The system
A headless core on :8200, nine applications around it, and
one written contract — machine-checked in the test suite of seven of the ten, on
every run.
Thin shells render the same core, so the whole network can move from a PC to a server unchanged — Windows or Linux.
Shells
Desktop · Mobile · Browser — no business logic in the shell.
Dizzi-Core :8200
AI orchestrator · panel registry · MCP hub · health watch · Dizzi-ID single sign-on. Headless: it orchestrates; it never acts outward on its own.
Nine applications
Each a service with its own SQLite database and its own web interface. Each independently runnable. Independently sellable is what the export contract is for — the packaging tooling itself is not built yet.
packages/appkit · packages/ui-kit
Shared beneath everything: the contract, authentication, security, deletion proofs — and the design system.
What holds it together
The start page names the three in one line each. This is what each one actually commits to, including what it costs.
The core runs offline. Cloud services are opt-in connectors — switchable off at any time, always shown as an external step. That makes sync harder; I took that trade-off deliberately, because the data belongs on the machine that produced it.
One written app contract, ten applications built to it. Answer the contract and the dashboard picks the app up by itself; the assistant can reach it without a new integration, and nobody wires it up by hand.
Honesty is not a tone of voice here; it is a written rule the code has to obey: an unmeasured value is reported as unmeasured, never as a zero. The same rule governs this website.
The mechanism
Write the contract, and the app appears. A service that answers the mandatory endpoints registers itself in the dashboard and becomes reachable for the assistant — nobody wires it up by hand.
The contract is not a document that hopes to be followed. It is
machine-enforced: appkit/conformance.py runs inside the test
suite of seven of the ten. Creating’s core is not in this snapshot at
all; the core and the trading fleet carry their own test suites instead. The
specification says so itself — where the prose and the code disagree, the code
wins.
Measured against the written specification, nine of the ten meet the contract. The core — the hub that collects it — stays outside by design, on its own port.
/api/summary always answers HTTP 200; the state lives
in a status field (ok · leer ·
fehler), never in an error code and never in a fake zero./api/actions carries the human-in-the-loop flow:
propose → approve or reject. The AI never approves its own action./api/account/export and /api/account/loeschen
implement the data rights — both demand fresh re-authentication, both
fail closed./api/audit records every action that has an effect.# every application around the core GET /api/health heartbeat + contract version GET /api/manifest machine-readable identity GET /api/summary always 200, state in `status` GET /api/settings typed, strict, audited GET /api/account profile · tier · SSO state GET /api/vault names only, never values GET /api/audit every effect, logged POST /api/actions propose → human approves /mcp tool server for the assistant
docs/16_APP_VERTRAG_SPEC.md.Source: docs/16_APP_VERTRAG_SPEC.mdThe shared floor
One shared library instead of ten copies of the same idea. Authentication, CSP hardening, deletion proofs, security posture, the area canon. When the security model improves, it improves in every application that imports the library — nine of the ten today.
lokal → verifiziert → hochsicher.
Routes that require a tier refuse without one — 403, fail-closed.
Nothing is accidentally open.
Ed25519 with the algorithm pinned in the verifier, PKCE mandatory, single-use codes with a 60-second life, refresh rotation with family revocation on reuse, secrets stored hashed only.
Service secrets sit encrypted beside the app database. The HTTP surface returns names, never values — a backup leak does not become a credential leak.
The library itself is not published. Until 6 August 2026 the extract carried its code; the curated set that replaced it carries the contract the library has to satisfy, which is the part that can be argued with:
Between the apps
There is no central data lake. Every application keeps its own data, and hands over only through a written contract — nineteen of them, numbered and specified. The core relays; it listens and it logs.
The constraint is real and I accept it: local-first makes synchronisation harder, and a read-only relay is less convenient than a shared database would be. I took that trade on purpose. Data that never leaves its source cannot leak from somewhere it never was.
Cross-connection rule“Data stays at its source; the Core only relays read-only; anything with outside effect needs an explicit human approval step.”
Security posture
lokal_only by default — those contents never leave the
machine.The security concept itself is no longer published. It was in the extract until 6 August 2026 and was taken out on purpose: a document that lists what is not yet hardened is a map for whoever is looking for exactly that. Saying so is better than quietly dropping the link.
The interactive map shows all of it at once — layers, hand-over contracts, security posture. Self-contained, no external calls.
Open the system map Open the small mapGo deeper in the repository: docs/16 — the app contract· docs/26 — cross-connections· docs/37 — the strict-CSP recipe· docs/12 — the whole thing, no prior knowledge