HHlinor Request a Risk Review
Engineering notes

Fail-closed decisions: what a funding router taught us about evidence gates

Hlinor — engineering notes. October 2026.

Ask a general-purpose LLM where a startup should apply for funding and you get a long, confident list. Most entries look plausible. Some programs closed last year, some never accepted that kind of company, and a few depend on a fact nobody checked. The list reads well, and you cannot act on it.

We built Funding Intelligence to make fewer, more defensible decisions instead. It is an open-source (Apache-2.0), deterministic engine that routes a project to grants, accelerators, cloud credits, investment and business-development programs — and refuses to recommend a route it cannot back with evidence.

Funding is not Hlinor's business. We publish this note because the rules that keep the engine honest are the same rules we apply when we review AI systems that make decisions about customers, refunds or access.

Five rules that keep the output honest

  • Unknown is not evidence. A missing fact stays unknown. It is never filled in by a model, a default value or a confident paragraph.
  • A transport failure is not a status. If the application page does not answer a live probe, the program is not marked CLOSED. The source-backed status is kept and the endpoint is recorded as UNREACHABLE.
  • A failed hard gate cannot be outvoted. A high raw score or good prose cannot turn a route that failed eligibility into "apply now".
  • Dated facts stay dated. Every program card carries a source and a snapshot date. A stale date produces VERIFY_FIRST, not a silent "current".
  • Every recommendation has an exit. Each route comes with a reason, a next action and a stop condition: the fact that would make this route a waste of time.

Separate questions get separate answers

Most recommendation systems collapse everything into one score. This engine keeps the questions apart and only combines them at the end:

  • program status — is the program running, according to its official source;
  • endpoint status — is there a confirmed way in: an application portal, a form, a forum;
  • project fit — do the structured project facts match the route;
  • project readiness — does the project already have the proof the route demands;
  • eligibility — ELIGIBLE, INELIGIBLE, INCOMPLETE or UNKNOWN.

The final decision is route-specific and says what to do, not how good the match feels. A shortened route from the public sample report:

program: Microsoft for Startups
project_fit:      POSSIBLE (score 62)
eligibility:      INCOMPLETE
  passed:  [company-owned software product]
  missing: [current official eligibility, intake endpoint verification]
next_action:      VERIFY_FIRST, within 2 days
stop_condition:   No eligible private software company
                  or no Azure/enterprise use case
decision:         VERIFY_FIRST

A score of 62 is not a recommendation. Two facts are missing, so the honest answer is "verify first", with a deadline and a reason to stop.

Humans confirm the way in

Finding a program is easy. Finding the real door into it is not: an official information page is not an application endpoint. The engine includes a read-only scanner that collects candidate application links from official pages, but a candidate is only a lead. A card gets a confirmed endpoint only after a person opens the route and records it.

As of the latest changelog, 9 of 50 program cards carry a confirmed endpoint. The other 41 are deliberately source-only. That number is low on purpose: it shows how much of "funding discovery" is still unverified.

How it is tested

One command runs the full local gate. In our latest run it reported:

  • 49 automated tests and 9 synthetic regression cases with expected decisions;
  • 7 public decision-quality benchmarks built only from public sources, each listing the decisions that would count as wrong;
  • schema validation of all 50 program cards, plus checks that no private evidence or credential-like values enter the public repository.

The same checks run in GitHub Actions on every push.

What this does not prove

  • No consented external pilot yet, no repeat usage and no funding outcome. Benchmarks measure decision quality, not acceptance or revenue.
  • Program cards are snapshots. Coverage is selective, and every route must be re-verified before a real application.
  • The engine never submits applications or contacts programs. Human review is still required for claims, eligibility and execution.
  • Our own market check found discovery and matching already crowded. Larger catalogues are not the goal; defensible triage is.

Why this matters for AI risk reviews

Swap "funding route" for "refund approval" or "account access" and the rules still hold. When we review an AI workflow, we ask the same questions: what the system treats as evidence, what happens when a dependency times out, whether a confident output can bypass a hard rule, and whether a decision can be reconstructed later. If the answers are vague, that is a finding.

Repository

All engineering notes