Babb Works

A software and standards company building durable tools for people who do real work.

Babb Works is the entity behind everything on this site. It builds tools, protocols, and standards for operational work — manufacturing, field service, accounting, production coordination. The company's output spans open-source software, normative specifications, a venture-stage industrial initiative, and a growing family of command-line tools that share a common design philosophy.

The name comes from a simple idea: work should be the thing that matters. Not the platform, not the subscription, not the vendor lock-in. Babb builds instruments that respect the actual constraints of working life — conservation laws in ledgers, offline operation on cheap phones, natural language at the terminal — and publishes them with normative specifications so anyone can verify what's claimed.

How it operates

All active repositories are publicly visible on GitHub under github.com/babbworks. Repos are tagged with topic labels (babb-tool, babb-featured, babb-standard, babb-vision) for discoverability. Development follows a source-of-truth model: edits happen in the canonical repo, then sync outward to deployed instances.

The product ecosystem is vertically integrated but loosely coupled. BitPads and BitLedger define the wire formats. Workpads uses those formats for portable records. Workwarrior provides the productivity layer. Clarkware integrates it into a production-floor IDE. Clark deploys it into a real industrial corridor. Each layer functions independently, but together they form a stack where every byte on the wire has a specification and every tool has a standard it can be measured against.

The voice

Babb also has a companion persona — heybabb — a terminal-native CLI companion built on compiled knowledge bases with optional AI enhancement. It narrates work with clarity and care, described internally as "faithful and curious." The character framework that powers it is open-source, so any organisation can build their own CLI companion on the same architecture.

Clark

Rebuilding industrial training and production capacity across the Hamilton–Niagara corridor.

Clark is the largest project in the Babb Works portfolio. It is a research-driven initiative to establish distributed electronics manufacturing and training centres across Southern Ontario's Hamilton–Niagara corridor, with a cross-border thesis extending into the Buffalo–Western New York region. The ambition is not to build a single factory but to seed a network of locally owned, protocol-connected production centres that share curriculum, credentialing, and software while remaining operationally independent.

The core insight is that the Anglosphere's industrial training infrastructure has atrophied to the point where individual firms cannot rebuild it alone. Decades of offshoring hollowed out not just production lines but the apprenticeship pipelines, community colleges, and supplier ecosystems that made production viable. Clark proposes that the recovery unit is not the firm but the corridor — a geographic zone dense enough in transport, talent, and institutional memory to support a critical mass of production activity.

The corridor thesis

The Hamilton–Niagara corridor is Clark's anchor. Hamilton retains deep industrial memory from its steel era, an established post-secondary infrastructure, and real estate that is undervalued relative to the GTA. The Niagara region offers border proximity to the Buffalo manufacturing base, a network of smaller towns with skilled labour pools, and access to both CN and CP rail corridors. The QEW, 403, and 406 highways connect everything within a 90-minute drive radius.

On the American side, Buffalo–Niagara and Western New York provide the counterweight. Existing EMS (electronics manufacturing services) firms like Artaflex, SCI Systems, and CUI Global already operate in the region. The CHIPS Act and I-Corridor initiatives have directed federal investment into semiconductor and advanced manufacturing. Clark's thesis is that the border crossing at Niagara is not a barrier but a seam — a zone where Canadian training capacity and American production demand can meet.

The training model

Clark's curriculum is structured as a 16-course map spanning three levels. Level 1 (Foundations) covers industry history, IPC standards, basic soldering, and component identification. Level 2 (Professional) deepens into SMT assembly, reflow profiling, inspection under IPC-A-610, and production documentation. Level 3 (Advanced) addresses Class 3 high-reliability assembly, BGA rework, X-ray inspection, and conformal coating — the kind of work demanded by defence, aerospace, and medical device contracts.

The model is deliberately bench-centric. Training happens at workstations, not in lecture halls. Each station runs the Clark IPE for task management and process documentation, so the training environment and the production environment share the same software. A trainee's work is recorded from day one in the same systems they'll use as a certified operator.

The evidence approach

