The Four Pillars

Every architecture decision in RSB is recorded as an ADR at adrs.rsb.sh, and those decisions directly shape the programming standards at standards.rsb.sh. But the decisions and the standards both rest on something more fundamental: these four pillars. The pillars hold up the foundation of everything RSB does. They are deliberately not specific — the ADRs and the standards are where the specifics live — what the pillars do is set the direction and keep the work stable as it grows.

So the pillars are not slogans, and they are not aspirations I hope to live up to later. They are the constraints I hold every decision against — every type, every API, every release. If a change strengthens one or more of them without weakening any, it is probably a good change. When a change appears to weaken one, that tension is not a verdict — it is a prompt to slow down and look closer. The pillars do not move, but I am not rigid about them either; building software is the art of balancing competing forces, and the honest response to that kind of tension is to review it and talk it through until I understand what is really being traded. The decision is not made by reflex — neither waved through because it is convenient, nor refused because it brushes against the philosophy. It is made by weighing what the work and its feedback loops are actually telling me against what the pillars exist to protect, and finding the balance between them.

These are my considered positions, not universal laws. Where a reasonable person might choose differently, I have tried to say so. The work is meant to make the case, not the manifesto.

Reliability — built in, not bolted on

Reliability is engineered, not asserted — it lives in the design, the logic, the failures, and the tests, not in good intentions.

Reliability begins before any code is written, in understanding how the system actually behaves — where it can fail, what it depends on, how its parts interact under load. That understanding is carried through every layer that can hold it: the design, where failure modes are anticipated rather than stumbled into; the logic, where invalid states are made unrepresentable rather than merely discouraged; the failures themselves, traced and handled until they are exhausted — because the successful path is never designed directly, it is what emerges once every failure flow has been accounted for; and the tests, where what the system claims is continually proven.

This is the foundational pillar: nothing else RSB builds matters if it is wrong, so reliability is settled first and everything else is built on top of it. In practice that means every error path is understood, tested, and accounted for, and every error is classified by the recovery action it calls for rather than the stack trace it leaves behind — because what a caller needs to know is what to do next, not where the failure happened to surface. When an error path genuinely cannot be exercised in a test, it does not get waved through: it gets a dedicated written explanation — what the error is, how to reproduce it or why it cannot be reproduced, and why no test covers it. And when the choice is between making something easier and making it more reliable, the pillar chooses reliability.

Accuracy — honest models, precise names

Every abstraction is a claim about the world — accuracy is the commitment to understanding that world and modeling it honestly.

Accuracy is the commitment to discovering the truth of a system and modeling that understanding faithfully in the code. It is not a demand to get it right the first time. Early models are often wrong, and being wrong while you are still learning a system is not a failure — it is how the understanding is earned. What accuracy refuses is the other thing: an abstraction that papers over a gap in understanding, one that is convenient precisely because it skips the work of actually grasping what it claims to represent. The goal is not to be right immediately, but to keep moving toward a faithful model — and never to pretend to an understanding the code does not yet have.

Accuracy works along three axes, and they reinforce each other. The first is that the model is faithful to how the system behaves — the understanding I keep refining. The second is that the words are faithful to what things actually are: a pixel is called a pixel, not a dot; linear RGB is not labelled sRGB; each thing is named with the domain's real, precise term rather than a near-synonym that happens to be at hand. A name is a claim as much as a type signature is. Call a pixel a dot and you have imported the wrong concept into every place that name appears — people reason about dots, build on dots, and inherit a misunderstanding that lives only in the vocabulary, never in the system. Precise naming is not pedantry; it is the difference between code that teaches the domain correctly and code that quietly miseducates everyone who reads it.

The third is the feedback loop that keeps the first two honest. A model is proposed, put to work, and measured against what the system actually does; where it diverges, that divergence is the signal to correct the model — or the name. Accuracy is not a state reached once and defended, but a commitment to running this loop, so that each pass leaves the code more faithful than the last.

Inaccurate abstractions compound. Downstream code inherits the lie without knowing it, builds on top of it, and eventually produces a failure that is harder to diagnose than it needs to be — the bug isn't in the code that broke, it's in the contract that was never true. So the first question I ask of any design is whether it represents the problem more accurately. A design that is convenient but inaccurate is debt; a design that is awkward but accurate is a signal that the vocabulary needs refining — not that accuracy should be relaxed to make the awkwardness go away.

