Skip to main content
SCSyndicate Code
Get Started

Providers Overview

Provider abstraction

Provider and model selection is controlled by the control plane (provider_routing_and_model_abstraction_spec.md PR-001). Workflows request capabilities; they do not hardcode provider identities (provider_routing_and_model_abstraction_spec.md PR-002, §5.3).

This is the provider-abstraction guarantee from product_system_definition.md G5.

v1 deployment note This page describes v1 local-embedded behavior. Team and enterprise deployments use syndicate-server; routing policy and endpoint topology differ, while control-plane routing authority and evidence requirements remain unchanged.

Routing model

Routing is capability-based and policy-governed.

Routing inputs include (provider_routing_and_model_abstraction_spec.md §5.2):

  • required capability set
  • workflow class
  • trust tier
  • data sensitivity class
  • provider policy restrictions
  • latency and availability constraints
  • fallback policy

Canonical capability dimensions include 15 fields (provider_routing_and_model_abstraction_spec.md §4.1):

  • text input support
  • structured output support
  • tool-calling support
  • streaming support
  • multimodal input support
  • context window size
  • usage-accounting fidelity
  • seed/determinism support
  • stop-sequence support
  • system instruction support
  • latency class
  • cost class
  • provider residency class
  • privacy/retention class
  • evidence fidelity class

Fallback invariant: rerouting must not widen provider exposure, data sensitivity class, or policy scope (provider_routing_and_model_abstraction_spec.md PR-004, INV-PR-002).

Provider classes

Primary provider classes:

  • hosted providers (cloud inference APIs)
  • local providers (local inference engines such as Ollama, llama.cpp, LM Studio)
  • custom endpoints (operator-registered OpenAI-compatible or Anthropic-compatible endpoints)

Policy minimum classes include local, approved_hosted, restricted_hosted, and blocked (provider_routing_and_model_abstraction_spec.md §6.2).

Wire formats

Supported wire formats (provider_routing_and_model_abstraction_spec.md §4.4):

  • OpenAI Chat Completions
  • Anthropic Messages

Operational mapping:

  • models catalog providers use OpenAI Chat Completions format
  • Anthropic family uses Messages format
  • custom OpenAI-compatible endpoints are registerable by URL
  • local inference endpoints are commonly OpenAI-compatible and policy-governed as local provider class

Provider evidence

Provider evidence is captured before any transformation (provider_routing_and_model_abstraction_spec.md PR-005).

Required envelope evidence includes (provider_routing_and_model_abstraction_spec.md §10):

  • model_id
  • request_body_raw
  • response_body_raw
  • usage accounting fields
  • non-determinism markers

Evidence provenance is explicit (provider_routing_and_model_abstraction_spec.md PR-006, §11):

  • self_reported
  • client_captured
  • provider_corroborated
  • middleware_derived