Skip to main content
Batoi AIF Docs

Architecture

Understand the governed execution path inside Batoi AIF.

Version Foundation release Early foundation work Reviewed Jul 21, 2026 Next review Sep 21, 2026

Owner: Batoi Engineering Reviewed by: Batoi AIF Maintainers Source revision: cd680e8

AIF is the public engineering framework. For the managed intelligence capability used across supported Platform and Flex workflows, see Batoi Intelligence.
Browse Batoi AIF Documentation Architecture

Architecture

Batoi AIF is designed around one core idea: inference, embeddings, moderation, retrieval, and tool execution should pass through a governed framework boundary instead of scattered provider calls.

Host App RAD, API, CLI, worker AIF Gateway Context + request Governed execution Policy Allow, deny, review Prompts Templates, versions Provider Vendor adapter Evaluation Quality and safety checks Audit Evidence and review

Execution Flow

  • Validate governed runtime dependencies, trusted execution context, and request shape.
  • Resolve a capable provider and an immutable approved prompt where applicable.
  • Evaluate operation-aware policy and enforce redaction or review obligations.
  • Stop denied and review-required operations before provider or tool side effects.
  • Execute through the selected provider, access-controlled retrieval adapter, or registered tool.
  • Run pre- and post-execution evaluators.
  • Attempt one correlated terminal audit record and emit operational metrics.

Important Boundary

AIF core remains framework-independent. RAD, UIF, Laravel, Symfony, queue systems, and vector stores integrate through adapters or profiles instead of becoming hard dependencies.

Resilience controls are composable around HTTP providers: bounded responses, timeouts, retry and backoff, safe rate-limit metadata, circuit breaking, and cooperative cancellation.