Clark maintains a claims register where every public assertion is tracked with an evidence status: safe, provisional, or rejected. The venture corpus — approximately 140 documents covering business plans, field reports, research notes, financial models, and site assessments — is published alongside the public narrative at clark.babb.tel. The intent is that anyone evaluating Clark can inspect not just the pitch but the underlying record. Two industry reports, on the Niagara Peninsula and the Buffalo Region, provide the corridor-level context. The first-node business case targets approximately CAD 135,000 in proof economics over a 24-month bar.

Clark IPE

The Integrated Production Environment: a Theia-based workstation shell for electronics assembly centres.

The Clark IPE is the software layer that sits on every workstation in a Clark centre. It is built on Eclipse Theia 1.69, the open-source IDE framework, extended with custom panels, services, and integrations specific to electronics production. Where Theia provides a general-purpose editor shell with extension architecture, the IPE narrows it into a five-panel workstation interface designed for operators, not software developers.

Architecture

The IPE runs as a Theia application with a Node.js backend and an Electron or browser frontend. The backend exposes a FastAPI service layer for domain operations — profile management, task routing, ledger writes, object storage — while Theia handles the UI shell, keybinding system, and extension lifecycle. PostgreSQL stores structured data (profiles, tasks, credentials, audit records). MinIO provides S3-compatible object storage for binary artifacts: inspection photos, firmware images, gerber files, and test reports.

The five panels are: Task Queue (active work orders, priority-sorted, pulled from Workwarrior), Process View (step-by-step assembly instructions with visual references), Inspection (photo capture, defect classification against IPC-A-610, AI-assisted anomaly detection), Time & Journal (TimeWarrior integration for station-level time tracking and JRNL for shift notes), and Comms (XMPP-based messaging for inter-station and supervisor communication). Each panel is a Theia widget backed by its own service contract.

Workwarrior integration

The IPE embeds Workwarrior as its task and productivity engine. Each workstation runs its own Workwarrior profile, isolated from other stations but synchronisable to a centre-level aggregate. The ww dispatcher is invoked from the IPE's command palette, and the natural language engine is available for operators who prefer typing "start soldering board 4" over navigating menus. UDAs (User Defined Attributes) carry production-specific metadata: board revision, work order number, customer code, IPC class. The MCP server interface allows AI agents running in the Inspection panel to query and update task state programmatically.

IPC-CFX communication

The IPE implements a subset of the IPC Connected Factory Exchange (CFX) protocol for machine-to-machine communication on the production floor. CFX messages are AMQP-transported JSON payloads defined by IPC-2591. The IPE publishes station events (work started, work completed, inspection result, defect logged) as CFX messages and subscribes to equipment events from reflow ovens, pick-and-place machines, and AOI (Automated Optical Inspection) systems. This gives the centre a real-time event bus without requiring proprietary MES software.

Firmware tooling

For centres doing board-level assembly with programmed components, the IPE includes a firmware workflow. It manages JTAG and SWD programming sessions via OpenOCD integration, stores firmware images in MinIO with version metadata and SHA-256 checksums, and records programming results (pass/fail, device ID, programming time) against the work order. The flash programming panel provides a visual status for multi-device batch operations — critical for production runs where a single board may carry three or four programmable ICs.

XMPP and audit trails

All inter-station and operator-supervisor communication runs through XMPP (via the clark-chat component). Messages are persisted and indexed as part of the production audit trail. When an operator flags a defect, the message thread — including photos, inspector notes, and disposition decisions — becomes part of the quality record. This replaces the paper-based traveller documents still common in small-volume electronics assembly with a searchable, timestamped, cryptographically attributable digital record.

Offline-first and deployment

The IPE is designed to operate without continuous network connectivity. The Theia shell, all panel UIs, and the FastAPI services run locally on each workstation. PostgreSQL and MinIO run on the local machine or on a centre-level LAN server. Synchronisation with other stations and with the central profile happens opportunistically when connectivity is available. This is a deliberate architectural choice: production floors have unreliable Wi-Fi, and a workstation that stops functioning because a cloud service is unreachable is a workstation that loses money.

Current development status: the Theia shell boots, four of five panels render, profile CRUD operates end-to-end, and the Workwarrior service contract is stable. The Inspection panel's AI integration and the IPC-CFX event bus are the active development fronts.

Workpads