Performance — fast, and measured

Speed is a design constraint, proven with benchmarks — not an optimization pass deferred to later.

Performance is the commitment to treat the user's time as something worth protecting. Speed is not a finishing touch applied once the features work; it is a design constraint, decided up front and held to evidence. A system is fast because it was built to be fast — because at each decision the cost in time was weighed and measured — not because someone went hunting for things to optimize after the fact.

This matters most at scale, which is where creative work lives. A delay that is negligible on a single operation becomes punishing when it repeats across a large body of work. Latency is cumulative, and cumulative latency is the line between a tool professionals trust and one they quietly abandon.

So performance is decided at design time, not bolted on afterward. Code that is correct and accurate but slow has still failed, because the resource the project exists to protect is the user's time. "We can optimize later" is the performance equivalent of "we can add tests later" — a decision to take on debt that compounds faster than it can be repaid. Measurement is performance's feedback loop: a benchmark is what turns a guess into a fact and a regression into a signal, and performance claims made without one are almost always wrong. So I measure first, decide second, and never ship a regression without understanding exactly what was traded and why.

None of this is the easy path, and I won't pretend it is. Building for speed from the start asks more than deferring it does, and there will be moments when the easy route is right there. But choosing the harder line is what makes the work stronger — and the people doing it stronger with it. The easy route is not the one you chose, if you are reading this.

Open and free — the tools and the work are yours

Professional-grade tools should be free and open, and the work made with them should stay yours — the whole stack, software and files alike, in the hands of the person using it.

This pillar is about independence, and it has two halves: you own the tools, and you own the work. The conviction underneath it is simple — a creative's ambition should not be gated by their budget. That professional-grade tools are expensive is an accident of how the industry funded itself, not a law of nature, and it quietly decides who gets to make serious work and who never gets the chance. Free, open tools remove that gate.

Free here means two things, and I mean both. Free as in price: the software costs nothing, so cost is never the reason someone cannot pick it up. And free as in freedom: you can use it, study it, change it, and share it, because the source is open. RSB Lab is released under the GNU GPL, version 3 or later — copyleft by choice. Anyone can use it for anything, commercial work included, and anyone can build on it; what no one can do is take what was given freely and fence it off again. Whatever is built from this work and shared stays as free as the work it came from. I know the argument that copyleft is freedom with conditions attached, and I read it the other way around: the condition binds the developer, not the user, and it binds them to exactly one thing — passing the freedom on. A permissive license trusts that nobody will rebuild the gate this pillar exists to tear down; copyleft makes rebuilding it impossible. For these tools, that guarantee is the point.

Blender is the proof that none of this is naïve. It settled the argument that free and open software can be professional-grade — not a budget alternative, but the tool serious people choose and a whole industry comes to depend on — and that a community can sustain it for decades. It is the north star: the standing evidence that you do not have to choose between free and serious, and the bar I am trying to clear.

Independence does not stop at the tools; the work is yours in the same way. Your documents live on your machine. You can work offline, indefinitely, with no loss of capability, and when the network is there it enriches the work without ever owning it — the local copy is canonical, and the cloud is a synchronized observer, never the source of truth. RSB's infrastructure never receives, processes, stores, or monetizes your data, your metadata, or your work; there is no background sync and no passive transmission of any kind. When you switch on a cloud or AI feature, your credentials go straight to that third-party service — RSB is never in the path between you and your data.

Owning your tools and owning your work are the same commitment seen from two sides: nobody gets to rent your craft back to you, lock you in, or take it away.

None of this is ever finished, and that is the design. Each pillar carries its own feedback loop: reliability traces failures until they are exhausted, accuracy measures the model against the system and corrects where they diverge, performance turns guesses into facts with benchmarks, and openness lets the work fund and grow the freedom that produced it. They are not four standards to satisfy and set down. They are four loops to keep running, and what they have in common is a direction: each pass through is meant to leave the work more reliable, more accurate, faster, and freer than the one before — never the reverse.