XGuard / Architecture
Execution path

A pure policy core behind a narrow BAM adapter.

The architecture isolates application policy from BAM-specific routing, registration, attestation, and accounting so the critical logic remains testable without inventing an unofficial production interface.

Data path

Placement before scheduler admission.

The intended runtime placement is inside BAM's routing/scheduling environment. An adapter extracts the minimal transaction view, calls the policy core, then returns a delay decision.

01

Incoming transaction

Transaction arrives at BAM routing.

02

BAM adapter

Extracts top-level calls and referenced keys.

03

xguard-core

Returns deterministic delay decision.

04

Scheduler

Normal or delayed admission path.

Core model

Small input. Small output.

classify(config, transaction) receives validated application rules and a minimal transaction view. It returns only the chosen delay_ms and stable rule matches for auditability.

The core has no BAM SDK dependency, network client, RPC connection, database, model runtime, or persistent state.
Integration boundary

No invented production API.

BAM's public ACE design discusses application registration and plugin execution, but XGuard intentionally leaves the production adapter as a boundary until BAM provides the supported interface for the early-access cohort.

  • Application registration source of truth: supplied by BAM.
  • TEE / attestation expectations: supplied by BAM.
  • Scheduler adapter contract: supplied by BAM.
  • Fee/accounting hooks: supplied by BAM if available.
Determinism

The decision is a pure function.

There are no wall-clock reads, random values, network calls, mutable globals, or external storage reads. Identical validated policy plus identical transaction view yields the same classification.