A field notebook for the working world. Portable, sovereign, offline-first.

Workpads is a portable job record system for people who do physical work in the field. It pairs structured forms with photos, audio, and signoffs, and it runs on the cheapest phones available — KaiOS devices with 240×320 pixel screens, D-pad navigation, and no touch input. A complete job record can be encoded into a URL hash small enough to send over SMS or WhatsApp.

The system is organised around the PADS model: Processes, Actions, Details, Story. These four categories cover most field work — a repair log, a delivery confirmation, a site inspection — while remaining simple enough that someone on a $30 phone can complete one between tasks. Records are encoded using the pads-v1 binary frame format with DEFLATE compression and base64url encoding, producing URLs like workpads.me/p#1pa/<payload>.

The ecosystem spans thirteen repositories: an orchestrator, a normative standard, a canonical JavaScript codec, a KaiOS app (v0.1 live with 14 Places across 5 Worlds deployed), a browser app at workpads.me (currently in active build), a CLI reference implementation, a BASICS conformance environment, build tooling, and public-facing sites at workpads.org and standard.workpads.org. Conflict resolution in sync favours the person on-site, because the person holding the phone knows more than the server.

Workwarrior

A terminal productivity operating system. Five tools, one interface, natural language.

Workwarrior wraps five open-source productivity tools — TaskWarrior, TimeWarrior, JRNL, Hledger, and Bugwarrior — into a single profile-based command-line dispatcher. Each profile gets its own isolated workspace: its own tasks, time records, journal entries, ledger, and configuration. Switch profiles and the entire context switches with you.

The natural language engine is the centrepiece. A compiler written in JavaScript produces 627 heuristic regex rules that map conversational English to precise tool commands. Type something close to what you mean; the engine finds the right tool and the right flags. When the heuristics miss, an optional LLM fallback handles edge cases. The system also serves a browser UI via Python HTTP with real-time SSE updates across 15+ panels, provides two-way GitHub sync via Bugwarrior, and includes a set of power tools called Weapons: Gun (bulk task series), Sword (task splitting with dependencies), Next (recommendation), and Schedule (auto-scheduling).

Webwarrior

Webwarrior is the browser-native reimagining. Same capabilities — tasks, time, journal, ledger — running standalone in any browser with zero installed dependencies and data stored only on the user's device. The architectural shift is fundamental: Workwarrior is a microservice mesh (bash subprocesses, IPC via stdin/stdout); Webwarrior is a modular monolith (ES modules, function calls returning Promises, IndexedDB storage). Every service takes a (profile, args) signature, touches no DOM, and is independently testable in Node.js. A CSP policy of connect-src 'none' guarantees no outbound network calls after page load. Available at webwarrior.babb.tel.

BitPads & BitLedger

From a single heartbeat byte to a fully identified, timestamped, valued, tasked, and annotated record.

BitPads is a universal binary communication protocol built on a single organising principle: conservation. Every meaningful exchange of value — money, mass, energy, data — obeys the same algebraic invariant. Double-entry accounting, Kirchhoff's current law, mass balance, and momentum transfer are all instances of the same rule. BitPads makes that invariant the structural foundation of the wire format.

The protocol scales across a transmission spectrum: 1 byte for a pure signal (heartbeat, ACK), 4 bytes for an anonymous value wave, 13–29 bytes for a full record with identity and timestamps, and 22+ bytes for a complete BitLedger double-entry transaction with CRC-15 integrity. The encoder is hand-assembled x86-64 NASM — no C runtime, no dependencies, direct kernel syscalls. This isn't minimalism for aesthetics; it's minimalism because every byte on the wire must be accountable, and abstraction layers obscure accountability.

BitLedger

BitLedger sits on top of BitPads as a binary financial transmission protocol. A complete double-entry transaction fits in 40 bits — 5 bytes. Three layers: an 8-byte session header with CRC-15, a 6-byte batch header for currency and scaling, and a 5-byte record. The batch constraint is absolute: the sum of all signed flows must equal zero. If it doesn't, the batch is rejected at the encoding stage. Balance isn't a policy — it's a physical property of the format.

