Allocation Engine Methodology

Why this document exists

A black box that produces numbers nobody can trace back to assumptions is worse than useless in resource management. It generates mistrust, not coordination. Every number this engine produces must be traceable to first principles, and every assumption must be explicit and challengeable.

This document explains every step: what inputs the engine takes, how it weights them, what constraints it applies, and why. If your view of how a particular weight should be set differs from the default, the live engine at /fisheries lets you change any parameter in real time and see exactly what changes.

The problem the engine solves

Most contested resource allocation processes fail for the same reason: each party enters negotiation claiming they need more than the system can sustainably provide, with no neutral mechanism to adjudicate between claims.

The typical result is one of three outcomes: a negotiated overshoot where parties agree to exceed the sustainable limit because no one will accept a cut; a deadlock where negotiations collapse and an often-unsustainable status quo continues; or power capture where the strongest party gets the most regardless of what sustainability or equity would suggest.

CORIOLIS ONE produces a fourth option: a recommendation that is mathematically consistent with the sustainability ceiling, distributes remaining capacity across parties according to documented principles, and explains every allocation in terms any party can trace and challenge.

The four inputs

Every allocation is computed from four inputs per stakeholder. Nothing else enters the calculation unless explicitly added by the user running the engine.

1. Claim (C_i)

What the party says they need: their requested quota, historical catch level, or treaty entitlement. The claim is treated as a ceiling on what the party will receive, not a floor and not an automatic entitlement.

2. Compliance Score (K_i)

A 0 to 1 score reflecting how consistently the party has adhered to past agreed allocations. A score of 1.0 means the party has never exceeded their agreed quota. A score of 0 means consistent, documented violation.

Compliance enters the allocation as a multiplier on effective claim weight. A party with K = 0.5 has their claim weighted at half the rate of a fully compliant party. This creates a continuous, systemic incentive for better behaviour: parties that comply receive better allocations in the next cycle. Parties with poor records are not excluded: they are downweighted.

3. Economic Dependency (D_i)

A 0 to 1 score reflecting how reliant the party's economy is on this resource. A nation where fishing represents 15% of GDP scores materially higher than one where it represents 0.1%. Dependency enters the allocation as a floor modifier: parties with high dependency scores receive a larger guaranteed minimum before the unconstrained optimisation runs.

The purpose is to reflect a political reality: a technically optimal solution that destroys the economy of a small island fishing state will not be adopted. Economic dependency is the engine's way of acknowledging that not all cuts are equal.

4. Sustainability Ceiling (S)

The scientifically assessed maximum yield consistent with stock recovery or maintenance. This is a hard constraint. The total recommended allocation across all parties will never exceed S. This is non-negotiable by design: the entire purpose of the engine is recommendations consistent with long-term sustainability. A recommendation that exceeds the ceiling is no better than the status quo.

The optimisation

With the four inputs defined, the engine runs a constrained optimisation across all stakeholders simultaneously in five steps.

Step 1: Compute weighted effective claims

For each party i, compute their effective claim weight:

W_i = C_i × K_i × (1 + D_i × dependency_weight)

Where dependency_weight is a configurable parameter (default: 0.3) controlling how much extra allocation parties with high economic dependency receive relative to their claim weight alone.

Step 2: Apply the sustainability ceiling

Distribute the total sustainable yield proportionally to effective claim weights:

A_i(unconstrained) = S × (W_i / ΣW_j)

Step 3: Apply treaty floors

For any party with a treaty minimum M_i, enforce:

A_i ≥ M_i

If the sum of all treaty minimums exceeds S, the engine flags a genuine constraint conflict explicitly rather than silently violating any floor. No allocation that is mathematically impossible is produced without surfacing the impossibility.

Step 4: Apply step-change caps

To prevent destabilising single-cycle swings, cap the maximum change from the previous allocation:

|A_i - A_i(previous)| ≤ max_change × A_i(previous)

max_change defaults to 30% per cycle. The most common reason RFMOs fail to implement scientifically sound allocations is that the recommended cut is too large to absorb politically. A 30% cut this year followed by 20% next year achieves the same long-run outcome as an immediate 44% cut, and is far more likely to actually happen.

Step 5: Generate per-party reasoning

For each party, the engine outputs a plain-language explanation noting: which constraint was binding (sustainability ceiling, treaty floor, step-change cap, or none); how compliance and dependency modified their weight; and what the allocation would have been without each constraint: making the cost of each constraint visible.

Design decisions and their rationale

Every design choice in the engine reflects a specific judgement about why previous allocation mechanisms fail. The key decisions:

• Compliance as a multiplier, not a veto: maintains participation while incentivising improvement. Exclusion incentivises data disputes, not behavioural change.
• Dependency as a floor, not an exemption: prevents dependency claims from becoming blanket shields against any cut. All parties bear some cost.
• Sustainability ceiling as hard constraint: a recommendation that exceeds the ceiling is indistinguishable from the status quo in its long-term effect. The constraint is inviolable.
• Step-change caps: accepts a slower path to the optimal allocation in exchange for political adoptability. The engine is designed to produce recommendations that can actually be implemented, not just recommendations that are technically optimal.
• Full configurability: every parameter is user-adjustable in the live engine. There is no hidden assumption. If a user believes dependency should receive a weight of 0.5 rather than 0.3, they can set that and see the result immediately.

What the engine cannot do

This section matters as much as the sections above.

• It cannot verify inputs. If a party submits false compliance data or an exaggerated claim, the engine processes it. Data verification is a governance problem. Tools like Global Fishing Watch address the monitoring side: CORIOLIS ONE operates on whatever inputs it receives.
• It cannot enforce. Recommendations are advisory. The engine has no mechanism to compel compliance and does not claim one. Its value is in producing a neutral, transparent starting point for negotiation: not in replacing negotiation.
• It cannot adjudicate between stock assessments. If two credible scientific bodies produce different sustainability ceiling figures, the engine produces different recommendations. Resolving the science is not its function.
• It cannot account for factors it was not given. The four-input model is a deliberate simplification. A production-grade tool for binding RFMO decisions would incorporate seasonal variation, species interaction effects, gear selectivity, and other factors not currently in the model.

Pilot scope

Transparency and auditability

Algorithm weights are configurable in the live engine at /fisheries. Every parameter is visible. The source code for the allocation engine is available on request to research partners and pilot participants.

The engine's outputs can be reproduced independently using the formulas in this document and the inputs provided. There is no proprietary calculation: the value is in the framework and the interface, not in hidden maths.

References

This document describes the methodology of a working alpha engine and will be updated as the engine develops. Discrepancies between this document and live engine behaviour should be reported via the contact form.  ·  © 2026 CORIOLIS ONE. Not legal or regulatory advice. Pilot outputs are advisory only.