The Product
Solid is the software whose construction this lifelog narrates — the product that The Lizard, The Caffeinated Squirrel, and twenty-five episodes of The Solid Convergence were born to document. Solid is also an enterprise agent platform that does everything an enterprise platform is supposed to do — ingest data, enforce compliance, run AI agents, serve a web interface, manage workflows, and deploy to production — while doing none of the things enterprise platforms actually do, which is require a Databricks cluster, a Snowflake warehouse, a React frontend, a Python backend, a Kubernetes cluster, a service mesh, an API gateway, forty engineers, and a monthly AWS bill that could fund a small nation’s space program.
Solid is one binary. Written in Go. Deployed with scp to the customer’s own infrastructure — their AWS, their Azure, their data center. Storing compliance data in Parquet files that are never modified, queried through DuckDB projections that are entirely disposable, configured through Git repositories that are their own audit trail, and operated by half an engineer and eight hallucinations.
This is either impossible or inevitable. The Yagnipedia notes, with some bewilderment, that it appears to be both.
“One repo. One binary. Cobra subcommands.”
– The Lizard, The V3 Saga Final Chapter - Is It Fun To Fight Windmills
The Stack That Isn’t
The typical enterprise compliance platform requires what the industry euphemistically calls “infrastructure”:
| Component | Enterprise Stack | Solid |
|---|---|---|
| Data ingestion | Databricks cluster (47 nodes, $180K/year) | Go routines |
| Data storage | Snowflake ($300K/year) | Parquet files (free, immutable, on disk) |
| Query engine | Snowflake again (same bill, different line item) | DuckDB (embedded, zero-config, disposable) |
| Reverse proxy | Nginx + HAProxy + load balancers | Cloudflare free tier |
| Frontend | React (14,000 npm dependencies, 847MB node_modules) | There is no frontend |
| Backend | Python (312 pip dependencies, 4 virtualenvs, 1 prayer) | Go (one binary, zero runtime dependencies) |
| Deployment | Kubernetes + Helm + Docker + CI/CD + YAML (so much YAML) | scp and systemctl restart |
| Audit logging | Separate system ($$$) | Git. The config IS the audit trail |
| Team size | 40 engineers, 3 tribes, 1 architecture committee | 1 developer, 8 Claude instances, 2 cats |
| Monthly cost | $47,000 (conservative) | One Hetzner server (demo instance) |
| Response time | “it depends” (it’s slow) | 52ms for 25 compliance queries |
node_modules size |
Approaching heat death of universe | 0 bytes. There is no node_modules. There has never been a node_modules. |
The Squirrel once proposed adding React for “a richer user experience.” The response was to render HTML on the server using Templ and send it to the browser via HTMX and Server-Sent Events. The browser receives HTML. The browser displays HTML. At no point does anyone maintain a virtual DOM, reconcile a state tree, or npm install anything.
“There is no frontend. There is only HTML the server already rendered.”
The Data Pipeline, or The Three Lives of an Audit Log
Solid’s compliance engine — called Comply — ingests audit logs from Azure, Databricks, and similar services. The pipeline has three stages, each named for what the data is doing, not what the infrastructure is called, because naming infrastructure is how you end up with KafkaEventStreamProcessorOrchestrationService:
1. Arriving (JSON, volatile) – Raw audit logs land in a directory. The filesystem is the state machine. Deduplication is by filename existence. There is no cursor database to corrupt. There is no Kafka. There is a directory.
2. Stable (Parquet, immutable) – After a two-hour settling window, JSON is promoted to Parquet via atomic write (os.Rename()). Once written, a Parquet file is never modified. This is the source of truth. It will outlive the server, the company, and very likely the developer.
3. Compacted (DuckDB, disposable) – Three DuckDB files per project serve as query projections. They are disposable. They can be deleted and rebuilt from Parquet at any time. They exist purely for speed. They are the lens, not the truth.
THE FILE IS THE TRUTH
EVERYTHING ELSE IS A LENS– The Lizard, The Homecoming, or The Three Days a Palace Was Built From Markdown and SQLite
The Squirrel proposed Apache Kafka for the ingestion pipeline. Kafka requires ZooKeeper. ZooKeeper requires configuration. Configuration requires YAML. YAML requires a conference talk explaining why you chose it. The conference talk requires slides. The slides require a graphic designer. The graphic designer requires a MacBook Pro with 64GB of RAM running Adobe Creative Cloud, which has more dependencies than the Kafka cluster.
Solid’s ingestion pipeline is a directory, a two-hour timer, and os.Rename().
Twenty-five compliance queries execute in 52 milliseconds total against 40,000 events. That is approximately 2 milliseconds per query. The Squirrel’s Kafka cluster would still be negotiating its consumer group assignment.
The Deployment, or The Absence of DevOps
Solid deploys like this:
git push- Server pulls, builds, sets capabilities for port 80
systemctl restart solid
There is no Docker. There is no container registry. There is no Helm chart. There is no YAML file describing the YAML file that describes the deployment that describes the container that contains the binary that could have just been copied to the server in the first place.
Cloudflare sits in front for SSL termination. The firewall restricts port 80 to Cloudflare IP ranges. The binary serves its own static files. Monitoring is Prometheus and Grafana, bound to localhost, accessed via SSH tunnel when anyone cares to look, which is rarely, because the server runs at 3% CPU and has never once reorganized its keys at 3 AM.
The demo instance runs on a single Hetzner server. Customers deploy the same binary inside their own infrastructure — their AWS, their Azure, their data center. The sale includes free knowledge transfer to ensure the customer’s team can operate it independently. This is not generosity. This is self-preservation. Allowing riclib near a customer’s AWS console would be catastrophic — not because he would break anything, but because he would simplify it, and the customer’s forty-seven microservices, twelve Helm charts, and three redundant Redis clusters would not survive the encounter.
“The best deployment is one binary.”
– The Lifelog Manifesto
The Squirrel proposed Kubernetes. The Lizard did not respond. The Lizard was already on the server, which had been running for months, which had never been restarted by anything other than a human who chose to restart it, which is the deployment equivalent of a lizard on a warm rock — present, functional, blinking, and completely uninterested in your opinions about container orchestration.
Constraints as Architecture
The intellectual core of Solid is not a feature. It is an absence. The thesis: the best way to prevent errors is to make them impossible. Don’t validate – constrain.
| Constraint | What It Eliminates |
|---|---|
| Phone-width sidebar for admin UI | Complex features; if it doesn’t fit one column, the design is wrong |
| Server-side rendering only | Client state sync bugs, security surface, build pipelines, React |
| Single binary | Deployment complexity, Docker, Kubernetes, the word “orchestration” |
| Go language | Runtime type errors, formatting debates, dependency hell, node_modules |
| Git-backed config | Unaudited changes, configuration drift, the question “who changed this?” |
| Rigid domain pattern (types/store/handlers/views/register) | Architectural decisions, inconsistency, the Squirrel |
| File size limits (every file fits in LLM context) | Partial understanding, context overflow, the need to “understand the codebase” |
| Hash-chained workflow execution | Tampered audit trails, separate logging systems, compliance theater |
The constraints compound. The sidebar forces simple features. Simple features fit the domain pattern. Small domains produce small files. Small files fit in the LLM context window. The LLM produces correct code. Compiled code deploys as one binary. One binary serves HTML. No frontend means the server is truth.
This is not minimalism. This is not asceticism. This is the philosophy of a developer who wrote 488-byte bootblocks on The Amiga at age sixteen: find the algorithm that fits the constraint budget. “512 bytes per track” became “files that fit in a context window.” “Ship a bootblock” became “deploy a binary.” The boy grew up. Got gigabytes. Still builds as if he hasn’t.
“The best abstraction is the one you don’t think about.”
– riclib
The Origin Story
Solid was born on December 13, 2025, when V3 was abandoned after twenty-three episodes of fighting windmills – the reactive signal framework that was beautiful, correct, and wrong for the product.
V4 began with mkdir v4.
The methodology was cp -R – copying battle-tested V3 code rather than designing from scratch. In 48 hours: CSS design system, HTMX components, NATS server, OIDC authentication, and a login page. The Squirrel proposed a clean-room rewrite. The Lizard proposed copying what worked. The Lizard was already copying what worked while the Squirrel was still formatting its proposal.
“V4 rises from these learnings. Clean. Boring. Solid.”
– The Lizard, The V3 Saga Final Chapter - Is It Fun To Fight Windmills
Over the following three months, the mythology unfolded: Poor Man’s Signals replaced client-side reactivity with HTTP headers. The Databases We Didn’t Built composed SQLite, NATS JetStream, and DuckDB instead of inventing custom storage. The Window That Opened Both Ways made markdown the universal interface. First Light gave Claude eyes to see the application it had built blind.
And on February 18, 2026, the Solo Developer ran eight Claude sessions simultaneously, producing 36 tickets in one week – a velocity that exhausted the backlog entirely by March 6. The bottleneck shifted from engineering throughput to human imagination.
The Squirrel, denied 54 times across all episodes, was told: “You were never wrong. Just early.”
The Sales Pitch
Solid sells itself as an audit intelligence platform – the thesis being that enterprises are drowning in logs but starving for intelligence. It sits atop existing infrastructure (Databricks, Oracle, Azure) and lets non-technical users query audit data in natural language.
The one-liner: “Solid turns compliance from a cost center into competitive advantage.”
The onboarding manual – written by Solid itself after interviewing the salesman about his professional history – explicitly warns against the Oracle comparison: “This is not Oracle 2.0.” Solid augments rather than replaces, deploys in weeks not years, and follows a land-and-expand model rather than maximizing Year 1 deal size.
The proof-of-value is 30 days. The sales cycle is 12-16 weeks. The salesman – a former Oracle GM – spent an hour with the product, received a 17-page personalized sales bible, and then asked for a demo. He had been sitting inside the demo the entire time. His espresso had gone cold.
“The product assigns him homework before he’s agreed to work there.”
– The Closer, or The Afternoon the Product Interviewed Its Salesman and Gave Him Homework
The Hash Chain, or Why Compliance Officers Sleep at Night
Every workflow step in Solid is a block that references the previous block’s hash. The execution history is a cryptographic chain – no block can be removed, reordered, or modified without detection. Agent decisions include reasoning, not just outcomes.
The workflow execution IS the audit trail. There is no separate logging system. There is no compliance theater where you maintain a second set of books that claims to record what the first set of books actually did. The chain is the record. The record is the chain. The auditor can verify it without trusting the database, because the auditor can verify it from raw Parquet files – 85x slower, but that’s the point. The slow path exists to prove the fast path isn’t lying.
The Squirrel proposed a ComplianceEventStreamAuditTrailOrchestrationServiceWithGracefulFallback.
The hash chain was already running.
The Databases Solid Didn’t Build
On January 25, 2026, the Squirrel arrived with blueprints for SolidMemDB. Three-layer storage. Custom indexes. A QueryPlannerWithCostEstimation. A TemporalIndexWithVersioning.
The response was to compose four existing technologies, each boring, each battle-tested, each doing exactly one thing:
- NATS JetStream – hot storage (30-day retention, real-time pub/sub)
- SQLite – per-user conversation stores (append-only, forever)
- DuckDB – analytical queries (embedded, zero-config, disposable projections)
- Parquet – immutable source of truth (write-once files, never modified)
Three thousand lines of composition replaced thirty thousand lines of invention. The QueryPlannerWithCostEstimation was rendered unnecessary by the observation that DuckDB already has a query planner, written by people who have spent years on it, benchmarked against terabytes of real data, and available for the price of embedding a library.
“Just Go, SQLite, and stubbornness.”
– riclib, The Databases We Didn’t Build
The Three Personas
Solid is one binary with three faces:
solid– the enterprise agent platform (Comply, workflows, AI agents)solidagent– the edge agent (runs at customer sites, phones home)lifelog– the personal journal and task system (the ancestor, the prototype, the garage)
One codebase. One go build. Three deployment targets. The Squirrel proposed separate repositories. The Lizard proposed GOOS=linux go build -o solid. The binary does not care which name you gave it. It checks os.Args[0] and becomes the appropriate persona. This is the Go equivalent of a lizard that is also a binary that is also three products.
The AI That Built Itself
Solid’s codebase is designed not just by AI but for AI to keep building. The domain pattern – types, store, handlers, views, register – is a template the LLM replicates. CLAUDE.md files in every directory onboard the AI contributor. File sizes ensure full context. The architecture IS the prompt.
In “The Rain in Lisbon,” at 4 AM in his mother’s kitchen, riclib and Claude built the skills domain. The agent read its own conversation history, identified its failures (including hallucinating “radar” charts that didn’t exist), and proposed its own training curriculum. Three skills were written. The domain shipped in 1,241 lines. It worked on first try.
riclib’s mother asked if this was the same thing he did at age six, narrating his school day to toys. “Same thing. Different vocabulary.”
The endgame vision: configuration through conversation. The domain pattern is so regular that eventually an agent that understands it can scaffold new domains. A consultant sits with a customer and talks to Solid: “Connect to the SCADA system. Create a skill for contamination investigation. Set up alerts when pH readings leave this range.” The boundary between configuration and programming dissolves. The Squirrel proposes a ConversationalConfigurationOrchestrationFrameworkWithSemanticScaffolding. The boundary dissolves anyway.
Measured Characteristics
- Binaries produced by
go build: 1 - Personas served by that binary: 3
- Frontend frameworks: 0 (there is no frontend)
- npm dependencies: 0 (there is no npm)
- Python dependencies: 0 (there is no Python)
- Docker containers: 0
- Kubernetes clusters: 0
- Reverse proxies: 0 (Cloudflare)
- Compliance queries against 40K events: 25, in 52ms total
- Parquet files modified after writing: 0 (immutable, forever)
- DuckDB projections rebuilt from scratch: trivially (they’re disposable)
- Deployment method:
scpandsystemctl restart - Monthly infrastructure cost: less than a conference ticket
- Team size: 0.5 engineers + 8 Claude instances + 2 cats (1 Maine Coon, 1 stare-based QA)
- Squirrel proposals declined: 54 (across 25 episodes)
- Squirrel proposals that were right but early: 54
- Time from
mkdir v4to exhausting the backlog: 83 days - Windmills fought: zero
