إنتقل إلى المحتوى الرئيسي

🤖 AI Architecture

The BayanCore Intelligence Layer is built to provide context-rich, secure, and compliance-validated assistance. By combining Retrieval-Augmented Generation (RAG) with a strict Tool Execution Gateway, the system accelerates daily business operations without compromising transactional integrity.

1. The Three-Tier Agent Framework​

AI agent autonomy is segregated into three functional tiers, each requiring distinct guardrails:

[User Input] 
  │
  ├── Tier 1: Ask (Read-only RAG) ──> Fetch Context ──> Output Answer
  │
  ├── Tier 2: Act (Draft Record) ──> Tool Call Draft ──> Request Human Sign-off ──> Commit
  │
  └── Tier 3: Automate (Opt-in loops) ──> Run Check ──> Execute ──> Log Audit Trail

Tier 1: Ask (Natural Language Queries)​

  • Access Level: Read-only.
  • Behavior: The user asks a question about company performance, records, or policies (e.g., "What is our current cash runway?").
  • Execution: The system queries local databases and vector indexes via RAG and generates a response. No database writes are allowed. All answers must include source citations.

Tier 2: Act (Draft Documents)​

  • Access Level: Write draft-level objects only.
  • Behavior: The user requests record creation (e.g., "Draft a purchase order for 50 boxes of cable from Supplier X").
  • Execution: The AI maps the request to a schema-validated tool in the Tool Registry, populates a draft PO record, and sends a review card to the UI. The record is committed only when the user clicks "Approve".

Tier 3: Automate (Closed-Loop Workflows)​

  • Access Level: Executable background actions.
  • Behavior: Repetitive tasks (e.g., matching daily bank transactions).
  • Execution: Requires explicit, audit-logged user activation. The agent executes checks using programmatic validation scripts. If validation fails, it stops and routes the transaction for human review.

2. In-Kingdom RAG Pipeline​

To comply with the Saudi Personal Data Protection Law (PDPL), all customer datasets, vector databases, and LLM inference engines run strictly within Saudi borders on OCI Riyadh infrastructure.

  1. Ingestion & Chunking: Documents and transactional databases are parsed and segmented into semantic chunks.
  2. Embedding Generation: Chunks are vectorized using a KSA-hosted Cohere embed-multilingual-v3 model.
  3. Vector Store: Vector indices are stored locally in OCI Search with OpenSearch, isolated per tenant.
  4. Retrieval: User queries are vectorized and compared against the tenant's vector database to retrieve the top-k relevant contexts.
  5. Inference: Contexts are merged into the LLM system prompt and sent to a local Llama-3-70B model running on OCI GPU shapes.
  6. Deterministic Validation: Financial numbers generated by the LLM are validated programmatically against actual ledger databases before the response is rendered to the user.

3. Tool Registry & RBAC Gateway​

When an agent needs to perform an action (Tier 2/3), it must execute through the RBAC Gateway:

  • Schema Contracts: Every available action is defined as a JSON schema contract in the Tool Registry (specifying arguments, required fields, and output structures).
  • RBAC Enforcement: The gateway checks the user's active JWT role (e.g. Accountant, Ops Manager) before executing a tool. The AI cannot elevate its own permissions.
  • PII Redaction: The gateway redacts PII elements (Iqama numbers, personal emails, phone numbers) from the context before it is passed to the LLM.
  • Audit Logging: Every tool call is logged immutably: 
    {
      "timestamp": "2026-06-02T01:13:42Z",
      "user_id": "usr_9281a",
      "role": "Accountant",
      "action": "draft_purchase_invoice",
      "ai_generated": true,
      "payload": { "vendor_id": "vendor_012", "amount": 12500 }
    }