BitLedger has been generalised to a universal domain. The same wire format that carries financial transactions can carry propellant mass budgets between spacecraft, power obligations across a grid, data packet allocations in a network, or contractual obligations between satellites. The conservation law is identical. Only the domain label changes.

Works

A digital production system and compound standard for the deliberate storage, transformation, and authorised output of business information.

Works models information management as a physical compound — a Victorian ironworks where raw material enters through one gate, moves through stores and mills, passes inspection, and exits through another gate with full accountability for every gram. The metaphor is structural, not decorative. It enforces properties that software typically treats as afterthoughts: every piece of information has a verifiable location, a transformation history, and an authorised output path.

The standard defines nine building types. Intake receives, verifies, and routes incoming material. Store provides addressed chunk repositories across three tiers (Raw, Staged, Integrated). Mill handles interactive transformation — grouping, reordering, tagging, annotation. Bench is the ephemeral session workspace. Barrel stores programs (instruction sequences, cycle modes, event triggers). Gate authorises output with approve/reject/hold/reroute decisions. Dispatch delivers through five channels. Office sets policy, issues tokens, and maintains the audit log. Vault is append-only archival with a Pacioli guarantee — once written, never altered.

The architectural lineage is explicit: Babbage's Analytical Engine (3D addressing, stored programs), Ada Lovelace's notes (symbolic generality, cyclic operations), and von Neumann's 1945 architecture (the stream bottleneck accepted as a feature, not a bug, because auditability requires serialisation). A full browser implementation exists in Preact with 42 files, OPFS persistence, Web Worker replay, and over 100 passing tests.

Standards-first

Write the specification before the software. Then build a tool that checks conformance automatically.

BASICS

BASICS (Business Application Standardisation In Core Systems) is a conformance protocol for business-focused software. It defines five structural components (Shared Core, Software, Hardware, Firmware, Operational Extensions), three conformance tiers (Core, Field, Industrial), and a governance model with 100-day cycles from draft to decision. No silent requirement drops. Formal migration impact assessments for every change.

The companion CLI tool (basics) runs locally against any repository. It checks for structural compliance — do the required documents exist, are command surfaces documented, are policy artifacts present and correct. Two rule packs: dirty-core for harsh quick checks and assess-core for deeper validation. Machine-readable JSON output plus human-readable Markdown reports. It fills the gap between heavyweight ISO 9001 and the informal practices most teams actually follow.

The specifications

Five standards currently exist, each written independently of its implementation:

• Workpads Standard — pads-v1 codec normatively specified (sections 1–8)
• Workwarrior Standard — profile system, command grammar, service contracts
• BitPads Standard — 8-bit meta layer, enhancement sub-protocol, transmission spectrum
• Works Standard — compound buildings, stream system, Pacioli guarantee
• BASICS Standard — conformance tiers, rule IDs, governance model

CLI-first philosophy

Nearly every project begins at the command line. A CLI forces you to name every operation, define every parameter, and produce composable output. It generates an audit trail by default. It works over SSH, in containers, on servers, in CI pipelines, and inside AI agent tool-call chains (via MCP). Five dedicated CLI tools: ww (Workwarrior), basics (conformance), bitpads (protocol decoder), workpads (record management), and newent (enterprise planning). Language and syntax are not an interface choice. They are the centre of operations.

ZAKO

A sovereign operating system standard where every interaction is a conservation event — two-sided, balanced, and provable.

ZAKO is not an Android skin. It is a normative standard for a sovereign mobile operating system. The name governs a complete architecture: every meaningful event the device mediates — a payment, a task assignment, a blood pressure reading, a power mode transition — is treated as a record in a ledger. Records are BitPads frames, signed by the device sovereign's ed25519 key, chain-hashed against the record that preceded them, and never deleted. Amendments are new records that reference and supersede.

The architecture is organised into three layers. The Bedrock Layer is hardware and kernel: TrustZone key storage, dm-verity partition integrity, hardware power domain control. These are physical guarantees that software cannot override. The Submerged Layer is where ZAKO's intelligence lives: Outstack governs the device through power, Telux manages identity and sovereignty, and the BitPads codec library encodes every record at the wire level. The Visible Layer is the surface: AOSP without Google Mobile Services, F-Droid for distribution, UnifiedPush for notifications, and ZAKO's own native C application suite.

