Skip to content

row 155 (L1#3): a model's protocol override reaches the llm plane and is served, fail-closed (#51) - #841

Merged
MattJackson merged 4 commits into
predevfrom
lane-p3-llm-protocol
Oct 15, 2026
Merged

MattJackson merged 4 commits into
predevfrom
lane-p3-llm-protocol

Conversation

@MattJackson

Copy link
Copy Markdown
Collaborator

Row: /status 155. This fixes row-159 audit plane-llm L1#3 (HIGH, door path). It must be green before #824 leaves draft.

What. A model entry's protocol (#51: model override, else the provider's default; the plane interprets it fail-closed. THE DESIGN §2 BEDROCK-INVOKE ruling; CHANGELOG "a model entry takes protocol") was being lost in two places:

  • root::door_steps::kernel_sections dropped it, so the plane never received it.
  • The plane's Shaping::from_settings never read it, so every lane spoke its provider's dialect and an unknown override was accepted.

Now the root passes the member through as protocol (MODEL_PROTOCOL_KEYS[0]). The plane resolves the dialect as model override, else provider, else the default dialect. A dialect it does not serve is refused as model '<name>' uses unknown protocol '<p>'.

Why. Spec l.2237 (#51): "model may override protocol+error_map; resolution = model-override-else-provider-default; plane interprets resolved dialect, unknown => fail-closed". 1.5.5 had no model-level protocol (additive in 1.6.0), so no 1.5.5 golden moves. A config that names no model protocol is byte-identical.

RED-able tests

  • busbar-plane-llm/tests/exchange_shaping.rs::a_models_protocol_overrides_its_providers_and_an_unknown_one_is_refused
  • crates/busbar/src/root/tests/door_steps.rs::a_models_protocol_override_is_handed_to_the_plane

Ledger rows touched: none expected.

Not in scope: a per-model error_map override. The config grammar (busbar_contract::config::ModelCfg, deny_unknown_fields) does not accept one today.

…nd is served, fail-closed (#51)

Row-159 audit plane-llm L1#3: a model entry's `protocol` (#51, THE DESIGN §2 BEDROCK-INVOKE
ruling; CHANGELOG "a model entry takes `protocol`") was dropped by the root's section builder and
never read by the plane, so the plane wrote that model's requests in its provider's dialect and
accepted an unknown override. The root now hands the member through (`kernel_sections`), and the
plane resolves model override, else provider default, else the default dialect, refusing a dialect
it does not serve naming the model.

RED-able: exchange_shaping::a_models_protocol_overrides_its_providers_and_an_unknown_one_is_refused,
root door_steps::a_models_protocol_override_is_handed_to_the_plane.
…lect (kind-isolation law0 busbar x vendor 92 -> 89)

The root hands the model's override through as opaque data; its test now spells two neutral dialect
words, so the root carries no vendor name (#841 gates: law0 busbar x vendor 92/89, law0-base 89/0).
@MattJackson
MattJackson merged commit 8b163c9 into predev Oct 15, 2026
1 check was pending
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant