Fifty-four components went into the review. Twenty-one came out killed.

Not deferred to a later phase, not descoped to a smaller version, not parked behind a flag. Removed from the plan on the grounds that building them would be worse than not building them — and in most cases substantially worse, because each one would have consumed effort to produce something less capable than a thing that already exists and is given away.

FIGURE 1 · DISPOSITION OF FIFTY-FOUR COMPONENTS The largest column is the one that ships nothing. KILL 21 duplicates mature OSS, or serves no thesis MERGE 17 absorbed into one of six consolidated products RE-SCOPE 10 survives with a materially narrower charter ADD 6 genuinely unclaimed — no existing implementation anywhere KEEP 4 survives essentially intact SPLIT 2 one half killed, one half survives The flaw was never ambition. It was spending most of the surface area re-implementing primitives the open-source ecosystem had already contributed, tested at scale, and given away. Twenty-one kills is the measure of that flaw. Removing them is what made the remainder buildable.

The kill column is the largest, and a reader is entitled to be suspicious of that. A portfolio review that ends by cancelling most of the portfolio is either a serious act of judgement or an admission that the portfolio was never real. This piece is the argument that it was the first, together with enough of the working that a reader can decide it was the second.

The pattern all twenty-one shared

The kills were not spread evenly across a spectrum of quality. They clustered, and the cluster has a name: each component wrapped mature open-source infrastructure that the system should call rather than re-implement.

FIGURE 2 · THE SUBSTITUTION LEDGER Every row is a project that would have been worse than what it replaced. WHAT I KILLED WHAT I CONSUME INSTEAD A bespoke sandbox runtime WASI runtimes, gVisor, Firecracker — behind one adapter trait The identity half of the identity plane SPIFFE / SPIRE, a graduated CNCF project, plus Cedar only the delegation-chain intersection survives — nobody else builds it A bespoke safe-tensor post-processor Safetensors + OpenSSF Model Signing — in production, signed at source A bespoke policy evaluator Cedar and Open Policy Agent A bespoke transparency log Sigstore and its transparency log A bespoke attestation verifier IETF RATS architecture with an existing verification project A bespoke red-team harness Established open red-teaming and evaluation frameworks The defensible novelty is unification, not invention. Saying so is what makes the unclaimed work credible.

Read that ledger with a specific question in mind, which is not whether the substitutions are reasonable. It is whether, for each row, my version would have been better in any dimension that matters.

For the sandbox runtime, no. Isolation is a domain where the value of an implementation is almost entirely a function of how many adversaries have attacked it. A new sandbox is a sandbox nobody has tried to escape. Consuming established runtimes and demoting the whole area to a backend adapter trait means the isolation property comes from projects that have absorbed years of attention, and my surface reduces to selecting and configuring them — which is the part that actually goes wrong in deployments anyway.

For the identity plane, no — but only half of it. Workload identity is solved. SPIFFE and SPIRE are a graduated project with production deployments at a scale I will not reach, and a bespoke workload-identity implementation would be a liability the day it shipped. What is not solved, and what nobody else builds, is computing effective authority along a delegation chain as the meet of every link's capabilities. So the identity half was killed and the intersection engine survived. That split is the single most useful decision in the review, because it separates a component that sounds novel from the part of it that actually is.

For signing, transparency and attestation, emphatically no. These are domains where interoperability is most of the value. A bespoke signing envelope is not merely redundant; it is worse than redundant, because it forfeits every existing verifier. An auditor with tooling that already understands the standard envelope can answer questions about my artefacts without understanding my system at all. A bespoke encoding would have thrown that away in exchange for nothing.

Why duplication is worse than waste here

The ordinary argument against reinventing infrastructure is about cost: you spend effort on a solved problem and end up behind. That argument is correct and it is not the argument I want to make, because it applies to any project and explains nothing specific about this one.

The specific argument is about what the layer claims to be. The claim is that it binds the outputs of many systems — identity, policy, signing, attestation, isolation — into one non-bypassable, signed decision. The novelty is the binding.

A binder that also competes with the things it binds is arguing against itself. If I ship my own policy evaluator alongside a claim that I compose the outputs of policy evaluators, I have asserted that the existing evaluators are inadequate. That is a coherent position, but it is a different product — a replacement rather than a substrate — and it is a much harder one to defend, because now every conversation is a comparison against a mature project on its own ground rather than a conversation about a gap nobody is filling.