The conservation principle

Every ZAKO record involving a quantity — money, energy, data, time — is a BitLedger record. The conservation invariant is enforced at encoding time: for every batch, the sum of all signed flows must equal zero. This is not a rule the application must remember to check. It is a structural property of the wire format. A batch that does not balance cannot be correctly formed. Three independent error detection mechanisms — CRC-15, cross-layer direction bit mirroring, and the conservation invariant itself — make corruption survivable only if it defeats all three simultaneously.

Sovereignty architecture

A ZAKO user is the Sovereign of their device. Records never leave the device without an explicit sovereign action that itself produces a record. Identity is not issued by a third party — it is a W3C Decentralized Identifier (did:key method) backed by hardware keys in TrustZone (Keymaster 4.0). The Telux subsystem manages Islands — isolated containers, each with its own security namespace, ledger, and capability grants. A work Island, a personal Island, and a health Island share the same device but cannot access each other's records without an explicit, revocable, audited capability grant with a maximum delegation depth of three.

Power as governance

Outstack is not a power management system. It governs everything through power. The distinction matters. Where conventional power management operates at the margins — dimming screens, throttling background tasks — Outstack is the organising principle of the entire runtime. Every process has a power class (CRITICAL, INTERACTIVE, STANDARD, DEFERRED, OPPORTUNISTIC). Every Island has a power budget. The device exists in one of five system-wide modes at all times — FULL, NORMAL, CONSERVE, CRITICAL, EMERGENCY — determined by objective battery and thermal measurements, not user preferences. In CRITICAL mode, only processes classified CRITICAL and INTERACTIVE continue to execute. In EMERGENCY (below 5%), the device enters survival posture: basic paging, incoming SMS, and a full state snapshot to durable storage for recovery on next boot.

The design lineage is aerospace. Spacecraft running on radioisotope thermoelectric generators have operated this way for decades — every subsystem has a power budget, every operation is evaluated against it, and graceful degradation is the default. ZAKO brings this discipline to a 1450mAh lithium cell.

Offline-first and transmission

No ZAKO service requires network connectivity to create or read records. Transmission happens when and how the Sovereign chooses, over four channels: SMS (no data connection required), QR code (no network at all), Bluetooth LE (short range, very low power), and IP when available. Records encoded as pads-v1 URLs fit in fewer than 300 characters — transmissible in a single SMS. The bilateral exchange engine enforces conservation across both sender and receiver: a payment is not complete until both ledgers reflect the same atomic two-leg settlement.

The standard corpus

ZAKO is specified across seven core documents: the ZAKO Standard v1 (canonical record format, service architecture, two-engine model), Wire Conventions v1 (byte-level encoding rules for every record type), Codebook Standard v1 (domain-specific symbol sets for pictographic communication), Pictography Standard v1 (4-bit visual symbol encoding), Infrastructure Extension Profile v1 (adapting ZAKO for stationary and industrial infrastructure), Performance Constants Index v1 (quantified timing and resource budgets for every operation), plus three protocol specifications for Outstack, Telux, and SIMBA.

Protocols

Outstack Protocol v1 defines the five-mode state machine, process class taxonomy, power budget accounting, and the C0 signal broadcast mechanism for mode transitions. Telux Protocol v1 defines Island lifecycle, DID-based identity, the exchange engine, capability grants, and the append-only chain-hashed ledger with fsync-before-ACK durability. SIMBA Standard v1 (SIM-Based Authentication) defines how ZAKO uses the SIM card's secure element for identity binding without carrier dependency.

Packages and services

Four system packages implement the standard: zako-outstack (power governor daemon), zako-telux (sovereignty, identity, and ledger services), zako-pads (portable field record integration), and zako-simba (SIM-based authentication). Four domain services are specified: Academy (structured training delivery with progress tracking), Agreements (bilateral contract formation and execution), Health (clinical measurement records with conservation-enforced dosage tracking), and PADS (the field record service integrating Workpads into the OS).

ZAKO OS v1

From specification to compiled code: 14 C libraries and daemons, 1,207 tests passing, three phases complete.

