Skip to content
Appendices

Appendix B. Reference architecture

This appendix names the architectural components behind every BAGF commitment. It states what each component does and the capabilities it must provide. It does not name vendors or products. Vendor selection evolves. The architecture, and the BAGF commitments, do not.

  • Full ACID semantics for the operational write path.
  • Row-level security for multi-tenant isolation.
  • Field-level encryption for PII columns.
  • Primary-replica replication for high availability.
  • Streams transactional changes to downstream stores in near real time.
  • Idempotent processing. Schema evolution supported.
  • Columnar storage tuned for analytical queries.
  • Read-only role for the text-to-SQL agent (Pillar V §8).
  • Partitioned by tenant and by time for query performance and isolation.
  • Storage for retrieval-augmented embeddings.
  • Tenant-scoped collections. No cross-tenant retrieval.
  • Approximate nearest-neighbour search for retrieval performance.
  • Single ingress point for every LLM call (Pillar IV §9).
  • Routing by task class and model classification.
  • Fallback chain with automatic retry.
  • API-key management through a key-management service.
  • Per-tenant, per-IP, per-feature rate limiting.
  • Real-time cost tracking.
  • Primary. Commercial providers under enterprise agreements with Zero Data Retention and regional pinning where required.
  • Fallback. A different commercial provider combined with self-hosted open-source models.
  • Self-hosted open-source. Open-weight models hosted inside Vietnam for data residency.

Specific vendor names are not published in BAGF. The current sub-processor list is disclosed to enterprise customers under contract.

  • A state-graph orchestration layer for deterministic multi-step workflows.
  • A multi-agent conversation layer for experimental conversational workflows.
  • A custom enforcement layer for hard caps (recursion depth, token budget, wall-clock, cost ceiling).
  • MCP-compatible server. Open standard for safe LLM-to-tool integration.
  • Customised for the Bizzi multi-tenant model and integrated with PII redaction.
  • Tool definitions versioned in source control.
  • A2A-compatible message bus for inter-agent communication.
  • Open standard for structured agent-to-agent messaging with identity, capability advertisement, and schema validation.
  • Trace IDs propagated across every hop for end-to-end observability.
  • Embedding model deployed in-house. Content does not leak through an embedding API.
  • Cross-encoder reranker for top-K candidates.
  • Refreshed quarterly or when drift is detected.
  • Specialised engine fine-tuned on Vietnamese invoices and multi-format documents.
  • Self-hosted for data residency.
  • Confidence scoring at the character and field level.
  • Self-hosted instance for data residency.
  • Traces for every LLM call and agent workflow.
  • Prompt versioning.
  • LLM-as-a-judge evaluation integration.
  • Distributed tracing using an open tracing standard.
  • Metrics aggregation.
  • Centralised log aggregation.
  • Channel integration for the DevSecOps team.
  • Email and SMS for the on-call rotation.
  • Paging for SEV1 incidents.
  • Compute. Container orchestration with isolated workloads per environment.
  • Storage. Managed cloud storage in the Vietnam region for enterprise and banking customers.
  • Network. VPC isolation. Mutual TLS for service-to-service traffic.
  • CI/CD. Git-based pipeline. Peer review required. Automated test gates.
  • Separated OLTP and OLAP. Each store is purpose-built for its workload. The transactional path stays fast. The analytical path scales.
  • Vendor-neutral protocol layer (MCP). Lets Bizzi swap LLM vendors without touching application code.
  • Open observability standards. Traces and metrics interoperate with customer-side tooling without lock-in.
  • Hybrid LLM strategy. Commercial models for top-tier quality. Self-hosted open-weight models for data residency and cost predictability.
  • Hard caps in a dedicated layer. Cost and runtime ceilings are enforced uniformly across every agentic workflow.

The stack shifts when:

  • benchmarks change,
  • cost dynamics change,
  • vendor stability changes, or
  • customer requirements demand it (BYOK, region pinning, sovereignty constraints).

BAGF commits to the architectural principles. Fallback. Observability. The MCP boundary. Residency. Not to specific products. A vendor swap does not require a BAGF version bump unless the architecture itself shifts.