The Method That Was Already Built

On January 30, 2026, I was handed a list of 133 open roles at Ramp and about three hours of actual attention to spend on it. I did not skim. I ran a framework, named it in the piece I wrote that same day, and got from 133 roles to one S-tier fit, a Product Manager opening on the company's "New Bets" team, in under three hours of logged work. That part is not the point of this post. The point is what I called the framework, and what I said it was made of.

I named it ARCS. In that essay the letters stood for Assumption-Risk-Conviction-Signal, my own shorthand at the time, not the expansion the name carries now. But underneath the acronym I listed six operating principles, in order, with a plain definition for each: Traceability, Falsifiability, Explainability, Transparency, Composability, Interoperability. I was not describing a piece of software. There was no software. I was describing how I had just made a decision, by hand, in a spreadsheet and a browser, and naming the parts of it so I could do it again.

Here is what each of the six meant in that piece, stated the way I stated them then.

The essay itself claimed to demonstrate all six at once, marking each one inline as it appeared: a traceability note next to the 133-roles figure, a falsifiability note next to a 40% failure-rate estimate, and so on through the piece. It closed on a dated bet: if the article produced zero inbound interest by February 15, 2026, the hypothesis behind writing it in public would be considered wrong. I don't know how that resolved. It was a self-imposed date, stated as one, and I'm not asserting an outcome for it here.

What exists now, eight months later, is a mechanized decision pipeline: a receipt schema, a gate cascade that renders a decision GREEN, YELLOW, RED, or one of several other named states depending on how solid the conviction behind it is, and a standing rule that no merge, deploy, or publish counts as done until a receipt is logged against it, checked against what git and the deployment actually show. None of that existed on January 30. All six of it traces back to the same six words.

Traceability is now a literal field: every receipt this system logs carries a list of source references, and anything that can't be checked against real state goes in a column marked unconfirmed, never confirmed. Falsifiability is a write-lock: an irreversible decision requires a declared test before it can be committed to, not after. Explainability is a numeric score attached to a decision before it ships. Transparency is the receipt table itself, open to any verifier. Composability is a library of reusable decision components instead of one-off scripts. Interoperability is a numbering system that has to hold across more than one tool calling into the same ledger, or the numbers collide.

I am not claiming the engineering was planned from that essay. I'm stating the narrower thing, which is also the stranger one: the words match, in the same order, eight months apart.

Most of the time, a method gets built first and described afterward, in a changelog or a design doc that dresses up what the code already does. This ran the other way. The description came first, written under time pressure, about a decision that had nothing to do with software, and the description held up long enough that the system built later had no better words to use than the ones already on the page.

The method was not designed and then written down. It was written down, and then, eight months later, designed.

That ordering is not a claim about foresight. It's a claim about what was actually load-bearing in the January essay: not the job search, and not the 133-to-1 result, but the six words underneath it, which turned out to name something durable enough to survive being rebuilt in an entirely different medium without changing.