ZAKO OS v1 is the first implementation of the ZAKO Standard. It is an active engineering effort to produce an operational sovereign mobile operating system, written almost entirely in C99 (MISRA-C subset) with zero dynamic allocation in steady state. The project plan spans seven phases, from foundational cryptographic libraries through AOSP integration to a native C application suite. As of June 2026, Phases 1 through 3 are complete: twelve components built, compiled, and tested on the host machine with 1,207 tests passing across all three layers.

Language and build discipline

The language decision is deliberate and extreme. Every daemon, every protocol codec, every cryptographic primitive, and — uniquely — the primary user-facing applications are written in C. Not C++, not Rust, not Kotlin. The core ZAKO app suite (PADS, Exchange, Sovereignty Dashboard, Outstack widget) will be native C with direct framebuffer or minimal toolkit rendering: instant launch, minimal RAM, no JVM dependency. The Android application framework and its Java/Kotlin runtime are retained only as a secondary capability for third-party F-Droid software. ZAKO's own tools do not touch the JVM.

The integration model is zero AOSP framework modifications. Every ZAKO component is an addition — init.rc services, Unix socket IPC, resource overlays, system properties. No patches to existing AOSP source. This is not minimalism for aesthetics; it is a survival strategy. Every modification to upstream code is a rebasing obligation carried indefinitely. Additions live alongside upstream and require only integration testing as AOSP moves forward.

Phase 1 — Foundation libraries

Six pure C libraries, testable on any Linux or macOS machine, with zero external dependencies beyond a C99 compiler and standard libc:

• libzako-hash — BLAKE3 wrapper for chain hashing, frame hashing, and genesis anchor computation. Wraps the BLAKE3 reference implementation.
• libzako-sign — ed25519 key generation, signing, and verification. Wraps TweetNaCl. Tested against RFC 8032 known vectors.
• libzako-did — W3C DID formatter using the did:key method with z6Mk prefix and BASE58BTC encoding.
• libzako-bitpads — BitPads v2.0 codec: Meta byte parsing, four frame types, encode/decode. Produces both core and session static libraries.
• libzako-bitledger — BitLedger v3.0 codec: 40-bit record encoding, CRC-15 integrity, conservation invariant enforcement at encode time.
• libzako-c0 — C0 Enhancement Grammar parser: 13 declared positions for priority, acknowledgement, and continuation signalling in every transmission.

Quality gates: >90% branch coverage, cppcheck MISRA-C analysis with zero warnings, AFL++ fuzz testing (1M+ iterations, no crashes), cross-compilation verified for ARM32. Total: 495 tests passing.

Phase 2 — Core daemons

Three critical daemons and the system bus, forming the submerged layer:

• telux-ledgerd — The append-only ledger daemon. SQLite storage, conservation invariant enforcement, chain hashing with BLAKE3, fsync-before-ACK durability guarantee. Adversarial batches (intentionally imbalanced) are rejected at the codec level. Unix socket intake for record submission.
• telux-identd — Identity daemon. ed25519 key generation and management, DID lifecycle, capability grants (GRANT/REVOKE/DELEGATE with depth-3 maximum), identity lock, and signing service. All operations produce ledger records.
• outstack-powerd — The five-mode power state machine. Reads battery and thermal state from sysfs, determines the current mode, gates process execution via cgroup freezer, emits BitPads records for every mode transition, and broadcasts C0 signals to all listening daemons. Tested against all six state machine scenarios from the protocol specification.
• libzako-bus — Unix domain socket multiplexer for inter-daemon communication. Routes C0 signals between daemons. Provides the IPC backbone.

All daemons pass Valgrind with zero memory errors. Total: 425 tests passing.

Phase 3 — Exchange and transmission

The outbound capabilities that let ZAKO devices communicate:

• exchange-engine — Bilateral settlement core. SEND/RECEIVE cycle with conservation check and atomic dual-leg posting. Tested with simulated ZMW (Zambian Kwacha) transfers between two mock sovereigns.
• telux-sharedb — Channel abstraction for outbound transmission. Manages SMS, QR, BLE, and IP channels with per-channel formatting and queue management.
• libzako-padsurl — pads-v1 URL codec. Encodes records as <300 character URLs suitable for SMS transmission. Round-trip encode/decode verified for all frame types.
• libzako-pictography — 4-bit symbol codec with codebook switching and ALERT promotion for binary pictographic communication.

