The July notes were about receipts. The September work is about foundations. Everything that ran in July still runs — chat, private Max workflows, search, memory, voice, image generation, reminders, communications, the operator console. What changed is underneath: the estate now has a named architecture, a dedicated compute foundation built for it, and a migration that moves one product at a time with restore proof at every step.
This article is written as release notes. As always, the goal is to describe what is running without turning private infrastructure into public attack surface or publishing personal data.
Where the stack stands today
As of September 5, 2026 the platform registers 35 logical services across 49 manifest components — the services themselves plus the wrappers, proxies and edge pieces they depend on. In July those figures were 33 and 41.
Project Kaizen public-safe snapshot — September 5, 2026
Logical services: 35 (35/35 running)
Manifest components: 49
Compute foundation: dedicated Proxmox host, restore-proven
Services plane: Debian 13 VM, containerized products
Public lanes: KaizenAI Open (web), voice and SMS (phone)
Private lane: Max
Dashboard: protected AI Orchestrator Console
Migration: parity-first, one product at a time
Public boundary: no private memory, no device control, no internal tools,
no hardware or platform identity
Citadel
For most of its life this was "the homelab" — a Mac Studio, a NAS, a VPS, a pile of containers, and a lot of glue. That framing stopped being accurate. What exists now is a platform with defined layers, defined boundaries between products, and defined rules about what may talk to what.
Citadel is that platform. Project Kaizen is the AI product family that runs on it. So do the safety products, the home automation layer, and the communications path. Naming it mattered more than it sounds: once the platform had a name, it became possible to say precisely which parts are finished, which are being migrated, and which are still aspirational.
The architecture
The architecture is deliberately boring to read, which is the point. Seven layers, each with one job:
- Intelligence — think. Local models on Apple Silicon. Inference, speech to text, text to speech, image generation, and tool use, all resident on hardware that is physically here.
- Compute — build. Virtualized infrastructure. Application containers, Windows VMs, Linux services, and isolated environments — run machines, deploy services, keep them separated.
- Applications — work. The containerized product plane. Independent products that happen to integrate, rather than one monolith with delusions of modularity.
- Physical world — sense. Home Assistant and the device layer, reached over open standards — Z-Wave, Zigbee, Thread and Matter, MQTT.
- Durable state — remember. NAS-backed local storage, VM and application backups, restore artifacts, and tested restores, with an independent off-site encrypted copy.
- External reach — reach. Cloudflare tunnels and access policies. Protected origins with no direct exposure, authenticated links, and minimal public surface.
- Communications — communicate. Mail, monitoring, alerting and NOC operations, with authenticated provider APIs at the edge.
Four network classes cut across those layers — an internal platform network for product-to-product calls, a narrow ingress class for explicitly published endpoints, a private network per product, and an optional management class. A product that has no reason to reach another product cannot reach it. That is enforced by topology, not by convention.
Private by default. Open standards. Resilient. Observable. Modular. Transparent. Six principles, and the architecture is arranged so that violating one of them requires deliberate effort rather than a moment of inattention.
What shipped
A dedicated compute foundation
The largest piece of September work is a purpose-built compute host running Proxmox, with redundant networking, key-only operator access, local guest storage, NAS-backed backup storage, and snapshots. The milestone that mattered was not "it boots" — it was bootable restore proof: a guest destroyed and rebuilt from backup, verified working, before anything of consequence was moved onto it.
Alongside it runs a validated Debian 13 services VM carrying the containerized product plane, with Docker Engine and Compose, LAN-only container management, and a proxy alias for the home automation and radio services.
The migration plan, stated publicly
The migration is parity-first and runs one product at a time. Each product must reach functional parity on the new platform, pass an attended cutover, survive a monitored soak, and retain a stopped rollback on the original host before the next product starts. There are no calendar waits and no batch cutovers — the gate is evidence, not the clock.
Twelve mandatory roles have to reach production for the migration to be complete. As of publication, three are there: search, deep research, and memory now run as accepted production products on the services plane, each with exact-image verification, scoped secret delivery, writer fencing, monitoring, backup and restore validation, and a retained rollback. The gateway is the active product; the connector bridge is next.
The architecture itself is frozen. New work executes against it rather than renegotiating it, which is what makes a one-product-at-a-time migration finishable instead of endless.
Why publish a migration plan? Because a plan that only exists privately is indistinguishable from an intention. Twelve roles, three done, gate on evidence, rollback retained. That is a claim anyone can hold me to — and it is far more useful than another architecture diagram with no scoreboard attached.
The Orchestrator moved into containers
The AI Orchestrator Console — the protected operator dashboard — completed its cutover to a containerized deployment with a protected ingress. This is the piece that shows service health, live stack topology, logs, notifications, communications state, security posture, and the audit control plane. Moving it into the same containerized plane as everything else removed the last significant "special case" host process from the operator path.
A refreshed cloud model roster
Kaizen runs local models first, but it keeps authenticated paths to cloud providers for the work where a frontier model genuinely wins. That roster was rebuilt this month and now covers Gemini 3.8 Flash, Grok 4.6, GPT-6 Astra, Claude Fable 5.1, Claude Opus 5, GLM-5.3, and Perplexity Pro.
Two things about that list matter more than the names. First, each provider path is functionally checked by the full audit rather than assumed healthy. Second, cloud lanes are excluded from performance benchmarking — comparing a local model on hardware I own against someone else's datacenter tells you about their datacenter, not about this platform.
A governed CLI bridge
Five governed terminal sessions now run as a first-class service, reachable from the iOS app and the console. Each session is a named lane with its own lifecycle, and an out-of-process watchdog refreshes an idle lane only after continuous proof that nothing is attached and nothing is running. It never guesses which process to kill; failure restores the original.
KaizenAI iOS 1.0.115
The iOS client shipped with authenticated runtime health, live model discovery, terminal viewport and repaint fixes, direct theme controls, and a rewritten About screen that describes the compute and intelligence systems the app is actually talking to.
What remains private
The boundary has not moved. The public lanes — web chat, and the bounded voice and SMS demo — get a model and nothing else. No private memory. No device control. No internal tools. No hardware or platform identity. No access to the operator console, the automation layer, the communications state, or the file surfaces.
Specific infrastructure details stay unpublished on purpose: host addresses, credential architecture, the internals of the secret distribution model, and the exact contents of the security control plane. A release note that hands over a map is not transparency, it is an invitation.
How to evaluate the work
The useful test for a platform like this is not whether the demo works. It is whether the boring parts are real:
- Does a backup restore, and has anyone actually tried it recently?
- When a service fails, does something notice without a human watching?
- Can a migration step be rolled back, and is the rollback still there?
- Does the public surface get a smaller set of capabilities than the private one, enforced somewhere other than a prompt?
- Is there a number attached to "how far along is this", and does it move?
Three of twelve roles in production is not a finished migration. It is a real one.
Why this matters
The premise has not changed since the first article: own the intelligence, control the entire system. What changed in September is that the system underneath the intelligence is now something I can describe in one diagram, migrate one piece at a time, and prove the state of on any given day.
Build local. Remain in control.