So the twenty-one kills are not a concession made for schedule. They are what makes the remaining claim sayable. And the converse holds: the six additions are only credible because the kills happened. A portfolio that claimed six genuinely unclaimed pieces while also re-implementing seven mature ones would have had no way to distinguish its real novelty from its noise, and neither would a reader.

This is the same discipline the field report on defect classes applies to claims, pointed at scope instead. There, an artefact should not assert more than it can evidence. Here, a portfolio should not contain more than it can justify. Both are the same refusal to let a comfortable sentence stand in for a checked one.

What consumption actually costs

Every piece of writing that recommends consuming open source rather than building stops at the recommendation, which is why the recommendation is easy to give and often goes badly. The costs are real and they are not the ones people expect.

  1. Every consumed project is a dependency with its own release cadence, its own security posture and its own governance. Killing seven components did not remove seven risks; it converted them into seven relationships, and a relationship can make a decision that does not suit you.
  2. Adapter traits leak. The sandbox-backend abstraction is honest right up to the point where two backends have genuinely different security semantics, and then the abstraction is either lying about one of them or has grown a configuration surface that reintroduces the complexity it was supposed to hide. I have not solved this. I have made it visible, which is less than solving it.
  3. A mature project can be the wrong shape. Maturity means a project has made choices and lived with them, and one of those choices may be exactly wrong for a deployment topology it never anticipated. Consuming means inheriting choices, and the inherited choice you disagree with is not negotiable on your timeline.
  4. Version skew becomes a security property rather than an operational annoyance. When the thing you consume provides an invariant you rely on, an upgrade that changes that invariant is a security change wearing the clothes of a dependency bump.

None of these outweighs the case for consuming. All of them are the actual work, and a report that listed the kills without them would be selling a decision rather than describing one.

The dangerous failure mode of this discipline

Here is the part I would flag hardest, because it is the failure I am most likely to commit and the one this piece makes more likely by existing.

A team that has internalised "consume, don't reinvent" will eventually consume something that does not do the job. The mechanism is social rather than technical: after twenty-one kills, consuming is the move that feels rigorous and building is the move that requires a defence. So the question quietly shifts from "does this project provide the property I need?" to "is there a project in roughly this area?" — and those are very different questions with the same shape.

The test that catches it is specific rather than general. Name the property you need, in one sentence, before looking at what exists. Then check whether the candidate provides that property or provides something adjacent to it. Adjacent is the failure. A red-teaming framework that generates adversarial inputs is adjacent to, and not the same as, a conformance suite that establishes whether a stop control actually stops things — and treating them as interchangeable because both are in the safety-testing area would have killed something that needed to exist.

Two of the six additions survive precisely because that test was applied and nothing suitable was found. Not because they were exciting, and not because they were mine. Because the property was named first and nothing provided it.

I would rather state this asymmetry plainly than let the twenty-one kills imply a general rule. The rule is not that building is suspect. The rule is that building requires a named property that nothing available provides — and that the naming has to come before the survey, because a property named after the survey will be shaped to fit the gap you already wanted to fill.

What would falsify the disposition

Each kill rests on a factual claim about a consumed project: that it provides a specific property at a specific quality. Those claims are checkable, and any one of them could be wrong.

If a consumed project turns out not to provide the property its kill assumed — if the isolation guarantee is weaker than the deployment needs, if the identity project's revocation semantics do not meet the latency the design assumes, if a signing chain has a gap where the design expects a binding — then that kill was a mistake. The correct response is to say so and re-open the component, not to work around the gap quietly in an adapter, which is how a killed component comes back as an undocumented one.

The broader falsification is simpler. If the six consolidated products that emerged from this cut turn out to be re-implementations in disguise — if the binding layer is doing, internally, work that a consumed project already does — then the discipline was applied to the plan and not to the code, and the twenty-one kills bought nothing but a cleaner document. That is a real risk with a specific tell, and the tell is a growing amount of logic inside the binder that has nothing to do with binding.

The reason to publish the disposition rather than only the result is that a reader can hold me to it. A portfolio that claims restraint should be inspectable for restraint, and a kill list is the only artefact that makes the claim falsifiable.