Exit criteria met: two simulated ZAKO devices exchange a signed payment record via mock SMS channel, conservation enforced, chain hashes verified, both ledgers consistent. Total: 287 tests passing.

What the code looks like

The system/components/ directory contains 14 subdirectories, each with its own Makefile, source files (.c/.h), compiled static libraries (.a), object files, test binaries, and test source. Every component follows the same pattern: a clean C API in the header, implementation in the source, a test file that exercises every public function, and a Makefile that builds both the library and the test. No build system generators, no dependency managers, no package.json. Makefiles and a C compiler.

Phases 4–7 (ahead)

Phase 4 (AOSP Integration) establishes the build environment, device tree (device/babb/s22flip/), vendor blob extraction, kernel cross-compilation (Linux 4.9 CAF, MSM8937), SELinux policy for all ZAKO daemons, and first bootable image. Phase 5 (Device Bring-Up) targets full telephony — voice calls, SMS, LTE data on a Canadian SIM — plus hardware-specific integration: lid sensor (Hall effect SW_LID triggering CONSERVE mode on flip close), T9 keypad GPIO mapping, and the ST7789 SPI cover display. Phase 6 (Applications) builds the native C application suite with direct rendering — PADS, Exchange, Sovereignty Dashboard, Outstack widget, T9 input method — after a UI toolkit research sprint evaluating framebuffer, SurfaceFlinger native client, NativeActivity, and lvgl. Phase 7 (Distribution) produces signed OTA packages, F-Droid repository configuration, and the first Babb Cat release image.

Workwarrior integration

All engineering work is tracked in a dedicated Workwarrior instance (~/wwv02, profile zako-os-v1). Tasks are tagged by subsystem: +outstack, +telux, +bitpads, +kernel, +aosp, +research, +code, +architecture. Time records, journal entries, and ledger transactions for the project all live in the same profile. The project plan, component inventory, language research, AOSP linkage analysis, and git overlay strategy are maintained as living documents alongside the code.

Babb Cat

The first ZAKO distribution. A sovereign phone for Zambia, built on the Cat S22 Flip.

Babb Cat is the codename for the first hardware distribution of ZAKO. It targets the Cat S22 Flip — a ruggedised flip phone running Qualcomm's QM215 (MSM8937) SoC with four Cortex-A53 cores at 1.4GHz, 2GB RAM, 16GB eMMC, and a 1450mAh battery. The device has two screens: a 2.8" main display and a 1.44" ST7789 SPI cover display. It has a physical T9 keypad, a Hall effect lid sensor, and a bootloader that can be unlocked. The form factor is culturally familiar in sub-Saharan Africa, the hardware is IP68-rated, and the bill of materials places it in the sub-$100 segment.

The thesis is simple: most phones running in sub-Saharan Africa are running software designed for someone else. The defaults are wrong — the timezone, the keyboard, the apps, the cloud endpoints, the energy assumptions. The hardware is often adequate. The software is not built for this context. Babb Cat replaces the entire software stack so that it is purpose-built for deployment in Zambia and similar markets.

What gets removed

Google Mobile Services (GMS) is entirely absent. No Play Store, no Play Services, no Google Maps, no Firebase Cloud Messaging, no Google Account system. This is not a compromise — it is the founding design decision. A device running GMS cannot be sovereign, because GMS's persistent connections mean the device continuously reports to a party that is not its user, the power budget is continuously allocated to that reporting, and the user's applications are mediated by Google's identity infrastructure.

What GMS removal requires Babb Cat to replace: push notifications move to UnifiedPush (open protocol, user-chosen or self-hosted provider). Application distribution moves to F-Droid (installed as a privileged system app for silent updates, serving only source-auditable software). Location moves to AOSP standard GPS plus OpenStreetMap. Authentication moves to Telux's DID-based identity backed by hardware keys. Device attestation narrows to hardware security module direct attestation — a smaller claim than SafetyNet, but honest about what it verifies.

Hardware bring-up

The device tree lives at device/babb/s22flip/ in the AOSP source tree. Key integration points:

