Proposed specificationSource-located exemplarH1

Multi-provider transport abstraction

Swap model backends.

JOIN POINTmodel_backend_resolutionRECORD STATUSCandidate · v0.1.0

UML class view

The proposed contract drawn as participant roles, received calls, and numbered dependencies.

Object interactions

The same roles and calls as a class collaboration and a numbered message sequence.

Object interaction diagram for Multi-provider transport abstraction, showing role collaboration and a numbered message sequence — FIG. P08 / OBJECT INTERACTIONS
Open full SVG Download PDF

Pointcut

Where the mechanism applies. All four dimensions belong to the proposed match, not just its vocabulary.

Context: A harness can select among model backends.
Trigger: The runtime resolves or invokes a model provider.
Structure: A shared request/response/error boundary plus provider-specific implementations.
Effect: Backends are interchangeable through a declared interface, with differences exposed.

Protected contract

The obligation that clients, operators, and auditors should be able to rely on.

Requires: Provider identity, model configuration, and common result types are available.
Ensures: Every provider satisfies the same invocation contract or reports unsupported behavior.
Invariant: Provider-specific state remains behind the adapter boundary.
Violation: Authentication, rate, schema, and capability errors map to explicit types.

Negative control

A single hard-coded vendor client is not the abstraction.

Variation & lifecycle

The hot spot is admitted only where the protected semantics survive.

Permitted variation

Registry, factory, adapter, transport, retry advice, and capability discovery.

Test obligation

Test two providers, unsupported tools, usage mapping, and error translation.

Evolution question

Did the common interface expand while provider differences stayed explicit?

Prompt + code design

An illustrative prompt and a small design sketch for the proposed contract. Names and APIs are invented; this is not a repository excerpt.

PROMPT SKETCH

Resolve a provider through a common transport contract. Normalize results and errors, report unsupported capabilities explicitly, and never leak provider-specific objects into the loop.

CODE DESIGN / PYTHON

class Transport(Protocol):
    def invoke(self, request: Request) -> Result: ...
    def capabilities(self) -> set[str]: ...

def invoke(request, registry):
    transport = registry.resolve(request.provider)
    if not transport.capabilities() >= request.required:
        raise UnsupportedCapability(request.provider, request.required)
    return transport.invoke(request.normalized())

Illustrative design sketch. The protocol defines substitutability; the registry selects an implementation. This example is a teaching aid, not implementation evidence or a conformance claim.

Detection & matching

The frozen rule that retrieves this record, the canonical source exemplar, and the control that should stay unmatched.

Join point: model_backend_resolution
Source locator: Barbaste et al., §7.1, p. 18 (“Provider Abstraction Spectrum: multi-provider via an abstraction layer or owned transports”); merged label
Lexical cue: (?i)\b(?:model[_-]?provider|provider[_-]?model|model[_-]?adapter|LLMClient|ModelClient)\bFrozen expression, v0.1.0. A match is a retrieval cue, not a confirmed implementation.
Aliases: None
Canonical exemplar: openai/openai-agents-pythonsrc/agents/models/interface.py:150Support: tests/models/test_reasoning_content.py:25
Negative control: A single hard-coded vendor client is not the abstraction.

Scope-anchored review. pohe-agent analyze <repo> --pattern P08 anchors the cue to its enclosing declaration and checks a separate operational signature for all four pointcut dimensions. Missing roles and negative-control risks remain visible; a structural match is not E2/E3. Calibration report ↗

Repository files

Up to five public files retrieved by the frozen cue and pinned to the audited commit. A match is a place to inspect, not a confirmed implementation.

01openai/openai-agents-pythonsrc/agents/models/interface.py:150CANONICAL SOURCE 02aaif-goose/goosecrates/goose/src/bin/build_canonical_models.rs:102RETRIEVAL CUE 03agno-agi/agnolibs/agno/agno/db/in_memory/utils.py:107RETRIEVAL CUE 04anomalyco/opencodepackages/ai/src/ai-client.ts:4RETRIEVAL CUE 05browser-use/browser-usebrowser_use/agent/service.py:2242RETRIEVAL CUE

Evidence & provenance

Each layer answers a different question. Do not substitute retrieval for review.

Source-located exemplar

A concrete source anchor is available for this proposed record. It is one exemplar, not evidence that all repositories—or every contract field—conform.

Review boundary: this candidate and its specification come from an AI-assisted study. Independent human validation remains open.

ANY-EVIDENCE FAMILY COVERAGE28/36

77.8% of repository families in the frozen panel have at least one current cue, historical cue, or canonical source layer. This is not confirmed prevalence.

Current lexical-cue repositories: 28 / 41

Canonical source anchoropenai/openai-agents-python 86bd29878b30src/agents/models/interface.py:150

Supporting surfacetests/models/test_reasoning_content.py:25

Abstract ModelProvider boundary.

Exploratory retrieval cue Regex / v0.1.0

(?i)\b(?:model[_-]?provider|provider[_-]?model|model[_-]?adapter|LLMClient|ModelClient)\b

This expression is a discovery instrument only. A match is a retrieval cue—not a confirmed implementation, pointcut match, or contract proof.