Deterministic scoring with bounded model influence for multichain expansion decisions

Deploying a product to a second chain is not a deployment. It is a new security surface, a new operational commitment, a second liquidity problem, and a permanent increase in the cost of every future change. The decision deserves the rigour of a hiring decision or an architecture review. In practice it usually gets less.

Three failure modes recur. The first is incentive capture: a grant or liquidity-mining offer arrives, and the offer rather than the fit determines the destination. The second is availability bias: the team deploys where its own engineers already have context, which correlates with familiarity rather than with where the product’s users are. The third, and most damaging, is unstated criteria — the team never writes down what it is optimising for, so it cannot tell afterwards whether the decision was right or merely lucky.

None of these are solved by more information. Ecosystem data is abundant and mostly public. What is missing is a structure that connects a specific product’s requirements to that data in a way a team can inspect and argue with.

The central construct is a structured representation of the product, built once and read by everything downstream. It records what the product is, what it requires from an execution environment, who uses it, what it cannot compromise on, and what the team can realistically execute.

Why an explicit model

A system that reasons directly from prose to a recommendation produces an answer that can only be accepted or rejected wholesale. Interposing an explicit model changes the shape of the disagreement: a reader who thinks the recommendation is wrong can locate the specific field that is wrong, correct it, and see what moves. Disagreement becomes an edit rather than a rejection.

It also makes the system’s ignorance legible. Every field the twin could not establish is recorded as missing data, surfaced in the report, and propagated into the confidence value attached to every score. A model that cannot represent its own gaps will fill them silently.

Provenance

Each field carries a tag: derived from a retrieved source, supplied by the user, inferred by the model, or a documented default. User-supplied values always outrank retrieved ones when they conflict, because a public website is frequently out of date and the team is not. Inferred fields are the ones most worth reviewing, and the interface says so.

Chain-fit is computed by a pure function of the twin and the knowledge base. It allocates 100 points across 5 categories and 17 sub-factors, applies objective-derived weighting, subtracts penalties for specific incompatibilities, and returns a complete factor-by-factor breakdown alongside the total.

Bands, not point estimates

Almost every knowledge-base field is a categorical band rather than a number. This is a deliberate accuracy claim, not a shortcut. Throughput, fee and liquidity figures move continuously; a pinned number is wrong within weeks while continuing to look authoritative, and false precision in an input propagates into false precision in the output. A band is defensible for longer and is honest about its own resolution.

Weighting and renormalisation

Stated objectives tilt category allocations, and the result is renormalised to exactly 100. Without renormalisation, selecting more objectives would inflate scores and make runs incomparable. The applied weights are recorded in every report, so a score can be reproduced from the published function.

Hard constraints

Some conditions are not matters of degree. An explicitly excluded ecosystem, an unsatisfiable virtual-machine requirement, and a data-availability layer proposed as a contract deployment target are all blockers: the score is zero, and the reason is attached. Treating these as heavy penalties rather than blockers would let a sufficiently attractive chain score its way past a constraint the user stated as absolute.

A language model is used for what it is good at: reading unstructured sources, explaining a numeric result in domain terms, identifying qualitative trade-offs, sequencing work, and drafting execution material. It is not used to produce the number.

The model may move a chain’s score by at most ±5 points, only with a written justification, and the adjustment is stored and displayed separately from the base score everywhere it appears.

The clamp is enforced in the scoring layer rather than requested in the prompt, so it holds regardless of what the model returns. This is also the primary defence against prompt injection: retrieved page content is untrusted by construction, and the structural answer to "what if a page tries to influence the analysis" is that the influence available to it is bounded at five points and rendered visibly next to the base score.

Every model response is a structured generation validated against a schema before it is used or stored. A response failing validation is retried with the specific validation error fed back; if it still fails, the stage reports an error rather than persisting malformed output.

Analysis runs as seven discrete stages rather than one large generation. Each has its own input contract, its own output schema and its own validation, which keeps every prompt short enough to reason about and makes a failure attributable to one stage.

1. 01Project extraction — retrieved page text plus user answers to a validated factual profile.
2. 02Digital Twin — profile plus constraints to the structured model everything else reads.
3. 03Chain interpretation — twin plus deterministic scores to explanations, advantages, trade-offs and unknowns.
4. 04Expansion sequence — ranked scores to a primary recommendation, secondaries, exclusions and rollout order.
5. 05Architecture brief — deployment model, components, messaging, token model and monitoring.
6. 06Risk register — security, liquidity, operational, governance, experience and compliance risks.
7. 07Execution plan — four weeks with milestones, dependencies and acceptance criteria.

Staging also enables section-level regeneration. A user who corrects the twin can regenerate the affected sections against stored upstream output rather than re-running the entire analysis, which makes iteration cheap enough to actually do.

Honest progress

Stage transitions are recorded as durable events and streamed to the client. Progress advances only when a stage genuinely completes. There is no interpolation and no timer: if a stage takes ninety seconds, the interface shows it running for ninety seconds. A simulated progress bar is a small lie that teaches users to distrust every other number in the product.

Every score carries a separate confidence value derived from the knowledge base’s own confidence in that ecosystem, the number of factors that fell back to a documented default, and the confidence of the twin itself, less a penalty for each recorded gap.

Confidence is bounded above by the confidence of the twin. A report cannot be more certain than its inputs, and a system that reports high confidence over an uncertain model of the product is reporting the confidence of its own arithmetic rather than of its conclusion.

A high score with low confidence is a meaningful and common result: the recommendation is directionally supported but rests on assumptions worth verifying before committing engineering effort. Collapsing score and confidence into one number destroys that distinction.

Routefold reads what it is given and what it can retrieve from public URLs. It does not read the codebase, product analytics, the counterparty list or the treasury. For many products the decisive fact — how many existing users already hold assets on each candidate chain — is private, and the system does not have it.

The knowledge base is a maintained human assessment, not a live feed. It carries a review date and a per-chain confidence level, and both are displayed. Where a live public figure genuinely improves a judgement it is fetched at runtime and always shown with its source, timestamp and whether it is live, cached or seeded.

Scoring resolution is finite. The function separates large differences reliably and small ones not at all. Where two candidates fall within a few points, the correct output is that they are tied and the decision rests on evidence the system was not given — and reports are written to say so rather than to manufacture a winner.

Routefold is not a smart-contract audit and is not a substitute for one. It does not provide financial, legal, compliance or investment advice; compliance items are framed as questions for qualified counsel.

The prevailing pattern for applying language models to analytical work is to let the model produce the conclusion and then ask it to explain itself. The explanation is generated after the fact and is not causally connected to the answer, which makes it unfalsifiable — a plausible narrative that cannot be checked because there is nothing underneath it to check against.

Routefold inverts that. A deterministic function produces the number, the model explains the function’s actual output, and the function is published so the explanation can be checked against it. The explanation is constrained by something real.

The bet is that for consequential decisions, teams will prefer a system that shows its work and states its uncertainty over one that sounds more confident. The entire factor table is exposed for that reason: the goal is not to be believed, it is to be checkable.