Batoi AIF Docs

Architecture

Understand the governed execution path inside Batoi AIF.

Start Reading Open AIF GitHub
On this page

Architecture

Batoi AIF is designed around one core idea: AI 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

  • Host applications construct a request with user, workspace, purpose, prompt input, and provider intent.
  • The AIF gateway normalizes the request into a governed execution context.
  • Policy decides whether execution is allowed, denied, modified, or sent for human review.
  • Prompt governance renders approved templates and versions.
  • Provider abstraction routes execution to a configured provider.
  • Evaluation checks can inspect the response before release.
  • Audit logging records evidence for operational review.

Important Boundary

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