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.
Data layer
Section titled “Data layer”Transactional store (OLTP)
Section titled “Transactional store (OLTP)”- 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.
Change data capture (CDC)
Section titled “Change data capture (CDC)”- Streams transactional changes to downstream stores in near real time.
- Idempotent processing. Schema evolution supported.
Analytical store (OLAP)
Section titled “Analytical store (OLAP)”- 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.
Vector store
Section titled “Vector store”- Storage for retrieval-augmented embeddings.
- Tenant-scoped collections. No cross-tenant retrieval.
- Approximate nearest-neighbour search for retrieval performance.
AI layer
Section titled “AI layer”AI gateway
Section titled “AI gateway”- 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.
LLM providers
Section titled “LLM providers”- 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.
Agentic runtime
Section titled “Agentic runtime”- 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).
Model Context Protocol (MCP)
Section titled “Model Context Protocol (MCP)”- 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.
Agent-to-Agent Protocol (A2A)
Section titled “Agent-to-Agent Protocol (A2A)”- 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 and reranking
Section titled “Embedding and reranking”- 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.
Observability layer
Section titled “Observability layer”LLM observability
Section titled “LLM observability”- Self-hosted instance for data residency.
- Traces for every LLM call and agent workflow.
- Prompt versioning.
- LLM-as-a-judge evaluation integration.
Application observability
Section titled “Application observability”- Distributed tracing using an open tracing standard.
- Metrics aggregation.
- Centralised log aggregation.
Alerting
Section titled “Alerting”- Channel integration for the DevSecOps team.
- Email and SMS for the on-call rotation.
- Paging for SEV1 incidents.
Infrastructure layer
Section titled “Infrastructure layer”- 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.
Why this architecture
Section titled “Why this architecture”- 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.
Evolution
Section titled “Evolution”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.