Engineering lens
One policy boundary coordinates provider health, rate limits, retries, fallbacks, budgets, and auditable execution across four interfaces.
Execution boundary
A static architecture drawing of the recorded Substrate boundary: callers enter a policy layer, controls make health, retry, and budget behavior explicit, and execution remains provider-dependent.
Problem
AI execution becomes operationally difficult when providers fail differently, expose different interfaces, and carry different cost or budget constraints.
Context
Substrate provides a policy boundary between callers and model/provider execution.
Architecture
The current surface spans HTTP, CLI, MCP, and A2A interfaces with shared routing, provider state, and audit/observability concerns.
Constraints
Provider health, quotas, retries, and budgets must remain explicit rather than hidden inside one adapter.
Key decisions
Rate limiting, retry/fallback chains, and policy-aware routing make failure behavior deliberate and inspectable.
Verification
Repository evidence covers the interface and control-plane scope; no performance or scale number is claimed.
Current limitations
Provider behavior and operational policy still depend on deployment configuration and live upstream availability.
Retrospective
The useful abstraction is a controllable execution substrate, not a single-provider wrapper.
Provenance & Attribution
- Evidence source
- Repository documentation and project history
- Repository
- https://github.com/KooshaPari/substrate
- Available in lens
- engineering