Image baseline policy reference¶

Topics: generation, kudos, workers

Baseline validation uses two sources outside the baseline policy module:

• The served baseline catalog. Published on models.aihorde.net and read through model_reference.baseline_record(baseline). It states what exists for a model family: which ControlNet, layer-diffusion and QR-code weights have been published, whether the architecture has a remix mechanism, whether a flow-matching timestep shift is meaningful for it, and the kudos, batching, lease and resolution-floor policy the horde applies to it.
• The bridge feature table. BRIDGE_BASELINE_FEATURES in horde/bridge_reference.py, keyed by bridge version. It states which bridge releases actually render a feature on a baseline.

horde/baseline_policy.py reads both sources. To add a baseline, see add an image baseline.

What each authority decides¶

A feature that both columns cover needs both to allow it. The features are evaluated in the order above, so a request tripping two of them is refused for the first.

A request specifying several models can be dispatched to any of them, so a feature is accepted only where every requested baseline renders it.

Which bridge releases render what¶

bridge_supports(feature, baseline, bridge_agent=None) is the only reader. It is cumulative by version in the same way get_bridge_capabilities is: a worker gets the union of every version at or below its own.

Admission checks whether any known bridge kind at any version renders the combination. If none supports it, the request is refused with 400. Dispatch checks the worker's declared bridge agent, so an older worker is passed over when its bridge does not support the requested feature. The flux graph capability stays a flat capability checked at dispatch alone.

The horde policy on a baseline¶

Read with policy(baseline), which returns the record's horde_policy or the par default.

An uncatalogued baseline¶

A baseline absent from the catalog, including one outside the installed horde_model_reference vocabulary, is given conservative capabilities and priced at par. A plain txt2img request remains accepted, while baseline-dependent workflows are refused until the catalog states that the required weights or mechanism exist and, where applicable, a bridge release states that it renders them.

Code map¶

Contract tests¶

tests/unit/test_baseline_policy.py covers catalog capabilities (TestCatalogCapabilities), bridge versions (TestBridgeSupport), uncatalogued baselines (TestUncataloguedBaseline) and service policy (TestServicePolicy).