Why Good Projects Die: Part 2, From 302 Projects to Bankable Value

August 26, 2026

Print This Article Share it With Friends

by Jim Lane (Biofuels Digest) Part 1 ... (C)ould the value of removing uncertainty be expressed in terms that mattered to capital?

First, a live project has to become machine-readable.

A project normally arrives as a collection of decks, spreadsheets, contracts, engineering studies, timelines, assumptions, emails and management knowledge. Useful to humans. Difficult for a formal system. So we developed an INGEST structure around the elements the FRAGILITY Framework actually requires:

State. Event. Time. Relation. Intervention. Evidence. Confidence. Context.

The objective isn’t to collect everything that can possibly be known about a project. It is to collect all the data the formal representation requires, and only the data it requires.

Consider something apparently straightforward: feedstock is secured. What does “secured” mean? Who is the counterparty? How much material is committed? For how long? At what specification? Under what pricing mechanism? With what escalation? What termination rights? What logistics? What credit support? Has the agreement actually been executed? What evidence establishes each of those things?

That allows us to distinguish materially different states:

asserted → evidenced → verified → contracted → secured.

Those differences matter because uncertainty lives in the gaps between them. INGEST therefore isn’t a conventional project questionnaire. It converts project narrative into a machine-readable formal representation upon which the rest of the system can operate.

Then the project enters the Observatory.

The project knows a great deal about itself. But it does not necessarily know everything the world knows about it.

That is where the Observatory comes in. Over many years, The Daily Digest has accumulated a large body of information about companies, technologies, projects, facilities, markets, policies, counterparties, scale-ups, shutdowns, financings, failures and successes. Its value is not simply that we have a lot of data. The formal project representation generates questions that can be put to that data.

...

Project Actions change the project. Intelligence Actions change what is known about the project. Both can remove uncertainty.

Then came the 302-project backtest.

We assembled a corpus of 302 bioeconomy projects and reconstructed their histories.

Of those, 234 were classified as not completed/operating, 57 as successful and 11 as unknown.

The purpose wasn’t to construct a clever explanation after we knew what happened. It was to determine whether the conditions identified by the FRAGILITY Framework showed a meaningful relationship with actual project outcomes. They did.

...

Technical failure was rare. More importantly, the decisive signals repeatedly appeared in interactions among markets, counterparties, policy, feedstock, infrastructure, timing and other operating conditions—the contextual relationships that project-centered assessments can underweight or miss.

That explained something that had puzzled us. A project could have a credible technology and an attractive TEA and still be moving into an increasingly fragile trajectory because the conditions around it were changing. The reactor might be working perfectly. The world around the reactor might not be.

But a project insight is not a basis point.

...

The Framework identifies a project condition and what would change that condition. The changed condition can then be expressed through concepts lenders already use to underwrite risk

...

Then comes calibration.

...

When a particular uncertainty is removed, how does that changed condition translate into the way sector lenders assess and price the project?

...

FRAGILITY identifies and structures the uncertainty. The project and the Observatory generate the actions and evidence that can remove it. The financing layer expresses the changed condition in underwriting terms. Capital determines the final price. Keeping those layers separate matters.

The output has to speak Bank.

There was one more problem to solve. Suppose we successfully remove uncertainty and then hand a lender a consultant’s report saying: “Management should consider strengthening its feedstock position.”

We’ve created another translation problem.

...

CapLess finds removable uncertainty, determines what removes it, gets the work done, documents the changed condition, and translates that change into bankable value. It unifies the machinery behind a much simpler objective. Remove uncertainty before capital prices it.

Close the hood.

CapLess is not a score. It is not a consultant’s opinion about what a lender might think. It is not another way to describe risk. It is a platform system for identifying uncertainty, determining what removes it, completing the necessary Project and Intelligence Actions, documenting the evidence, and expressing the resulting project condition using the concepts through which capital assesses and prices risk.

There is an enormous amount of machinery underneath that sentence. There should be. New systems have to earn the privilege of becoming ordinary. But the people who eventually use them shouldn’t have to think about recurrence, contextual moduli, operator treatments or hundreds of historical project trajectories every time they need an outcome.

They should be able to think about the outcome. The project doesn’t become smaller. The uncertainty does.

Which leaves us with a very different question from the one that started this investigation. We began with: Why did this project fail? We have arrived at:

What uncertainty can we remove before capital charges you for carrying it?

That’s the question CapLess is built to answer. Less uncertainty. More project. We’ll be unveiling CapLess to a select group of projects in September and October, and debuting CapLess at ABLC in October. READ MORE