)
On this pageA good idea on paperWho pays the complexity taxWhere modularity belongsThe shifting shape and rhetoric of modularityThe builder-user gap
A good idea on paperA few years ago, if you were paying attention to the rise of CDR-native registries, you probably kept hearing the same word: modular. The pitch was legitimately compelling, and I bought it when I first heard it. Writing methodologies is slow, expensive, and repetitive work. A huge fraction of what goes into any given CDR methodology looks more or less the same across pathways. How to source biomass, account for lifecycle emissions, handle leakage, quantify uncertainty—they don’t vary widely. Why not write those components once, as clean reusable modules, and snap them together differently for biochar, BECCS, BiCRS, enhanced rock weathering, and whatever comes next?Every engineer I know would look at that and nod. It's how you build software. It's how you build anything you expect to scale. The alternative—writing each methodology as a single giant standalone document that repeats the same biomass-feedstock rules and the same LCA boilerplate in slightly different words every time—looks wasteful and brittle by comparison. Bespoke and expensive methodologies at legacy registries was a huge problem, and new players were sure to point to that issue.Newer registries made modularity a central part of their pitch to buyers, investors, and the serious methodology-assessors at places like ICVCM and Microsoft. The story was that modularity would let them move faster, maintain consistency across pathways, and produce a higher-quality standard with a smaller team. Rainbow went the same direction, building its biochar methodology as a module underneath a broader "BiCRS" methodology, with the expectation that the biomass-feedstock logic would be cleanly reusable across technologies.And then something interesting happened. They started walking it back. Not all of it, and not loudly. But the architecture of the methodologies that are actually being written is shifting.
Who pays the complexity taxI sat down with Rainbow's Erica Dorr and Clément Georget to try to understand why. Erica leads methodology development. Clem leads product. Their explanation is among the most honest I've heard anyone in this industry give about a design decision that didn't work out the way they hoped."Our dream was to have these cleanly defined little building blocks that are modules, that are totally reusable, plug and play," Erica told me. "It was all very promising." The problem wasn't the dream. The problem was that when you actually write a methodology as a set of modules, the neat edges between them dissolve. Every module turns out to have exceptions, caveats, technology-specific tweaks, edge cases that don't quite apply to the next pathway over. So you need a second layer of requirements somewhere–as caveats or exceptions written directly into the modules, or in a methodology document on top of the modules—to say which modules apply, which ones have carve-outs, and how those carve-outs interact. Pretty soon the reader is chasing requirements across three documents and a footnote.And that, if you think about it, is the exact experience the modular approach was supposed to prevent.Clem framed it in the language he actually thinks in, which is software engineering. "It's really like software development," he said. "Who do you want to expose the complexity to? Who cares about the modularity is us, because we have to maintain this code base. The user doesn't care. They just want to go through the requirements."That's the thing the original pitch missed. Modularity on the backend is a good idea for almost exactly the reasons it sounds like a good idea. But modularity on the frontend—modularity that the reader of the methodology has to reassemble in their head—is a tax the reader pays. And the reader is a project developer trying to figure out whether their site meets the bar, not a software architect who finds the elegance rewarding.
Where modularity belongsThe analogy that came to me while I was listening to them was Judaism. You have the Torah, one of the core texts and the document the tradition is built around. Then you have the Talmud, which is the commentary, the arguments, the exceptions and rulings and edge cases that the tradition accumulated on top of the Torah over centuries. Both are load-bearing. If you really want to understand Judaism you need both. But you don't hand someone the Talmud on day one.A modular methodology stack, done badly, is kind of like handing a project developer the Talmud and the Torah at the same time and telling them to cross-reference. The expert who wrote it can navigate it fine. They wrote it. The developer who just wants to know "does my closed-kiln biochar site in India qualify, and what do I have to measure?" is drowning.What Rainbow is doing now, and what Erica and Clem both described as the corrective, is keeping the modularity where it does real work, which is internally, and presenting the user with a single self-contained document that has everything they need in one place. "For them, it should read like a step-by-step; a single, self-contained document with everything they need," Erica said. "We shouldn't make it the user's problem to go find which document has the requirements." The modules still exist on Rainbow's side. They still power the certification platform, the lifecycle assessment tooling, the eligibility questions. That's where the scaling benefit was always real. It just turns out that making the modularity visible to the reader was a different decision from making it exist at all, and it was the wrong one.
The shifting shape and rhetoric of modularityThe braggable rhetoric of modularity has waned since its peak. It’s hard to say if that reflects a departure from modularity, a shift in how registries define and implement modularity, or an evolution in how modularity is experienced by developers. It may be a mix of all of them.What I find admirable about how Rainbow handles this change in the meta-methodology is that Erica and Clem just told me about it. There was no spin. No cliche "we're evolving our approach." They said: the dream was elegant, the reality was confusing for users, we're changing it, and the reason we're changing it is that we were optimizing for the wrong person. You don't hear that kind of honesty from institutions very often, and you almost never hear it from institutions that are still small enough that admitting a mistake could be read as weakness by potential buyers.
The builder-user gapThe part of this I keep coming back to is not actually about methodology writing. It's about what happens when a good engineering idea collides with a human reader. This isn’t by accident. It’s what Rainbow is aiming for as a developer-centric registry.These tensions between stakeholders, and the persistent awareness that “you are not your customer,” requires continuous self-examination and stress-testing. We have explored these themes in several recent blog posts and a podcast on the tensions between commercial, scientific, and engineering teams within carbon dioxide removal. These clashes are common enough to be archetypal for anyone trying to commercialize climate tech.Modularity is an abstraction. Abstractions are useful right up until the point where the cost of maintaining them is paid by somebody other than the person who designed them. Rainbow's rethinking of visible modularity is, in a way, a small piece of product management wisdom delivered to a field like registry design, which historically has not thought of itself as being in the product management business.Modularity is a tool, and tools are judged by how well they accomplish a task. They aren’t good in and of themselves. If the cost of the tool is too high for the user, or just doesn’t do the job well, then it is time to find a different tool. Rainbow’s awareness of and adaptation to the fact that their initial tooling wasn’t the right fit for the job is the kind of learning in public I like to see from the institutions I support. Honesty builds trust. And I think the carbon industry could stand to see a whole lot more of it.