Business Assistance System
BASICS 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 not a branding layer and not optional philosophy. It is a commitments framework with testable obligations.
Just as BASIC expanded access to programming, BASICS expands access to business system building.
Most tool stacks optimize for stable broadband, modern hardware, large teams, and homogeneous deployment environments. Real operations frequently look different:
Without a shared standard, teams repeatedly solve the same problems in incompatible ways. The result is integration drag, brittle migrations, and operator lock-in.
BASICS addresses this by defining a common contract for command surfaces, records, interoperability, resilience, and lifecycle governance.
BASICS is:
BASICS is not:
The strongest argument for BASICS is operational continuity.
Organizations do not fail because they lack features; they fail when core records, commands, and workflows become unreliable, opaque, or non-portable across changing constraints.
BASICS prioritizes continuity by requiring:
BASICS helps teams build interoperable tools that preserve operator command and control, remain legible, and operate in constrained environments.
BASICS uses a layered architecture so products can implement only what they need while remaining compatible.
Conformance is intentional and progressive.
BASICS governance balances speed and stability.
BASICS requires verifiable artifacts:
workpads is the current proof system for validating BASICS behavior under real constraints.
Active drafting repository. v0.1.1 establishes rule identifiers, profile boundaries, and conformance structure. Future changes follow proposal → trial → review cycles. ```
I assumed:
/standards/*.md exists at repo root under standards/ADOPTION.md is root-levelIf your repo differs (e.g. docs/standards/ or spec/), these links should be adjusted.
If you want, I can next:
Most financial data formats were not designed from the ground up—they evolved through layers of abstraction, readability requirements, and system compatibility. The result is predictable: large payloads, heavy parsing, and application-level enforcement of accounting rules.
BitLedger takes a different approach. It defines a financial transaction at the bit level, encoding a complete double-entry record in:
40 bits (5 bytes)
No compression. No schema lookup. No ambiguity. Every bit has a fixed meaning.
Source code and full specification: → bitledger https://github.com/babbworks/bitledger
BitLedger is a binary-native financial transmission protocol designed from first principles.
It encodes:
…all within a fixed 40-bit structure.
The defining property is that double-entry accounting is enforced at the encoding level, not left to application logic.
A direct comparison highlights the difference:
| Format | Size (100 transactions) | Parsing | Accounting Logic |
|---|---|---|---|
| BitLedger | ~512 bytes | None (fixed positions) | Built-in |
| Fixed binary | ~2–5 KB | Schema required | No |
| CSV | ~10–20 KB | Required | No |
| JSON | ~50–200 KB | Required | No |
| XML | ~200 KB+ | Required | No |
The reduction is structural:
Decoding is deterministic: read bits → interpret directly.
Each transaction is split into two logical sections:
Includes flags for:
Includes:
This separation allows the protocol to represent both what happened numerically and what it means in accounting terms.
Instead of treating accounts as external labels, BitLedger encodes their relationship directly.
Examples:
This removes ambiguity and ensures consistency across systems.
BitLedger uses a split integer encoding:
N = A × (2^S) + r
Where:
A = primary value componentS = split factor (from session settings)r = remainderThis allows every integer in the range:
0 → 33,554,431
to be represented exactly.
A separate scaling factor extends this to real-world values:
| Scaling | Max Value (2 decimal places) | Step Size |
|---|---|---|
| ×1 | $335,544.31 | $0.01 |
| ×1,000 | $335M | $10 |
| ×1,000,000 | $335B | $10,000 |
| ×1,000,000,000 | $335T | $10M |
Maximum theoretical value:
~$33.5 quadrillion
All values are:
Rounding is encoded using dedicated bits:
| Bits | Meaning |
|---|---|
00 |
exact |
10 |
rounded down |
11 |
rounded up |
01 |
invalid (reject) |
There is no silent precision loss.
BitLedger operates within a structured transmission model:
Each layer is transmitted only when needed.
BitLedger combines multiple mechanisms:
Detects burst errors in session configuration.
Certain bits must match across sections. If they don’t, the record is invalid.
Some bit patterns are explicitly illegal (e.g., invalid rounding flag combinations).
At the batch level:
sum(debits) = sum(credits)
If this fails, the dataset is invalid—regardless of bit integrity.
Multi-step events are supported using a continuation marker:
A special account pair code (1111) links records together.
This allows:
without increasing base record size.
Control records use a distinct leading bit and provide:
All in a single byte.
Despite being binary, BitLedger can render into standard accounting format:
DEBIT Operational Expense 1,247.50
CREDIT Accounts Payable 1,247.50
This makes it suitable for:
without loss of fidelity.
The reference implementation is a Python CLI tool using only the standard library.
Capabilities:
Example:
bitledger encode
bitledger decode 04D00518 14
bitledger simulate --profile retail
Designed for:
Most systems treat accounting as:
data + rules applied later
BitLedger encodes it as:
data that already obeys the rules
This shift has practical consequences:
BitLedger starts from a minimal premise:
What is the smallest possible representation of a valid accounting transaction?
The answer—40 bits—produces a system that is:
It does not optimize existing formats. It replaces them with a structure where correctness is intrinsic, not enforced after the fact.
]]>Most communication protocols evolve incrementally—layered on top of older systems, shaped by compatibility constraints, and optimized for specific domains. BitPads takes a different route: it is designed from first principles, starting at the mathematical structure of information exchange itself.
At its core, BitPads asks a narrow but consequential question:
What is the minimum structure required to represent a meaningful exchange between entities?
The answer leads to a protocol that scales from a single byte signal to a fully annotated, multi-layered record—without changing its fundamental structure.
Source code and specifications: → bitpads https://github.com/babbworks/bitpads
BitPads is a binary protocol family where every transmission begins with a single byte: the Meta byte.
That byte tells the receiver:
This happens before any payload is read. There is no schema negotiation, no preamble scanning, and no ambiguity about how to interpret the data.
From that starting point, the protocol scales along a continuous spectrum:
| Size | Type | Description |
|---|---|---|
| 1 byte | Pure Signal | Heartbeat, ACK, status |
| 4 bytes | Anonymous Value | Context-bound value, no identity |
| 13–29 bytes | Full Record | Identity + value + optional metadata |
| 22–28+ bytes | BitLedger Frame | Complete double-entry transaction |
The structure does not change—only the attached components.
At the center of BitPads is BitLedger, a binary encoding of a complete double-entry transaction in:
40 bits (5 bytes)
This is not compression of an existing format. It is a direct encoding of the minimal information required for:
The key property: conservation is enforced structurally.
For any batch of records:
sum(flows) = 0
If this invariant fails, the protocol detects it immediately—before application logic runs.
Most existing systems for transmitting financial or resource-flow data fall into one of three categories:
This leads to duplication: each domain rebuilds similar logic with incompatible formats.
BitPads takes the opposite approach: it encodes the shared algebra directly.
Across domains, the same invariant appears:
These are not analogies—they are structurally identical.
BitPads encodes that invariant at the wire level, making it:
BitPads is organized into layered components, each optional and composable.
Applies to any conserved scalar:
The wire format remains identical. Only interpretation changes.
A typical full transmission includes:
Optional components (time, task, annotations) attach only when needed.
This results in a system where:
BitPads does not rely on a single checksum. It uses multiple layers:
This combination catches errors that traditional checksums may miss.
The gains are structural, not compressive.
| Format | Approx Size (100 transactions) |
|---|---|
| BitLedger | ~512 bytes |
| Fixed binary | ~3,000 bytes |
| CSV | ~15,000 bytes |
| JSON | ~80,000 bytes |
There is:
Decoding is deterministic: fixed bit positions map directly to meaning.
The reference CLI is implemented in:
Characteristics:
The CLI:
.bp binary outputsCurrently, it is encode-only.
Values are encoded as scaled integers:
N = A × 2^S + r
This guarantees:
The receiver can determine:
after reading only the first byte (and a few following bits).
Features like:
only exist when used. They do not inflate simpler transmissions.
The protocol can emulate legacy control streams (e.g., telegraph-style control codes), while embedding richer semantics in unused bit space.
Working:
Incomplete:
Instead of separate systems for:
BitPads offers one structure that applies to all.
Designed for:
The protocol enforces correctness:
BitPads is not an incremental improvement on existing protocols. It is a redefinition based on a single invariant:
Every meaningful exchange between entities follows a conservation law.
By encoding that invariant directly, the protocol achieves:
The result is a system that can represent anything from a heartbeat signal to a fully contextualized transaction—using the same underlying structure.
]]>In a world full of slick web dashboards and AI chatbots, sometimes the most powerful interface is still the one staring back at you in the terminal.
Company-Character is a system that gives your organization its own voice — right in the command line.
Point it at your GitHub organization, and it builds a branded CLI companion that truly knows your tools, your current status, your roadmap, and most importantly — how your brand speaks.
It works offline by default, optionally taps into Claude for more natural responses, and ships as a single compiled knowledge file. No database. No server. Just pure, controllable knowledge you own.
Three components work together seamlessly:
company-state/ ← Content & personality (what it knows + how it speaks)
+
GitHub org ← Your repos (scanned via API)
↓
cc-admin ← Private build tool
↓
company-cli ← The public CLI your team and users install
company-state/ is a simple folder of plain-text files containing your section mappings, brand personality, NOW.md, roadmap, and more. You edit these directly or through the admin tools.cc-admin is your internal command-line tool. It scans your GitHub org, parses READMEs according to your rules, applies overrides, and compiles everything into a single dist/knowledge.json file.company-cli is the distributable CLI. It reads the compiled knowledge and responds in your brand’s voice. You simply rename the entry point in pyproject.toml (e.g. heybabb, hey-acme, askwidget).Getting started is surprisingly straightforward:
cd cc-admin
python3 -m venv .venv && source .venv/bin/activate
pip install -e .
# Scaffold your company-state folder
cc-admin init
The init command will prompt you for your GitHub org name, brand name, and topic prefix, then generate all the necessary files and configuration.
Use GitHub topics to control what gets included and how deeply it’s scanned:
{prefix}-tool → Full deep scan (products and tools){prefix}-featured → Lead with these when listing tools{prefix}-vision → Strategic future work (not yet a product){prefix}-internal → Infrastructure only — brief mentionReplace {prefix} with whatever you set during initialization.
For best results, add consistent section headers to your repositories (fully configurable):
## What is it?
## The Problem
## How it Works
## Current Status
## The Vision
## Industry Context
The scanner automatically turns these into structured knowledge. Need different headers? Just edit company-state/section-map.yml or use the admin commands to customize.
cc-admin gives you full control over your knowledge base:
cc-admin init # Scaffold a new company-state
cc-admin scan # Scan GitHub org and parse repos
cc-admin build # Compile knowledge.json
cc-admin diff # Preview changes before publishing
cc-admin publish # Push dist/ to company-cli
cc-admin preview "query" # Test a question before shipping
cc-admin audit # Show build log
Advanced curation tools include:
cc-admin qa — Manage hand-crafted Q&A pairscc-admin override — Curate or suppress information per toolcc-admin lore — Inject company history and culturecc-admin announce — Pin announcements to the now commandcc-admin alias — Create alternate names and cross-referencescc-admin persona — Customize tone and add easter eggsOnce installed and renamed to your brand, users get clean, intuitive commands:
companycli # Friendly greeting
companycli tools # List all indexed tools
companycli tool <name> # Deep dive on a specific tool
companycli now # What the team is working on right now
companycli vision # Roadmap and strategic direction
companycli version # Build and knowledge version info
companycli ask "<question>" # Natural language (offline)
companycli ask --ai "<question>" # Claude-powered responses
companycli sync # Refresh latest GitHub signals
For more fluid conversations, use --ai:
export ANTHROPIC_API_KEY=your_key_here
companycli ask --ai "What makes your approach different?"
The entire knowledge base is passed as context, so responses stay grounded in your actual content and brand voice.
You don’t have to change your READMEs to control what the CLI says. Use overrides:
cc-admin override set bitpads status "Stable. Ships next week."
cc-admin override suppress bitpads context
cc-admin override embargo bitpads vision --until 2026-09-01
cc-admin override tone bitpads technical
This gives you fine-grained control without polluting your public repositories.
Beyond README parsing, you can enrich the assistant with:
company-character is a reference implementation, not a one-size-fits-all product.
It’s intentionally generic — no hardcoded organization names or brand text. Everything is driven by your configuration and company-state/ folder.
Fork it, rename it, and build your own branded CLI companion for your team, your open-source community, or your customers.
The live reference deployment is the Babb CLI (heybabb), built by Babb Works.
Want your organization to have a voice in the terminal?
Try the reference implementation today and start building your own company-character system.
Your tools deserve to speak with personality. Your team deserves an assistant that actually knows what’s going on.
Welcome to the age of the branded terminal companion.
]]>Most startup tooling assumes you’re already in motion—tracking tasks, managing teams, or reporting metrics. newent takes a different position: it focuses on the earliest stage, where an enterprise is still being defined.
This is a command-line tool designed to help you structure, explore, and evolve a business idea using a local-first, service-oriented system. It is opinionated in architecture, but flexible in usage.
newent Is (and Isn’t)At its core, newent is:
It does not try to replace spreadsheets, CRMs, or accounting software. Instead, it aims to give you a clear, composable foundation for thinking through an enterprise before those tools become necessary.
The system is built around a few strict principles:
Each concern is isolated into a service with defined boundaries. This enforces discipline early and prevents the tool from collapsing into a monolith.
All persistent data flows through a single service—the Store. Only this service reads or writes to SQLite, which keeps data access predictable and auditable.
Everything runs locally using SQLite. There is no dependency on network services, and no requirement for accounts or sync.
Cloud support is considered, but intentionally deferred.
The command-line interface is designed to be natural-first:
Example philosophy:
plan new and plan-new are both validThe system organizes enterprise information into a layered hierarchy:
Business
→ Plan
→ Section
→ Document
→ Heading
→ ContentItem
→ ContextItem
This structure enables:
Flexible referencing using compact or dotted addresses
3B2ai or 3.B.2.a.iUpper levels are stable, while lower levels remain more fluid and positional.
Additional first-class elements include:
Right now, development is centered on the Store service, which provides:
Key components:
models.py — shared data structuresservices/store.py — the Store implementationschema/001_initial.sql — workspace schemaschema/001_spaces.sql — groundwork for multi-space supportThe Store is foundational: all other services will depend on it.
The long-term design includes a set of focused services:
Not all of these are implemented yet, but the boundaries are defined.
newentSetup is intentionally minimal and avoids global system pollution.
python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
This gives you:
newent command on your PATH (while active)You can also:
./.venv/bin/newentpipxnewent --help
pytest -q
The CLI and module entry point are equivalent.
A defining characteristic of the project is that implementation follows design documents, not the other way around.
Key references include:
If code and documentation diverge, the documentation is considered authoritative.
This keeps the system coherent as it grows.
Most early-stage planning is fragmented:
newent attempts to unify this into a single, structured system with:
It is less about speed and more about clarity and integrity of thought.
newent is not trying to be broadly accessible or immediately polished. It is a deliberate tool for disciplined thinking about enterprises.
If you prefer:
this likely won’t fit.
If you want:
then it’s worth examining.
]]>From Rust Belt, to Kalahari, to the Cosmos, Babb builds tools for work.
Babb is an industrial software company and an open-source foundry. We build practical software, standards, and hardware-oriented systems that help people start, run, and grow real operations under real constraints.
We build for the working world: individuals, small teams, shop floors, farms, field crews, and industrial operators whose work cannot pause for fragile software.
Most business and productivity tools are designed for stable desks, stable teams, and stable conditions. Much of the world does not work that way.
People who operate businesses in dynamic environments still need:
Babb exists to help businesses start, operate, and endure, while keeping the core systems of work open and interoperable.
We build across a scope that starts with command-line and personal workflows, and scales up to industrial operations and standards.
The current flagship projects are:
heybabb and company-character represent the class of compact, high-utility tools we build for enterprise operations and contributor onboarding.
Babb follows a technical philosophy shaped by constraints, clarity, and long-term interoperability.
Babb is committed to keeping a permanent open-source version of every tool.
Commercial products and services may be developed around these systems, including cloud platforms, enterprise support, and hardware offerings, but core capabilities are developed upstream in open repositories whenever possible.
We treat open participation as infrastructure, not marketing.
Babb’s primary audience is contributors.
We welcome participation across:
Babb takes responsibility for maintaining core integrity across tools, while providing structure, governance, and contribution rules so community work can compound safely.
We are committed to affordable, widely available devices as first-class targets for work software.
This includes KaiOS-based mobile phones and similar low-cost devices in emerging markets. Babb will continue developing and shipping work applications that operate effectively on constrained mobile hardware.
We are entering a period of reindustrialization and renewed space-era systems building while traditional forms of hard work remain foundational: farming, fabrication, transport, repair, field service, and local trade.
Babb is building for continuity across these realities: old and new infrastructure, local and global markets, terrestrial and off-world operations.
Workwarrior, BitLedger, BitPads, Clarkware)heybabb and company docs*-standard repositories with versioning discipline and conformance guidancePrimary repositories and standards currently include:
Full org repositories: babbworks repositories.
Babb builds durable tools that help people and businesses lead, endure, and grow.
We serve the workers and economies of today and tomorrow with a timeless touch.
Getting a business launched requires tools, resources, and supports. Business owners are the ones who determine the markers of success, but the growth of sales is always required for survival. A business can be initiated and operated by people of all ages given timely access to personal assistance and education. Our electronic tools have become essential for day-to-day business and for extending access to commercial activity. However much we accelerate, though, our tools must harmonize with paper-based processes for communities that prefer such approaches. Looking out to the stars, the durable tools and technologies that can reliably operate far away are the same ones that can faithfully serve Earth’s remotest regions. From the Midwest to the Kalahari to the Cosmos, Babb exists to help people and businesses to lead and endure. We are devoted to the development of Babb and its planetary and galactic growth. This is our shared oath to take the common spirit of business up into orbit and beyond.
]]>Modern software for small teams often assumes ideal conditions—stable staffing, reliable connectivity, and time to manage accounts and tools before work begins. In practice, many field and trade environments operate without those guarantees.
Workpads is designed from the opposite starting point. It focuses on a single, durable unit: the job record—a compact, structured document that captures what happened, what needs to happen next, and why.
Typical tools expect:
Workpads assumes:
The result is a system optimized for immediacy and resilience, rather than feature depth.
Instead of spreading information across multiple systems, Workpads centers coordination around a single artifact.
A well-formed job record should:
If that unit is reliable, many secondary systems become optional.
Workpads structures each record using a compact schema called PADS:
This model is intentionally constrained. It is broad enough to represent real work while remaining lightweight enough to function on low-end devices.
Workpads is aimed at:
Common tasks include:
An effective Workpads interaction should be:
The emphasis is not on features, but on clarity under constraint.
Workpads follows a service-oriented model with thin clients:
Clients—CLI, browser, or mobile—interact through the same contracts.
The command-line interface is not secondary. It defines the system’s behavior.
Design rule:
This approach stabilizes the system early and simplifies future client development.
A canonical record follows the PADS structure:
{
"templateId": "svc-basic",
"variant": "plain",
"process": {},
"actions": [],
"details": "",
"story": "",
"comments": []
}
For sharing, this is compressed into a smaller payload suitable for URLs.
Templates define the shape of records and can be authored in:
Both compile into a normalized runtime schema. This allows:
Storage behavior is explicit and policy-driven:
Sharing is based on encoded links:
Workpads supports two conceptual modes:
Identity is minimal by design, with anonymous-first behavior and optional display names.
The CLI currently supports:
To maintain focus, several features are paused:
These are not rejected—only delayed until the core system is stable.
The project is available here: → workpads https://github.com/babbworks/workpads
From the project directory:
npm install
node ./workpads.js help
Example workflow:
node ./workpads.js template:validate --file ./templates/svc-basic.kv --format kv
node ./workpads.js create --template svc-basic --variant plain --set process.job="Replace faucet"
node ./workpads.js share --record loc_000001
Workpads is built on a narrow premise:
If the job record is clear, portable, and complete, coordination becomes significantly easier.
Rather than expanding outward into complex systems, it focuses inward—on making that single unit reliable.
]]>Accounting is one of the oldest structured information systems humans have built. Long before computers, the core problem was the same: record what came in, what went out, what is owed, and what is settled. BitLedger starts there, at that most basic layer, and asks what the minimum honest representation of a transaction looks like when expressed in binary.
The result is a 5-bit core entry. Three bits identify the account type, one bit captures direction, and one bit captures status. Combined with three additional flag bits, a complete and meaningful transaction record fits inside a single byte. A second byte handles sub-classification. The encoding favors zero for the most statistically common states, which reduces average bit weight across a ledger and marginally but consistently lowers the energy cost of storing and transmitting records at scale.
The practical motivation behind this compression is transmission efficiency. Standard accounting data formats carry significant overhead that is acceptable on reliable broadband connections but becomes a liability in constrained environments — rural or maritime mobile connections, mesh networks, or communications with remote hardware where every byte of a transmission carries a real cost. At sufficient distance, such as relay communications with off-planet systems, that cost becomes a hard constraint rather than a preference.
BitLedger is not a reimagining of accounting. It is an attempt to express what accounting already is, stripped to its structural minimum, in a form that remains fully meaningful while being as small as the logic will allow.
]]>Asking these kinds of questions brings the student of computing immediately back to binary and assembly language from which all other systems sprung. Even the Murray and Baudot and Morse codes were early binary protocols. Once you’re back there where it all began you’re reminded that that every bit is a potential flag or indicator of some sort. The ancient and timeless nature of making a set of marks for a receiver to interpret is what helps put back computing in its societal context. You start wondering what is communication and what does it mean to carry out an exchange across the ages. This brings us back to the rudimentary forms of civilization and begs the question: how can the way we treat information be timeless too? How do we marry the old with the new to create a persistent approach to the creation and transmission of records?
Bitpads is one attempt to answer these questions.
The system is based on a few first principle assumptions about human and machine to machine communication. These assumptions deserve their own post but for now we’ll keep the breakdown brief. We’ll stick to the bitpad architecture to lay things out and draw connections to society. So first, the main types of bytes and blocks of bytes for a bitpad transmission.
The protocol operates using a hard-coded set of sequences where each byte or set of bytes has pre-determined locations in the overall stream. Interpretation by the receiver relies on things staying the same each time, and numerous checks and confirmations are built-in to the flow of data to enforce these rules.
The anchor bye for the whole system besides Start of Header is the Meta Byte, or what we can label Meta Byte 1 since there can be a 2nd Meta Byte depending on the settings coded into MB1.
Meta Byte 1 has 8 individual bits, with bits 5-8 operating as a 4 x 4 matrix when MB1 Bit 4 is set to 1 (Catoegory Mode).
| Bits | Field | Values | Description |
|---|---|---|---|
| Bit 1 | BitPad Mode | 0 / 1 | 0 = Wave mode (lightweight). Layer 1 not required unless category demands it. Bits 5-8 role determined by Bit 4. 1 = Record mode (full BitPad). Meta Byte 2 always follows. Layer 1 is always expected. |
| Bit 2 | ACK Req / SysCtx | 0 / 1 | Dual-purpose field: • When Bit 1 = 0 (Wave): 1 = ACK request. A single byte with only Bit 2 set ( 0x02) is the universal pulse.• When Bit 1 = 1 (Record): 1 = System Context Extension follows Layer 1. |
| Bit 3 | Continuation | 0 / 1 | 0 = Complete, self-contained message. 1 = Fragment. More BitPads follow for the same logical unit. Universal across both Wave and Record modes. |
| Bit 4 | Treatment Switch | 0 / 1 | Wave mode only: • 0 = Basic treatment (Bits 5-8 are Role A descriptors). • 1 = Category mode (Bits 5-8 become Role B 4-bit category code). Ignored in Record mode. |
| Bits 5-8 | Content Field | varies | Role depends on Bits 1 and 4: • Role A (Bit 1=0, Bit 4=0): Priority / Cipher / ExtFlags / Profile flags. • Role B (Bit 1=0, Bit 4=1): 4-bit category code. • Role C (Bit 1=1): Value / Time / Task / Note expect flags. |
In the BitPads transmission spectrum, a 1-byte Pure Signal is the smallest and lightest possible message type. It consists of only Meta Byte 1, with no content, no Layer 1, no Meta Byte 2, and no additional payload.
This is explicitly supported in the protocol:
| Size | Type | Structure |
| 1 byte | Pure Signal | Meta byte 1 only. The byte IS the message. |
We are returning to an era where hardware determines compute but on new terms. Whereas the early days were marked by packing transistors to shrink operations, the new explosion of pervasive compute is about matching processes with the right product. Just at this moment when computers are dematerializing knowledge work they are beginning to materialize or cause to exist countless more machines and smart devices that will be transforming the appearance, culture and operations of earth, the moon and beyond.
As upheaval comes to every industry, as it cyclically has in history, there are times when man must pause and inquire what work is worth pursuing now? And given the new conditions for society, what kinds of pursuits have become newly possible? Comparative advantage? Invisible opportunities? If the puck is moving as fast as many say it is then we should honestly view our early pursuits as a company or as an expert as simply bridges through to the higher sustained orbit which we sense is reachable but also necessary for survival. Orbit or obsolete.
It is not specific jobs or industries which are now setting, it is a whole broad set of civilizational assumptions which are being overturned, sifted, and re-stated all at the same time. A highly ancient and astoundingly novel environment for human life seems to be emerging where emphasis will be on the fundamental building blocks of existence, from the rural village up through to lunar landscapes.
Coupled with the need to keep living is our renewed need to keep producing and also creating novel solutions to the insatiable impulse to produce. Solutions which can extend and expand opportunities for living in old and new places. The arm became augmented by the windmill, by steam, coal and then by our system of wires. Now, as the coal empires find new footing, AI is empowering vast new possibilities for society and industry. Democratized expertise is enabling millions of minds to channel wind at the sails adding to the directs that everything is taking.
The goods and services needed for life and work in all there aspects are if anything exploding. Meanwhile the leveers to directly influence and intervene in the new great experiment, though seemingly countless, are but few in number when looked at from a physical standpoint. The opportunity for Babb and new companies like it centers on a simple level poorly understood by the public but of foremost priority to today’s engineer, the microcontroller or in common terms as it will surely be forever known, the microcomputer.
]]>