• Bootloader unlock — Cat S22's bootloader is unlockable via fastboot oem unlock. Once unlocked, custom boot and system images can be flashed.
• Kernel — Linux 4.9 CAF (CodeLinaro), cross-compiled for ARM32 with ZAKO-specific defconfig additions: CONFIG_CGROUP_FREEZER=y for Outstack process gating, CONFIG_THERMAL_GOV_USER_SPACE=y for thermal control, CONFIG_CPUFREQ_GOV_POWERSAVE=y for Critical/Emergency governors.
• Vendor blobs — Extracted from stock device via ADB. Critical: modem firmware (telephony), ADSP/CDSP (audio, sensors), Adreno GPU blobs (display), WiFi/Bluetooth firmware. Organised in vendor/babb/s22flip/.
• Cover display — The 1.44" ST7789 SPI panel requires DTB decompilation and reverse engineering for initialisation sequence. telux-coverd daemon drives it directly: time, date, battery, power mode, last ledger entry, caller ID.
• Lid sensor — Hall effect switch generates SW_LID input events. Closing the flip triggers Outstack to enter CONSERVE mode. Opening it restores the previous mode.
• T9 keypad — GPIO-keys driver with scan code mapping for all physical keys. The T9 input method is written in C, with a thin JNI shim only for Android IME framework integration.

Zambia deployment context

Zambia is the initial target for specific reasons. Mobile phones are the primary computing device for most Zambians. Mobile money (Airtel Money, Zamtel Kwacha, MTN MoMo) is the primary financial infrastructure — more accessible than banking. Android Go devices dominate the sub-$100 segment. Google services consume battery, bandwidth, and data — all scarce resources. No existing Android OS is designed with this context as its centre.

Babb Cat addresses this by stripping background data transmission to foreign servers, extending battery life through Outstack's power governance (a 1450mAh cell managed by aerospace-grade power discipline), providing first-class support for local mobile money platforms, and configuring the telephony stack for Zambian carriers. The device works as a phone first — voice calls, SMS, and USSD balance checks function without data connectivity.

The ZAKO integration layer

On the device, the ZAKO standard manifests as four daemon processes visible in ps: telux-ledgerd, telux-identd, outstack-powerd, and telux-sharedb. They communicate over libzako-bus (Unix domain sockets), write records to Island-specific SQLite ledgers, and emit C0 signals on mode transitions. SELinux enforces custom domains for each daemon (telux_ledgerd_t, telux_identd_t, outstack_powerd_t). The data directory at /data/zako/ is encrypted per-Island via Android's file-based encryption with Keymaster 4.0 ICE.

The services manifest specifies which ZAKO services are active on Babb Cat: PADS (field records), Exchange (bilateral settlements), and the Sovereignty Dashboard. The Academy and Health services are specified but deferred to a later release. Outstack tuning parameters are profiled for the Cat S22's specific battery chemistry and thermal characteristics, documented in a tuning log with empirical measurements.

Build and release

The build system produces flashable images via standard AOSP tooling: source build/envsetup.sh && lunch aosp_s22flip-userdebug && m -j$(nproc). Output is boot.img, system.img, vendor.img. Signed releases follow a defined process with regression testing, a known-issues log, and a release checklist derived from the distribution standard. OTA updates are planned via a self-hosted update server — no Google OTA infrastructure.

Everything else

Smaller tools, experiments, and supporting infrastructure.

heybabb

A terminal-native CLI companion built on compiled knowledge bases with optional AI enhancement. Offline-capable, never performative. The reference deployment of the open-source character framework, which any organisation can use to build their own branded CLI companion.

Atlas

An industrial discovery tool for the UK. Web-based, queries OpenStreetMap and Overpass API to locate workshops, manufacturing facilities, and industrial buildings. Built to support Clark's research into distributed production capacity.

newent

A Python CLI for planning new enterprises. Local-first, service-oriented architecture. Structures the early-stage thinking that usually lives in scattered notes into a queryable, version-controlled format.

babb-codecs

Monorepo containing canonical codec implementations for the pads-v1 binary frame format across four platforms: Node.js (bitpad), KaiOS, web, and relational database. Full test suite with cross-platform interoperability enforcement.

Supporting infrastructure