In the 1800s various British thinkers recognized the emergence of something different from the Empire itself, a metastasizing of the English world into a Greater Britain, a globalization of the English-speaking peoples with direct legal inheritances and common ethnicities that were producing a diverse but common culture across continents. There is no universal definition for who’s in or out but Ireland, South Africa, some Caribbean states and even Singapore have been included in this, so far, imaginary friendly federation. Beyond the English element and beyond the Common Law frameworks, the third aspect to this informal family is the shared experience of what we can now call “early industrialization” as we witness South America, Asia and Africa fire up their engines. The prototyping of the industrial society happened in the Anglosphere and across all of Europe first, passing through several stages, World Wars, and financial restructuring phases, which then led to a marked deindustrialization phase, bringing us to this new moment characterized by the cry for re-industrialization, advanced manufacturing, re-shoring, and the sovereign society.
At the precise moment that national independence is being emphasized like never before, with supply chain risks and artificial intelligence autonomy acting as driving forces, on what possible grounds can we pursue cooperation among these like-minded countries? And is it possible to do so in ways that provide models and mechanisms for our many trading partners so that we can foster political stability and material prosperity abroad, ultimately putting less stress on our borders and our budgets? I think there is a path for impactful cooperation that doesn’t rely on the fickle rhetoric or permissions of our national governments but nonetheless helps each national economy return to and surpass its former glories.
My proposal below is not a panacea but it does take dead aim at one of the valves pumping life throughout each national economy. Reviving our productive capacities in the very places that pioneered the spirits of mass production and advanced machining is the first but critical step for economic and cultural recovery across the West, for which the term Anglosphere was only ever a proxy, a placeholder and signifier for the extended family of peoples who closely share ideas about the good life and therefore how business should be organized and regulated by the State.
If we are to succeed beyond our imagination and break through into a new era in which the concept of managed decline is remembered as a stop gap measure, we must turn our attention back to the regional ecosystems of producers and processors of every size, seeing through the poster boy Shenzhen back into our own origin, where extreme intra-regional reliance produced the small-scale resilience and momentum which led us into our uncontested positions.
Re-shoring is of course not simply bringing large industrial operations back into our countries. It’s about simultaneously reviving and unleashing the creative capacities of the ecosystems of small and medium makers and inventors that assist big actors, all the while generating the new approaches and processes that the re-invention of traditional sectors requires. This is a return to the wild west, the wild mid-west and to the mania of Manchester where rules and reporting took a back seat to the values of rapid adaptation and adoption, to the seizing of momentary opportunities in the supply chain that could produce temporary gains or recurring revenues. It didn’t matter which at all, the order of the day was to build the economy and country in one messy, swift chaotic storm of collective effort.
These gaps between demand and supply were of a specific sort which seems to be misunderstood in our age of services and knowledge work. As the industrial economy advanced, especially in the mid 1800s, the gap between what people intended to produce and what the machinists and fabricators could create resulted in differing amounts of output-drag across regions. Wherever this backbone was the most adaptive and most skilled, all other industries closer to the consumer accelerated, feeding back in on themselves as manufacturing advanced to new levels of capability. The large factory isn’t the issue, the bottlenecks lay elsewhere, in the supplier of parts and products which enable the big players to ramp up operations. The businesses in need of the most assistance are often too saddled with reporting requirements, thinned out management, and back orders to engage in strategic planning and relationship building. Instead of asking more from these fragile contributors, the answer is to pursue what I call Ecosystem as a Service.
We can create profitable entities that help individual producers operate better on their own and within their regions while reducing the need for government interventions and investment which are absolutely not producing outcomes anywhere near the speed which the pressures we are facing require. So what does that look like and what are the lynchpins we can build around?
In the 1800s and early 1900s electrification was the agenda of the day, helping manufacturers and related industries move away from complicated and limiting drive systems to dispersed motors that powered individual parts of their pipelines. Today the equivalent is the computerization of production. But we can’t stop our intervention there, we must take a more holistic approach.
We’ve lived through a few rounds of electronics adoption and despite the current frenzy, the next stage isn’t a cut and dry matter of embedding AI. In these kinds of workspaces where humans and mechanical systems interact in complex and unique ways, the real challenge is to integrate computers in highly tailored ways that meet the needs of the human operators. These systems must support role evolution and product line pivoting without cost prohibitive re-tooling of the digital systems. Until now, these enterprise software systems often ended up being no different than the dinosaur metal machines that chain businesses into their past. Serving what exists but incapable of meeting the emerging moment. It’s time to support these companies like never before, literally. We can do so in three major ways by giving birth to a new kind of company designed to serve.
This isn’t a plan for a single business. This is a protocol for industrial recovery that anyone can implement. It’s open, amenable, and overall a conversation about what will work and what can be repeated, so that any group willing to take the lead in their area can act fast and effectively.
Main Thesis: Based on our need to re-industrialize across the Anglosphere, the new centrality of computers and automation systems, and the ongoing logistics challenges faced by small and medium sized producers and processors of hard goods, we need a background entity whose purpose is to help companies accelerate their daily output and evolution.
Response: A new kind of Platform-Franchise named Clark that marries the strength of a common brand and operational standards with an open model for spawning regional entities that serve the unique needs of an area while delivering at minimum a core set of high value universal services.
These four pillars are not departments in a corporate org chart. They are capacities that a region either has or doesn’t. Where they exist informally — a retired machinist who trains apprentices on weekends, a job shop that prototypes boards for three counties, a landlord who converts dead retail into maker space — the ecosystem already breathes. Where they don’t exist, producers stall. Orders back up. Talent leaves. The cycle accelerates downward.
Clark’s role is to formalize what already works and plant it where it doesn’t. A Clark entity in Hamilton, Ontario doesn’t look the same as one in Birmingham, Alabama or in Sheffield, England, but each one delivers the same core promise: if you make things in this region, there is an entity whose sole business model depends on you making more of them, faster, with fewer interruptions. Not a government program with quarterly reporting. Not a venture-backed platform extracting data for resale. A peer institution with aligned incentives, funded by the throughput it enables.
The franchise model matters because the problem is not unique to one city. The pattern of deindustrialization repeated everywhere the Anglosphere industrialized first. The recovery must repeat with equal consistency. A protocol — not a headquarters — ensures that each regional entity adapts to local conditions while maintaining the operational standards that make the brand trustworthy to the producers it serves. You can open a Clark in Christchurch with the same playbook that opened one in Cleveland, adjusting for what the region makes, who makes it, and what’s missing from their supply chain.
The window is not permanent. Re-shoring rhetoric without institutional support produces false starts. Governments announce funds, funds arrive late, funds arrive with conditions designed for large incumbents. The small producer — the sixty-person machine shop, the twelve-person electronics assembler, the family-run food processor upgrading a packaging line — watches the announcement, applies, waits, and meanwhile loses another contract to a faster overseas competitor. The gap between political will and operational reality is where Ecosystem as a Service lives. It doesn’t wait for the grant cycle. It earns revenue today by solving problems today.
The AI moment makes this urgent rather than merely important. Every producer will need to integrate computational intelligence into their operations within the decade. Most cannot do it alone. Most cannot afford the consultants who serve Fortune 500 clients. Most will be sold packaged solutions that lock them into vendor dependencies as rigid as the belt-drive systems their great-grandfathers replaced with electric motors. Clark exists to be the alternative: open systems, local expertise, aligned incentives. The software pillar — production and logistics tools built in the open — ensures that no producer’s digital infrastructure belongs to Clark either. It belongs to them. Clark profits from their acceleration, not their dependency.
This is an invitation to builders, not to spectators. If you operate in a region where producers struggle with fragmented support, outdated digital systems, training gaps, or facility constraints — you are looking at a Clark opportunity. The protocol is open. The model is documented. The brand exists to be deployed, not hoarded.
The Anglosphere’s industrial inheritance is not nostalgia. It is infrastructure — legal, cultural, educational, physical — that can be reactivated. The Manchester of 1845 did not have a strategic plan. It had a density of competence, a tolerance for speed, and an absence of anyone telling its makers to slow down and file a report first. We can recover that energy without recovering the soot. The tools are better now. The communications are instant. The knowledge of what went wrong last time is available to anyone who reads.
What’s needed is not another white paper or policy recommendation. What’s needed is the first ten Clark entities, operating, profitable, serving their regions, proving the model, and making it impossible for the next ten to justify waiting. Leadership in this context means going first. It means capitalizing an entity, hiring the trainers, leasing the assembly floor, deploying the software, and opening the door to every producer in the area who has been told for forty years that their industry is a relic.
It isn’t. They aren’t. And the people who act on that conviction first will define what comes next.
]]>ZAKO is a sovereign mobile operating system. Every interaction it mediates — every resource it governs, every relationship it records — is a conservation event. It has two sides, it must balance, and it must be provable. The protocol that enforces this at the wire level is BitPads and BitLedger. The sovereignty architecture that makes it yours is Telux. The power governance that makes it honest is Outstack. Together they are ZAKO.
A ZAKO device is sovereign in a precise engineering sense:
The reference hardware is the Babb Cat — a Cat S22 Flip ruggedized flip phone running on a Qualcomm QM215 (MSM8937) with 2GB RAM. A $99 device. The architecture does not depend on the hardware. The same standard runs on any AOSP-compatible platform.
ZAKO is not a kernel. It is a coherent assembly — like Ubuntu is to Linux — of a kernel, core daemons, system services, and application infrastructure expressing a unified philosophy: sovereignty.
Three layers:
The Bedrock Layer is hardware and kernel. TrustZone root of trust, dm-verity integrity checking, hardware power domains, the Telux-SEC kernel security module. These are physical facts. They cannot be overridden by userspace software.
The Submerged Layer is where ZAKO’s intelligence lives. Outstack governs the device’s power state and enforces the relationship between power mode and process execution. Telux manages Islands, newgroups, sovereignty grants, and the exchange ledger. The identity service manages DIDs for every entity — human, machine, AI, or service.
The Visible Layer is the surface: group interfaces, exchange queries, telephony, applications, natural language query. Built on AOSP because it is proven, runs on existing hardware, and can be audited without dependency on any single commercial entity.
The protocol foundation:
Every ZAKO record is a BitPads frame. BitLedger v3.0 encodes conserved scalar exchanges in 40 bits. BitPads v2.0 wraps every transmission with a meta byte declaring frame type. The Enhancement Sub-Protocol provides priority, acknowledgement, and continuation signalling at 13 declared positions. Three independent error detection mechanisms — CRC-15, cross-layer mirroring, and the conservation invariant — ensure integrity.
Four architectural lineages:
Unix gave ZAKO composable small tools and graceful degradation. Plan 9 gave it namespace isolation — every Island is a constructed namespace. seL4 gave it capability-based security — no ambient authority, sovereignty as unforgeable tokens. CICS gave it the transaction as substrate — every exchange recorded before it completes, durable, auditable, sixty years of proven operation.
No Google Mobile Services:
GMS removal is the founding design decision. Push notifications via UnifiedPush. Applications via F-Droid. Maps via OpenStreetMap. Authentication via Telux DID. Every replacement is more sovereign, not merely different.
Five power modes:
Outstack governs the device through five objective power states: FULL (>80%, unrestricted), NORMAL (60-80%), CONSERVE (20-60%, background limited), CRITICAL (5-20%, essential only), EMERGENCY (<5%, survival). These are not user-selected profiles — they are operational states determined by objective measurement. At exec() time, Outstack checks whether the current mode permits the process. A 10% battery is a device exercising sovereignty over which processes continue.
Every mobile operating system currently available was designed around a premise never stated because it was considered obvious: the phone exists to serve its manufacturer. Android routes push notifications through Google’s servers, verifies signatures against Google’s keys, sends location history and usage patterns to data centers in jurisdictions the user has no relationship with. Apple’s integration is more complete — the phone is a terminal into Apple’s services. Neither is dishonest. Both serve hundreds of millions of people adequately.
But there are contexts where the premise must be reversed. Where the phone must serve its user rather than its manufacturer. Where records must belong to the parties to the exchange and to no one else. Where the power budget must be accountable to the mission rather than to a background sync schedule determined on another continent.
ZAKO exists for those contexts. A phone in Lusaka, Zambia. An autonomous excavator in a Mongolian copper mine. A humanoid assistant in a hospital in Lagos. A relay node on a spacecraft crossing between Earth and Mars. The architecture does not change. The deployment profile changes. ZAKO adapts. The sovereignty does not.
ZAKO also exists because writing was invented for ledgers, not literature. Cuneiform tablets recording grain allocations, debt obligations, the transfer of livestock between parties. Writing was invented so that exchange could be trusted across time and distance. The clay token preceded the word. ZAKO is an attempt to build the next such substrate.
ZAKO is a sovereign mobile operating system. Every interaction it mediates — every resource it governs, every relationship it records — is a conservation event. It has two sides, it must balance, and it must be provable. The protocol that enforces this at the wire level is BitPads and BitLedger. The sovereignty architecture that makes it yours is Telux. The power governance that makes it honest is Outstack. Together they are ZAKO.
A ZAKO device is sovereign in a precise engineering sense:
The reference hardware is the Babb Cat — a Cat S22 Flip ruggedized flip phone running on a Qualcomm QM215 (MSM8937) with 2GB RAM. A $99 device. The architecture does not depend on the hardware. The same standard runs on any AOSP-compatible platform.
ZAKO is not a kernel. It is a coherent assembly — like Ubuntu is to Linux — of a kernel, core daemons, system services, and application infrastructure expressing a unified philosophy: sovereignty.
Three layers:
The Bedrock Layer is hardware and kernel. TrustZone root of trust, dm-verity integrity checking, hardware power domains, the Telux-SEC kernel security module. These are physical facts. They cannot be overridden by userspace software.
The Submerged Layer is where ZAKO’s intelligence lives. Outstack governs the device’s power state and enforces the relationship between power mode and process execution. Telux manages Islands, newgroups, sovereignty grants, and the exchange ledger. The identity service manages DIDs for every entity — human, machine, AI, or service.
The Visible Layer is the surface: group interfaces, exchange queries, telephony, applications, natural language query. Built on AOSP because it is proven, runs on existing hardware, and can be audited without dependency on any single commercial entity.
The protocol foundation:
Every ZAKO record is a BitPads frame. BitLedger v3.0 encodes conserved scalar exchanges in 40 bits. BitPads v2.0 wraps every transmission with a meta byte declaring frame type. The Enhancement Sub-Protocol provides priority, acknowledgement, and continuation signalling at 13 declared positions. Three independent error detection mechanisms — CRC-15, cross-layer mirroring, and the conservation invariant — ensure integrity.
Four architectural lineages:
Unix gave ZAKO composable small tools and graceful degradation. Plan 9 gave it namespace isolation — every Island is a constructed namespace. seL4 gave it capability-based security — no ambient authority, sovereignty as unforgeable tokens. CICS gave it the transaction as substrate — every exchange recorded before it completes, durable, auditable, sixty years of proven operation.
No Google Mobile Services:
GMS removal is the founding design decision. Push notifications via UnifiedPush. Applications via F-Droid. Maps via OpenStreetMap. Authentication via Telux DID. Every replacement is more sovereign, not merely different.
Five power modes:
Outstack governs the device through five objective power states: FULL (>80%, unrestricted), NORMAL (60-80%), CONSERVE (20-60%, background limited), CRITICAL (5-20%, essential only), EMERGENCY (<5%, survival). These are not user-selected profiles — they are operational states determined by objective measurement. At exec() time, Outstack checks whether the current mode permits the process. A 10% battery is a device exercising sovereignty over which processes continue.
Every mobile operating system currently available was designed around a premise never stated because it was considered obvious: the phone exists to serve its manufacturer. Android routes push notifications through Google’s servers, verifies signatures against Google’s keys, sends location history and usage patterns to data centers in jurisdictions the user has no relationship with. Apple’s integration is more complete — the phone is a terminal into Apple’s services. Neither is dishonest. Both serve hundreds of millions of people adequately.
But there are contexts where the premise must be reversed. Where the phone must serve its user rather than its manufacturer. Where records must belong to the parties to the exchange and to no one else. Where the power budget must be accountable to the mission rather than to a background sync schedule determined on another continent.
ZAKO exists for those contexts. A phone in Lusaka, Zambia. An autonomous excavator in a Mongolian copper mine. A humanoid assistant in a hospital in Lagos. A relay node on a spacecraft crossing between Earth and Mars. The architecture does not change. The deployment profile changes. ZAKO adapts. The sovereignty does not.
ZAKO also exists because writing was invented for ledgers, not literature. Cuneiform tablets recording grain allocations, debt obligations, the transfer of livestock between parties. Writing was invented so that exchange could be trusted across time and distance. The clay token preceded the word. ZAKO is an attempt to build the next such substrate.
BASICS — Business Assistance System — is a practical standard for building business tools that can operate across unstable conditions, constrained devices, mixed operator skill levels, and long product lifecycles.
It is a commitments system with testable obligations. If you build a tool that claims BASICS conformance, you are making specific, verifiable promises about how that tool behaves when conditions are bad: when the network is down, when the device is old, when the operator is new, when the power is low, when the data must last decades.
BASICS does not tell you what to build. It tells you what your tool must survive.
BASICS defines a set of rules — each with a stable identifier — organized into profiles that represent tiers of conformance. Each rule is a testable obligation: a concrete, verifiable statement about tool behavior under specified conditions.
The standard covers:
The BASICS CLI (basics) is a command-line assessor that evaluates a local repository against the standard. It examines code, configuration, documentation, and test coverage to produce an evidence-backed conformance report. The assessor does not guess — it checks specific files, specific patterns, specific behaviors, and reports what it finds.
Conformance is tiered. The Core tier establishes baseline requirements that all BASICS tools must meet. Higher tiers add obligations for specific deployment contexts (intermittent connectivity, KaiOS devices, multi-language operation, audit-grade record keeping).
Most software standards describe what a system should do when everything is working. BASICS describes what a system must do when things are not working — because in the working world, things are frequently not working. The network is down. The device is five years old. The operator learned the tool yesterday. The power went out an hour ago.
Tools built for the frontier — feed-lots, factory floors, rural branches, remote field offices — cannot afford the assumptions that tools built for Silicon Valley make. BASICS exists to codify what frontier-grade software requires, so that builders can commit to it and users can verify it.
The standard also exists because Babb builds tools (Workpads, BitPads, BitLedger, Workwarrior) and needed a way to hold itself accountable. BASICS is the internal discipline made public: the same rules Babb applies to its own products, available for anyone building tools for the same conditions.
basics — evidence-backed conformance checkingBitLedger is a compact binary transmission protocol for double-entry financial records. It encodes the structural balance invariant — every debit has a matching credit, every credit has a matching debit — at the wire level, not as an application-layer validation after the fact.
A complete BitLedger transaction fits in 40 bits. Five bytes. That is small enough to transmit over SMS, embed in a QR code, send via satellite burst, or store on a device with kilobytes of memory. The transaction is self-verifying: if the bits parse, the books balance.
BitLedger operates as the financial core within the broader BitPads protocol family. Where BitPads provides the universal framing and meta-layer, BitLedger provides the specific encoding for conserved quantities — money, inventory, obligations — that must always balance.
BitLedger encodes double-entry records into fixed-width binary frames. Each frame carries:
The protocol enforces conservation at the encoding level. A BitLedger frame that does not balance cannot be constructed — the format itself prevents it, the way a physical scale prevents you from removing weight from one side without adding it to the other. This is not a validation check that runs after encoding; it is a structural property of the encoding.
Error handling is built into the frame structure. CRC validation ensures transmission integrity. The format supports forward error correction for hostile transmission environments — degraded radio links, noisy satellite channels, store-and-forward networks with unpredictable latency.
The protocol is domain-agnostic in principle. While designed for financial transactions, the same conservation guarantee applies to any domain where quantities must balance: inventory movements, energy budgets, resource allocations, material flows through a manufacturing process.
Double-entry bookkeeping is 600 years old. It is the most successful information technology in human history — older than the printing press, more widespread than any programming language, more reliable than any database. Every business on earth uses it.
Yet the digital encoding of double-entry records has never been standardized at the protocol level. Financial data moves as CSV files, JSON payloads, XML messages, or proprietary binary formats controlled by individual vendors. The balance invariant — the entire point of double-entry — is checked by application logic, not enforced by the wire format.
BitLedger exists because the most important structural property of financial records should be guaranteed by the protocol, not hoped for from the application. And because that protocol should be small enough to work on the channels the working world actually has — not just the fiber-optic links between data centers.
When a cooperative in rural Kenya sends a transaction record over SMS, or a field office in northern Canada logs an expense via satellite burst, the protocol should guarantee that the record is structurally sound before any application touches it. BitLedger provides that guarantee in 40 bits.
BitPads is a universal binary communication protocol. It encodes structured records — from a single heartbeat byte to a fully identified, timestamped, valued, tasked, and annotated civilisational record — in as few as one byte.
BitPads is not hardware. It is not a device. It is a protocol: a specification for how to encode, transmit, and decode structured information across any channel, including channels too constrained for JSON, XML, or even CSV. SMS messages, satellite links, sub-GHz radio, KaiOS feature phones, low-bandwidth field operations across sub-Saharan Africa — BitPads works where other formats cannot fit.
BitPads sits as a meta-layer wrapping BitLedger (the double-entry financial transmission protocol) and providing mode declarations, type identification, and enhancement commands that extend any base record with additional structured data.
BitPads uses an 8-bit meta layer that declares the mode and type of each frame. A frame is the fundamental unit — a self-contained binary packet that carries a payload and enough metadata to be independently verifiable.
The protocol operates across a frame spectrum: different packet structures for different purposes, from a 1-byte heartbeat (alive signal) through compact sensor readings, financial transactions, task records, and fully annotated compound documents.
Key architectural elements:
The protocol is designed for conservation: the same structural guarantees that apply to financial double-entry (nothing created or destroyed without a balancing counterpart) apply to any domain — spatial coordinates, IoT telemetry, manufacturing records, agricultural data.
A companion CLI tool (bitpads-cli) provides decoding, inspection, and validation of BitPads frames, with a separate assembly encoder for constructing frames from human-readable input.
The world runs on text formats — JSON, CSV, XML — that were designed for machines with abundant bandwidth, storage, and processing power. But much of the working world does not have those luxuries. A sensor on a remote pipeline, a feature phone in a rural market, a satellite uplink with 30 seconds of window — these channels need a format that respects their constraints.
BitPads exists because structured communication should not require structured luxury. A protocol that can encode a complete financial transaction in 40 bits, or a full operational record in a few hundred, opens channels that text formats cannot enter.
The protocol also exists because Babb believes the encoding layer matters for durability. Text formats are ambiguous, version-dependent, and brittle across decades. A binary protocol with a fixed, formally specified structure can be read in 50 years by any system that has the specification — no parser updates, no library dependencies, no format migrations.
bitpads-cli — decoder, inspector, validatorClarkware is the Clark Industrial Process Environment — a manufacturing facility operations platform. It gives technicians, supervisors, and integrated tools a unified interface for tracking jobs, managing notes and communications, flagging issues, and running AI-assisted workflows, all in real time across a connected facility floor.
What a technician sees when they sit down at a Clarkware workstation:
Clarkware targets the underserved middle market between heavyweight ERP systems (SAP, Oracle) and the disconnected tools most small-to-mid manufacturers actually use (spreadsheets, group chats, whiteboards).
Clarkware is a Turborepo monorepo with two applications and eight shared packages, all written in TypeScript.
Applications:
apps/api — a Fastify REST + WebSocket backend on Node.js. Handles authentication, job management, notes, issues, AI routes, artifact management, and real-time event streaming.apps/ipe — the workstation shell, built on Eclipse Theia. A browser-based IDE-like environment with React 18 widgets for jobs, notes, conversations, and AI tools.Core packages:
@clark/core — domain types, enums, events, identity. Zero runtime dependencies.@clark/db — PostgreSQL connection pool and query helpers.@clark/identity — JWT authentication, Argon2id password hashing, RBAC permission checking.@clark/events — append-only domain event store with optimistic concurrency.@clark/ai — Anthropic Claude integration for summarization, note drafting, alert routing, state review.@clark/storage — MinIO S3-compatible object storage client for artifacts.@clark/messaging — XMPP client, MUC room manager, sync engine for facility-wide communications.@clark/sync — offline-first conflict handler and sync queue.Infrastructure:
Authentication uses JWT with RBAC enforcement on all protected routes. Every job state transition, every note revision, every AI invocation is recorded as a domain event in an append-only store.
Manufacturing runs on institutional knowledge — the kind that lives in a foreman’s head, in a technician’s notebook, in the shift handoff conversation that happens at 6 AM in a parking lot. When that knowledge is lost — when someone retires, transfers, or just has a bad day — the facility loses capability that took years to build.
Clarkware exists to capture and preserve that knowledge as structured, searchable, permanent operational memory. Not as a replacement for the people who hold it, but as a system that ensures their observations, decisions, and reasoning survive their shift.
The AI integration is not a gimmick. A technician who has spent 30 minutes troubleshooting a furnace does not want to write a report. But they will say “flag this, bearing noise on unit 4, same as last month.” Clarkware’s AI can take that sentence, attach it to the right job, draft a structured note, and route an alert — while the technician goes back to work.
The Eclipse Theia shell was chosen deliberately. Manufacturing workstations need to be robust, customizable, and capable of running for months without restart. Theia provides a plugin architecture that allows facility-specific tooling without rebuilding the core platform.
heybabb is a command-line companion for Babb Works. It answers questions about what Babb is building, explains how each tool works, and reports on current development activity — all from the terminal.
The commands:
heybabb greet Babb
heybabb tools list everything Babb Works is building
heybabb tool <name> full breakdown of a specific tool
heybabb now what the team is working on right now
heybabb version knowledge base build info
heybabb ask "<question>" ask anything in natural language
heybabb ask --ai "<question>" same, powered by Claude
Without --ai, heybabb answers offline from a compiled knowledge base — no network required. With --ai, it uses the Claude API for richer, more conversational responses grounded in the same knowledge.
heybabb is a Python CLI built with Typer and Rich. It ships with a compiled knowledge file — a JSON snapshot of all Babb tools, their status, architecture, and current development activity — built from the organization’s GitHub repositories.
The knowledge base is generated by the character system, a companion project that scans a GitHub organization and produces a structured knowledge file any CLI can consume. The generation is automated: point it at your org, it reads your repos, and it builds the knowledge. heybabb is the consumer; character is the producer.
Architecture:
tools, tool, now, ask, version, sync, vision)The offline-first design is intentional. A developer checking “what does BitPads do?” at 2 AM on a plane should get a useful answer without a network connection. The AI mode is for deeper, more conversational exploration when connectivity is available.
Developer documentation is where knowledge goes to die. READMEs get stale. Wikis get abandoned. Confluence pages multiply until nobody can find anything. The knowledge exists — scattered across 60+ repositories — but accessing it requires knowing which repo to look in, which file to read, and which section is current.
heybabb exists to collapse that search into a single command. Instead of navigating repos, you ask. Instead of reading READMEs, you get a synthesized answer. The compiled knowledge base ensures consistency — every answer comes from the same snapshot, not from whichever README was last updated.
heybabb also exists because Babb believes that every organization should be able to talk to itself from the terminal. The character system that powers heybabb is designed to work for any GitHub organization, not just Babb. Point it at your org, generate a knowledge base, build a CLI companion. The technology is not proprietary to Babb — the voice is.
character (knowledge base generator for any org)Outstack is an Alpine Linux derivative focused on two unified concerns: security and power management. It treats both as expressions of resource control — a component that cannot be power-gated is a component that cannot be isolated during a security incident.
The name comes from the northernmost exposed rock of the United Kingdom: permanently uninhabited, geologically stable, essential to the maritime definition of where Britain ends. It is the bedrock beneath everything. It has no residents. It is not optional.
Outstack is exactly that for the systems it runs on: the uninhabited, always-running bedrock that enforces the rules.
Four core tenets:
Kernel: Outstack tracks Alpine’s kernel source and layers a hardened configuration on top. No patching, no forking. KSPP essentials: stack protector, FORTIFY_SOURCE, hardened usercopy, SLAB freelist hardening, init-on-alloc/free, devmem/devkmem/kexec disabled. Per-board defconfigs (RPi4, iMX8, generic x86).
Security layers (boot to runtime):
| Layer | Mechanism |
|---|---|
| 1. Secure boot | TPM/eFuse root of trust, verified bootloader, dm-verity kernel |
| 2. Runtime integrity | dm-verity read-only root, IMA/EVM, immutable /usr, encrypted mutable /var |
| 3. MAC | AppArmor for process confinement + Landlock for self-sandboxing |
| 4. Network | nftables default-deny egress, WireGuard for all external comms, no listeners |
Power management (outstack-powerd):
A userspace daemon that reads power budgets from /etc/outstack/power.conf, monitors via powercap/RAPL, INA sensors, and SoC PMICs, and enforces budgets with configurable violation actions (throttle, power-gate, deny). Power domains receive individual budgets, governors, and idle timeout policies.
The critical innovation: power anomalies trigger security alerts. Unexpected power draw from a subsystem may indicate compromise. A compromised peripheral can be physically power-killed — not just software-disabled. Power state is included in attestation reports. This creates a security guarantee based on physics, not policy.
Five system operating modes:
| Mode | Trigger | Behavior |
|---|---|---|
| FULL | External power / >80% battery | Unrestricted |
| NORMAL | 60-80% | Normal operation |
| CONSERVE | 20-60% | Background limited |
| CRITICAL | 5-20% | Critical tasks only |
| EMERGENCY | <5% | Survival mode |
Execution gating: At exec() time, Outstack checks whether the current power mode permits the new process to start. In EMERGENCY mode, only CRITICAL-class processes execute. This is a scheduling primitive, not a firewall rule.
Image system: A/B rootfs partitions (dm-verity protected), recovery partition, encrypted data partition. Signed OTA updates with automatic rollback on failure. Profile-based builds: minimal, iot-sensor, gateway.
Package tiers:
| Tier | Source | Policy |
|---|---|---|
| Passthrough | Alpine direct | Trust Alpine, auto-update |
| Rebuilt | Alpine APKBUILD, hardened flags | -fstack-clash-protection -fcf-protection -fPIE, audit |
| Custom | Our APKBUILDs | Full control (outstack-init, outstack-powerd) |
Every existing approach to OS-level security focuses on software boundaries: access control lists, mandatory access controls, capability tokens, encrypted memory. These are essential. But they share a common vulnerability: a sufficiently privileged software actor can, in principle, bypass them.
Outstack adds a layer beneath software: physical power control. A hardware peripheral that is power-gated is not merely denied access — it does not exist as a computing entity. No software privilege escalation, no kernel exploit, no hypervisor escape changes this fact.
This creates a new class of security guarantee: resources isolated by Outstack are secure by physics, not by policy.
Outstack also exists because power management and security are, at the hardware level, the same problem. Both are about controlling which resources are available to which processes. Treating them as separate concerns — the way every other OS does — creates gaps. A device that can be software-disabled but not power-gated can still be exploited. A device that is power-gated cannot.
The aerospace heritage is deliberate. Outstack’s power model was inspired by RTG-powered spacecraft, where every milliwatt must be accounted across the mission lifetime. The same discipline applies to battery-powered industrial tools, remote field devices, and eventually to actual spacecraft running Telux nodes.
outstack-powerd internals, outstack-init specification, board-specific device tree overlays, CI/CD pipeline, attestation protocolSIMBA is a standard in the Babb family of protocols and specifications. It sits alongside BASICS (the business tool durability standard), BitPads (the binary communication protocol), and the Works compound standard as part of the broader architecture Babb is building for long-lived, interoperable business systems.
Details on SIMBA’s specific scope and obligations are forthcoming as the standard matures. This article will be updated as the specification develops.
SIMBA operates as a normative standard — a specification that conforming implementations must satisfy. Like BASICS, it defines testable obligations rather than suggested practices. The standard is maintained in the simba-standard repository alongside the core SIMBA project.
Further technical details will be published as the specification reaches its initial release.
Babb builds standards because standards outlast software. A protocol specification, clearly written and publicly available, can be reimplemented by anyone, on any platform, at any time. The software that implements it today may be replaced; the standard persists.
SIMBA exists as part of the commitment to building century-capable systems — tools and protocols designed to operate across major economic and technological shifts, not just the current product cycle.
simba-standard (in progress)