Provider workflows
Cross-Provider Runtime Configuration Contract
Separate application intent from Anthropic, OpenAI, and Google credentials, models, API versions, state, capabilities, and operational limits without pretending their APIs are equivalent.
- Format
- Template
- Level
- Intermediate
- Audience
- Developer, Operator, Leader
- Owner
- Project42 Editorial
- Review cadence
- Every 30 days
- Prerequisites
- A defined AI use case and data classification; Approved provider accounts and secret storage; Provider-specific capability checks
Separate the application contract from adapters
Define provider-neutral application inputs, outputs, evidence, safety rules, latency and cost budgets, state ownership, and failure semantics. Implement an explicit adapter for each provider. Do not flatten different tool loops, response types, storage defaults, safety signals, citations, or error models into false one-to-one fields.
Select a provider and model only after checking the exact required capabilities, region, policy, data handling, context, structured-output, tool, and availability constraints. Fail closed when configuration names an unsupported combination. A fallback is a new execution with a traceable reason, not a silent retry against a different model.
Record a deployable configuration
Store secret values in an approved secret boundary; store only environment variable names in source. Pin reviewed defaults, validate at startup, and expose safe configuration fingerprints in telemetry.
Application capability: [BOUNDED USE CASE]
Data classification/region: [POLICY]
Provider selection rule: [EXPLICIT CONDITION]
Fallback rule and approval: [CONDITION / OWNER]
Anthropic: key env=ANTHROPIC_API_KEY; model env=PROJECT42_ANTHROPIC_MODEL; interface=[MESSAGES]; capabilities=[VERIFIED LIST]
OpenAI: key env=OPENAI_API_KEY; model env=PROJECT42_OPENAI_MODEL; interface=[RESPONSES]; capabilities=[VERIFIED LIST]
Google: key env=GEMINI_API_KEY; model env=PROJECT42_GEMINI_MODEL; API version env=PROJECT42_GEMINI_API_VERSION; interface=[INTERACTIONS]; capabilities=[VERIFIED LIST]
Timeout/retry/total budget: [VALUES]
State/storage/retention owner: [APPLICATION OR PROVIDER / POLICY]
Structured-output validation: [SCHEMA + DOMAIN RULES]
Tool authorization/approval/idempotency: [ENFORCEMENT]
Logging/redaction: [INCLUDE / EXCLUDE]
Configuration version/fingerprint: [VERSION]
Rollback configuration: [LAST VERIFIED VERSION]Expected evidence and verification
Expected evidence is a reviewed contract plus provider-specific startup and smoke-test results. Verify missing-secret failures, model and API allowlists, capability probes, schema handling, tool authorization, state and retention behavior, timeouts, retry budgets, redaction, and provider-attributed metrics. Test every configured fallback with synthetic data.
On invalid configuration, stop before serving traffic. Rollback by restoring the last verified configuration fingerprint and provider adapter, then rerun startup, smoke, and policy checks. If a provider becomes unavailable, use a pre-approved fallback only when its capability and data-policy gates pass; otherwise return a clear unavailable state and preserve the incident evidence.