The CERL questionnaire and the CERL workbook were built last year, and the effort stalled before a single developer completed either one. The CERL tool is the new work: software that replaces the workbook, keeps the questionnaire exactly as written, and makes the case for restarting.
Three things are named in this document, and they are kept strictly apart.
THE CERL QUESTIONNAIRE — sixty questions across six categories, on a signed form. Built last year. Unchanged, and staying unchanged.
THE CERL WORKBOOK — the Excel file that scores the questionnaire and draws the radar charts. Built last year alongside it. The effort stalled before any developer completed a submission, and the workbook has not been used in the field.
THE CERL TOOL — software that replaces the CERL workbook while keeping the CERL questionnaire verbatim. Described throughout this document and embedded in section 10. Nobody at CAAFI has seen it.
Everything the CERL tool does is set in this colour throughout, so what is being proposed can be told apart from what already exists at a glance.
Every published SAF forecast is assembled from press releases. Two credible sources describing the same 2030 horizon can differ by nearly an order of magnitude, and neither can show its work.
The gap isn't a disagreement about arithmetic. It's a disagreement about what counts. Argus counts announcements; CAAFI counts announcements it has reason to believe. Neither number is attested to by the developer, dated, or backed by documentation, so neither can be interrogated.
The CERL questionnaire already asks the right questions — sixty of them, across six domains, signed by a named officer of the company. The instrument is not the problem. What is missing is a way to collect the answers at scale, keep them clean as they accumulate, and turn them into a number that can be republished every month without anyone retyping anything.
Collection at scale is the CERL workbook's weakest ground: one file, one editor at a time, no history, no way for a developer to submit directly, and no mechanism for anything to happen once an answer changes. The CERL questionnaire is sound and worth keeping exactly as it stands. The CERL workbook cannot carry what has to come next, which is why the effort stalled the first time.
The CERL questionnaire is unchanged — the sixty items in the CERL tool are verbatim from the signed form. Everything downstream of the questions is new.
The CERL questionnaire says evaluation may stop at the first No. The CERL workbook adds up every Yes. The two rules produce different answers, and each is right about something different.
The ladder is the headline. It is how far a project has actually walked, in order, and it is what an offtaker or a lender means when they ask where a project stands. It cannot be inflated by answering the easy questions.
The sum is kept in the detail view, because out-of-order progress is real. A project can have a signed feedstock contract before its sustainability certification is complete. Discarding out-of-order progress discards information.
The CERL workbook records companies and sites at the same level in its entity table. One level for two different kinds of thing guarantees collisions, and several are already sitting in the data.
| What's in the data now | What it actually is |
|---|---|
| DG Fuels appears in twelve rows | One company, twelve distinct refineries |
| "Cinergic Energy" and "Lafayette Renewable Fuels, LLC — Cinergic Energy" | One project, two records, same contact person |
| "Fidelis New Energy — Gron Fuels" and "Grön Fuels" | One project, same city and pathway, diacritic variant |
| "SAFFiRE" and "Saffire Renewables" | Possibly two real projects at different sites — a human has to decide |
No matching algorithm resolves that last row, which is why the CERL tool does not try to. Records separate into three tiers — organization, project, dated submission — which is enough structure to stop a company and a site being confused for one another.
An earlier version of this required a developer to search the registry, claim an existing record, and wait for approval before a new one could be created. That was the wrong trade. Nobody has submitted anything yet; the binding constraint is getting people to engage at all, and an approval queue between a developer and their first entry is exactly the friction that ends the attempt.
So creation is open. As a developer types a site and state, anything close already in the registry surfaces underneath — "this looks like project 46, is that yours?" — and they can claim it in one click or carry on. If they carry on and it turns out to be a duplicate, it is a duplicate that gets merged later, with both submission histories preserved. A duplicate is a small, fixable problem. A developer who gave up at the registration screen is not recoverable.
The CERL workbook overwrites: every prior state of every project is lost the moment a cell changes. Under snapshots, an update writes a new dated record and the old one stands, which produces year-over-year movement for free — which projects advanced, how far, and how long each gate took to clear. Snapshots are the one capability the CERL workbook structurally cannot have, and they are the basis for every trend view in section 10.
Confidentiality is the condition on which developers submit anything at all. The CERL tool treats confidentiality as a hard constraint rather than as a setting.
Nothing crosses a tier automatically. A partner who wants to talk to a project raises a request; CAAFI asks the developer; the developer decides. That single rule is what keeps the alerting described in section 07 from quietly becoming a lead list.
Routing is where the CERL tool stops being a scoreboard. Every project has exactly six unmet items — one per category — and each one names something CAAFI can do about it.
| Where a project stops | What it needs | Held until |
|---|---|---|
| FRL 6 | Pilot facility or DOE BETO funding | — |
| FORL 8 | Grower co-ops and aggregators | ERL 3 |
| ERL 4 | EPC firms with SAF experience | FRL 7 |
| F$RL 8 | Project finance lenders, DOE LPO | ERL 8 |
| OARL 3 | Airline or aggregator fuel team | FRL 6 |
| EPCL 1 | Environmental consultants and lead agency | — |
The third column is the part that matters. An introduction made too early is worse than none — it spends a connection that doesn't renew and costs the developer credibility with exactly the counterparty they most need. Pitching an offtaker before the fuel is past pilot, or a lender before FEED, does damage that a later, better-timed introduction can't undo.
That timing judgement currently lives in a few people's heads. Writing it down is most of the intellectual work in this build, and it is the thing no one else could replicate. The rules encoded in the CERL tool are a first draft and need CAAFI's correction.
Developers see their six asks and whether an introduction has been made. They do not see the holds, the queue, or their position in it. CAAFI keeps the discretion; the developer gets a reason to keep the record current.
Connection points, the same as the value chain side — six of them, one per category, updated every time they submit.
And visibility, on their own terms. A readiness score held by a neutral third party is worth something to a developer courting an offtaker, a lender or a state agency, because it states a level rather than an adjective. Each category can be opened or closed independently, at any time. Most will start closed.
Sections 02 through 06 are familiar in shape. Readiness ladders are CAAFI's own invention — FRL and FSRL have been in the field for years — and asking a developer to place a project on one is a well-understood idea, even though the CERL questionnaire has never been completed by a developer directly. The CERL tool makes that collection faster and cleaner. It does not make the underlying idea new.
Asking the value chain to declare its own criteria is the unfamiliar move, and it is worth being explicit that it has not been done in this industry. Today a catalyst lab, an EPC firm, a lender and an airline fuel team all find projects the same way: by hearing about them. Nobody has asked them to write down, in advance, the readiness range at which a conversation is actually worth their time. The information exists — every one of them has that threshold, and applies it in the first ten minutes of every call — it has simply never been collected.
Partners register once: which category they work in, what they provide, and the range they want to hear about. When a project crosses into it, an alert fires. A range rather than a floor, because the constraint runs both ways — a pilot facility has no use for a project already ASTM qualified, and a lender none for one that hasn't reached FEED. The upper bound is what keeps the alerts worth opening.
Running an intake questionnaire is a convening activity. Operating a matching network is closer to running a marketplace, and it carries obligations the first does not: a vetting standard, because approving a partner is an implicit endorsement; a service expectation, because partners who register expect alerts to arrive; and a neutrality question, because CAAFI would be routing commercial opportunity between members.
None of those is disqualifying, and the upside is substantial — introductions stop being rate-limited by a handful of calendars. But they arrive the day this launches rather than later, which is why the vetting standard and the alert cap sit at the top of the decisions list rather than the bottom.
Screening partners for quality would put CAAFI in the business of rating firms — fielding appeals from anyone turned down, and owning the outcome when an approved partner disappoints. The alternative is to check identity only, admit everyone, and be explicit that admission means nothing beyond identity:
Registration is open and self-declared. CAAFI does not assess, verify or endorse any registered organisation's capability, financial standing, track record or fitness for a project. Matching is automated: an alert is generated when a project's self-reported readiness falls within the range that organisation stated for itself. An alert is a data-handling result, not a recommendation. Parties remain responsible for their own diligence.
That holds up better than standard boilerplate because it names the mechanism. A reader can see that a range was compared and nothing was judged. Identity checking stays factual and cheap: a named individual, a corporate email domain, an organisation URL. Removal happens on complaint rather than by screening in advance.
A disclaimer covers competence but not motive. The registrant worth worrying about is not a weak engineering firm — it is a competing developer or a rival's commercial team registering as an advisor to watch the field advance in real time. Their credentials would be perfectly good, so no amount of vetting would catch them.
Two things already blunt that. Alerts are anonymised, so a watcher learns only that a project number crossed a level. And identity release runs through the developer, so no contact happens without permission.
The blocklist closes the rest. A developer names organisations that must never be alerted about their projects — typed in freely, no reason required, no list to browse. Entries match on organisation name or email domain, as a substring, so a single word blocks every variant of a company's name, and a block placed against an organisation that has not registered simply waits for them. A block suppresses alerts, contact requests and CAAFI-routed introductions alike, and the blocked party is never told.
Deliberately, there is no register for developers to pick from. Publishing who has signed up would expose partners who have good reasons for discretion, airlines above all. Blocking by name asks the developer to name a concern they already have rather than to go looking for one.
Aggregate what partners are willing to engage on and the result is something nobody currently publishes: the readiness level at which each part of the value chain actually shows up. If no lender in the network will look at a project before F$RL 8, the number measures where capital begins rather than exposing a gap in the roster. Repeated across six categories, it maps the valley of death by showing precisely where the supply side stops appearing.
No developer has ever entered their own data into the CERL workbook. Every record in it was typed in on their behalf, which is a large part of why the effort stalled last year. The problem to solve is a cold-start problem, and cold starts are solved by reach rather than by engineering.
Contact details for most of the industry already exist. That list is the asset. The CERL tool can be linked to in an email, opened in a browser, and completed in one sitting with no account approval standing in the way — which converts the list into submissions in a way that emailing the CERL workbook as an attachment never will.
The single highest-value piece of automation is a scheduled reminder. Once a month, everyone on the list who has not submitted gets a short note with a direct link. Everyone who has submitted gets a different note — their current six asks, their score, and a one-click confirmation that nothing has changed. Confirmation is as valuable as an update: it is what keeps a record from going stale, and it takes the recipient ten seconds.
That loop runs without anyone at CAAFI touching it, and it is what converts a static list of email addresses into a dataset that refreshes itself.
A registry that dies with its custodian was never really a registry. The design question is how much of the CERL tool can run with nobody at the wheel — and the answer is nearly all of it.
Account creation by email domain, project creation, scoring, snapshots, threshold alerts, partner matching, the public dashboard, the monthly reminder loop, and full data export. None of these need a person. They are arithmetic and scheduling.
| Needs a human today | How it stops needing one |
|---|---|
| Merging genuine duplicates | Ask the developer at the point of creation. They know whether project 46 is theirs; nobody else does. |
| Approving value chain partners | Publish the criteria, verify the email domain, auto-admit, and remove on complaint rather than screening in advance. |
| Ripeness thresholds | A one-time exercise. Once written down they are just rules, and they run themselves. |
| Releasing identity on request | Route the request straight to the developer with approve and decline links. CAAFI is a bystander to its own permission flow. |
| Reviewing submissions | Optional. Everything publishes as self-reported; a review badge is an enhancement, not a gate. |
Worth stating the cost of this honestly: automating the introductions removes exactly the discretion that makes them valuable. A rules-based referral is not the same as a well-timed phone call from someone the recipient already trusts. The sensible position is that the automated layer is the floor — it keeps working regardless of who is around — and human judgement is applied on top of it while there are people to apply it.
Four views the CERL workbook cannot produce, all generated by the CERL tool from the same sixty answers.
Four role views, live below. Switch roles with the control at the top right: Public sees numbers only, Developer is signed in as DG Fuels with three projects, Value chain is a partner setting their range, CAAFI staff sees everything including the routing queue and the vetting inbox.
The CERL tool runs entirely in the browser at this stage. Refreshing resets it.
Each was a placeholder in the CERL tool. Each now carries a recommended default, in teal beneath the question. None is a technical question, and all remain CAAFI's to set.
The CERL tool is a prototype, and it is unannounced. Everything runs in the browser with no database and no accounts, and refreshing resets the data. The CERL tool exists to make the decisions in section 11 concrete enough to argue about. Nobody at CAAFI has seen it, and no commitment has been made to build it out.
The seed data is illustrative. Company names and sites are real, drawn from the CERL workbook's entity table. The answers, scores and volumes are plausible fabrications. Screenshots should not circulate as findings.
It does not live on the main site, and does not need to. CAAFI's site is built on Wix, which has no database and no server-side code. The route around that is settled: a development page on its own Cloudflare URL, with the main site linking across. A separate address keeps the CERL tool independent of the main site's constraints, and puts this document, the CERL tool and anything built next at one URL that can be shared as a link.
The readiness-weighted number will be lower than the announced number. A lower figure is the whole point, but publishing one undercuts the more optimistic ones already in circulation, including CAAFI's own. Framed as "what is actually backed," the lower number is a credibility gain. Framed carelessly, it reads as CAAFI turning pessimistic on the industry. The framing is a decision to take deliberately rather than to discover later.