Architecture

How LLM Capsule plugs AI into the systems you already run

Three zones. Four steps. Five components. Two execution paths. One governance framework. The AI enablement data layer for regulated operations — at the architectural level.

Zone overview

One layer between your existing systems and AI

LLM Capsule sits inside your environment, reads from existing systems, preserves operational structure, and restores AI output back into the originating workflow. The architecture maps to four zones — Corporate Internal Network, DMZ, In-House Team, and Local Auto Reconstruction — and the trust boundary holds: raw operational data stays inside the corporate environment; only the protected capsule traverses zones; restored output is reconstructed locally inside the in-house team's environment.

Zone 1

Corporate Internal Network

Where the operational systems and the data they hold already live. LLM Capsule reads from these systems where they already are — without modification, with a single API-call addition.

  • ERP System (SAP / Oracle) — REST API
  • CRM (Salesforce) — REST API
  • Ticketing (Jira / ServiceNow) — REST API
  • DMS / ECM (SharePoint) — Graph API
  • Legacy DB (Oracle / MSSQL) — JDBC → API
  • RAG Pipeline (Vector DB) — gRPC / REST
Zone 2

DMZ — Demilitarized Zone

Where the Enhanced Encapsulation Layer operates. Detection identifies sensitive elements, encapsulation replaces them with safe tokens using structure-preserving, differential-privacy-based protection, and only the capsule leaves this zone toward an external AI.

  • Detection — PII + customer-defined markers
  • Enhanced Encapsulation Layer — DP-based, structure-preserving
  • Capsule transmission — capsule only, never raw data
  • Token map stays local
  • Audit trail of every encapsulation event
↑ Trust boundary — original operational data never crosses
Zone 3

In-House Team

Where governance, policy, and the AI workflow itself are operated. Organizational policy, permissions, and domain context drive how the encapsulated request is routed — to an approved external LLM or to an on-prem local model — with full audit retained inside the organization.

  • Organizational policy & permissions
  • Domain context applied to AI processing
  • Routing — external approved LLM (Path A) or on-prem local (Path B)
  • Approved external LLMs: ChatGPT · Claude · Gemini · Perplexity · any LLM API
  • Governance fully retained
Zone 4

Local — Auto Reconstruction

Where the AI response is automatically reconstructed back into Business-Ready output. Tokens are restored to original values inside the organization only — data that left the boundary cannot be reconstructed externally.

  • Token-by-token restoration from local token vault
  • Restoration happens only inside the organization
  • Externally-leaked data is not restorable outside
  • Business-Ready output delivered to the originating workflow
  • Restoration audit alongside encapsulation audit
Technical view · zone-based architecture

The same architecture, in technical view

For architects and security reviewers — the full zone-based view of how operational data, encapsulation, and how any LLM interacts.

01 Source Data
Corporate Internal Network
On-prem DB · Enterprise Systems
Unstructured
DB1
Customer Data
Personally Identifiable Info
DB2
Ticket Data
CS Tickets / Status
DB3
Detail Data
Unstructured Claims
Raw Input Fields
Customer David Lawson ID
Ticket CS-4203 CD
Free Text Shipping delayed... BD
×
PII guardrails protect fields. Enterprises run on structures. We are not criticizing PII filters. We handle a different category of data — table schemas, cross-references, alarm sequences, and ticket threads that simple field-level masking cannot preserve.
ERP
SAP·Oracle
CRM
Salesforce
RAG
Vector DB
Legacy
Oracle
Ticket
Jira·SN
DMS
SharePoint
REST · gRPC · JDBC · Graph API
Zero System Modification Integrates via a single API call with zero modifications to existing ERP, CRM, or legacy systems
02 Enterprise Environment Execution
Unstructured Data In
02 DP Encapsulation
DMZ — Differential Privacy
Same Org · EU Region · GDPR Ready
Encapsulation Flow
IN
Raw Input
Unstructured Data
PROCESS
DP Engine
Differential Privacy
OUT
Encapsulated
Token Capsule
Encapsulation ✓ Protected
Name * * * * * * * ID
Champ Id CS-* * * * CD
Free Text [tokenized...] BD
DP Engine epsilon-DP Active
Noise Injection (Laplace)
k-Anonymity Enforcement
Semantic Tokenization
Free-Text NER Masking
DMZ Guarantee Goes beyond simple encapsulation. Differential privacy techniques make original sensitive data mathematically irreversible
01 Structure-Preserving 05 Zero Exposure & Audit
Protected Data Out
03 AI Processing
In-House Team
Same Org · Anonymized LLM Proxy
LLM Pipeline
LLM-a-Proxy Anonymized Routing
Path A · External
Public cloud Region-hosted
Path B · On-prem
Private On-prem
swap any model — capsule contract stays the same
No Direct Access to Source DB AI teams never touch the source database. They only receive structure-preserved, differentially-private data
Privacy Isolation Module
PDESC / ISOLA
Privacy Descriptor
Isolated Computation Zone
Output De-identification
Re-identification attempts contained · Output validated
Compliance
EU GDPR EU Region
01 Structure-Preserving 05 Zero Exposure & Audit
AI Response (tokenized)
04 Local Auto Reconstruction
Local — Auto Reconstruction
Internal Only · No External Egress
Reconstruction Flow
IN
AI Token
Tokenized Response
PROCESS
Reconstruction
Local Restoration
OUT
Original Value
Business-Ready
Token → Original
Customer David Lawson ID
Ticket CS-4203 CD
Details Shipping delayed... BD
Reconstruction Local Only
Token Map Lookup
Original Value Restore
Context Re-binding
Output Validation
Local Reconstruction Guarantee Token map exists only in local storage · Delivers Business-Ready Output instantly
Output Properties
Original Values Restored
Zero External Exposure
Context Fully Preserved
Business-Ready Output
Auto Restore Local Only Data Residency
03 Business-Ready Reconstruction 04 Enterprise Context Control 06 Time-Shifting Policy
6 Core Capabilities
What Makes The Workflow Run
01
Structure-Preserving
Tables, logs, cross-references, and alarm sequences stay intact. AI reads structure, not just text.
02
Enterprise Environment Execution
Deploys inside your environment. Connects via API, SDK, connectors, or reverse proxy. No traffic re-routing.
03
Business-Ready Reconstruction
AI output is restored with real values. The result goes straight back to the originating ticket or workflow.
04
Enterprise Context Control
Your IT admin defines what counts as sensitive. Custom markers, regex rules, and tier policies. Set in 5 minutes.
What Gets The Approval
05
Zero Exposure & Audit
Raw operational data stays inside. Every action logged, timestamped, SIEM-exportable.
06
Time-Shifting Policy
Sensitivity changes over time. Capsule versions every marker and policy for continuous compliance.
01 and 02 lead the conversation. 05 and 06 anchor the approval.
Zone 1 · Corporate Internal Network

Where the operational systems already live

Existing enterprise systems — ERP, CRM, Ticketing, DMS / ECM, Legacy DB, RAG Pipeline — stay in place. Nothing migrates. Capsule reads from them via REST, gRPC, JDBC, or Graph API depending on the source.

Zone 2 · DMZ — Demilitarized Zone

Where encapsulation happens

The Enhanced Encapsulation Layer detects sensitive elements, replaces them with safe tokens using structure-preserving, differential-privacy-based protection, and hands the capsule to the routing decision. Original values stay behind, retained in the local token map.

Zone 3 · In-House Team

Where governance and routing happen

Organizational policy, permissions, and domain context decide where the capsule is processed — an approved external LLM (Path A) or an on-prem local model (Path B). The decision is policy-driven per workflow, with full audit retained inside the organization.

Zone 4 · Local — Auto Reconstruction

Where the AI response becomes Business-Ready output

The AI response is automatically reconstructed from token to original value inside the organization only. Data that left the trust boundary cannot be reconstructed externally. The restored output is delivered back into the originating workflow.

Six architectural pillars

What this architecture protects against — and how

The pillars below are the technical commitments encoded into the four-zone architecture above. Each maps to a specific failure mode of conventional approaches.

Pillar 01

Beyond simple PII guardrails

Even inside the same enterprise, free-text fields like a CS ticket Details column mix customer names, contact information, and claim narrative in unstructured form. Simple PII guardrails cannot safely process this. Detection in Capsule operates on free-text and structured fields together — semantic and context-aware, not pattern-matching alone.

Pillar 02

No modification of existing systems

Existing enterprise systems are not refactored. Connection is a single API-call addition (REST / gRPC) — the operations team continues using their existing tools, the Capsule layer handles encapsulation and restoration alongside.

Pillar 03

Beyond simple encapsulation — differential privacy

The Enhanced Encapsulation Layer goes beyond simple tokenization. Differential privacy (epsilon-DP, Laplace noise, k-anonymity, NER masking) is applied to minimize re-identification risk on the capsule itself, providing stronger protection than tokenization alone.

Pillar 04

No raw exposure to external AI

External AI services see only the capsule. Original operational data does not cross the trust boundary. Tokenization combined with DP processing means a leak from the external AI side does not yield reconstructable original values.

Pillar 05

In-environment auto-restoration

AI response tokens are automatically restored to their original values inside the organization only. Data that left the trust boundary cannot be reconstructed externally — only the in-house token vault can perform restoration.

Pillar 06

Governance, policy & domain context retained

Organizational policy, permissions, and domain context drive the entire AI processing path — what gets encapsulated, where it is routed (Path A external or Path B on-prem), and how restoration is audited. Governance stays inside the organization end-to-end.

These pillars are derived from the diagram_v8 architecture reference. Each pillar maps to a specific failure mode of conventional approaches — masking and redaction, prompt security gateways, and synthetic data platforms — that the four-zone architecture is designed to address.

Five components

What's inside the LLM Capsule

The five architectural components that implement the data layer. Each is independently configurable and audit-loggable.

Component 01

Detection Engine

Detects PII + customer-defined markers across structured fields and free text. Beyond regex — semantic + context-aware. 98.1% detection accuracy.

Component 02

Encapsulation Engine

Differential-privacy-based replacement (epsilon-DP, Laplace noise, k-anonymity, NER masking). Structure-preserving — tables, hierarchies, references survive.

Component 03

Policy Control

Versioned, scoped, RBAC'd policies. Time-shifting markers — yesterday's policy archived, today's enforced. Per-team, per-workflow scope.

Component 04

Restoration Engine

Local token vault lookup + context re-binding + output validation. 100% restoration rate. AI output comes back business-ready, in the originating tool.

Component 05

Audit & Compliance

Every detection, encapsulation, processing, and restoration logged with policy version, model, latency, and outcome. GDPR / HIPAA / SOX-aligned.

Two execution paths

One architecture. Two paths. Policy-driven per workflow.

The same LLM Capsule instance can route different workflows through different paths — under one governance framework.

PATH A · External

Approved external LLM, capsule data only

For workflows where the regulatory profile permits transmission of differentially-private capsules with appropriate contractual safeguards (DPA, SCCs).

  • Routes to ChatGPT, Claude, Gemini, Perplexity, or any LLM API
  • Capsule travels — original data never does
  • In-region endpoints supported (EU-hosted for sovereign AI)
  • Best for: NOC RCA, claims classification, summarization
PATH B · On-prem

On-prem local lightweight model

For workflows where any external endpoint is unacceptable — classified data, lawful intercept segments, OT operations, regulated mental health / pediatric data.

  • Quantized model on internal GPU (vLLM-served)
  • Zero external transmission — fully air-gapped option
  • Same Capsule instance, same audit, same policy framework
  • Best for: defense, classified workflows, strict sovereign AI
In-environment integration

Reads the systems you already run — without modifying them

LLM Capsule is not a SaaS API you call from outside. It runs inside your environment and reads from the operational systems already in place. Existing systems are not modified — a single API-call addition is what connects them to the encapsulation layer.

ERP System
SAP / Oracle — REST API
CRM
Salesforce — REST API
Ticketing
Jira / ServiceNow — REST API
DMS / ECM
SharePoint — Graph API
Legacy DB
Oracle / MSSQL — JDBC → API
RAG Pipeline
Vector DB — gRPC / REST

These six are the source-system identities mapped in the diagram_v8 reference. Existing enterprise systems are not modified — connection is a single API-call addition. Raw operational data does not leave the environment to reach Capsule; the Capsule sits next to these systems, on-prem or in your VPC.

Integration interfaces

How existing systems invoke Capsule from inside the environment

Once Capsule is deployed inside the environment, existing enterprise systems invoke it through whichever interface fits their stack. All interfaces stay inside the customer network — none of them route raw operational data through an external SaaS endpoint.

REST / gRPC
For modern operations tools, RAG pipelines, and custom orchestrators inside the environment.
JDBC / ODBC
For legacy database systems (Oracle, MSSQL, DB2) that need Capsule invocation as a stored procedure or job step.
Graph API
For DMS / ECM systems (e.g. SharePoint) where document events trigger Capsule processing.
On-prem API
Capsule's own on-prem callable surface. Same contract whether you're air-gapped, hybrid, or VPC.
Embedded SDK
Library-level integration for ISVs and platform vendors who ship Capsule inside their own product.
Slack App
For teams using Slack as the operations UI. The runtime still lives in the customer environment; the Slack App is the invocation surface.
Deployment modes

Six deployment modes — match your environment exactly

Capsule runs inside the customer environment in every mode. Path A and Path B execution choices apply across all six.

Air-gapped on-prem

Fully internal. No external network. Path B only. Defense, classified, OT.

On-prem hybrid

Internal Capsule + approved external LLM. Path A for most workflows, Path B for sensitive subset.

VPC / private cloud

Customer's cloud VPC. Capsule + token vault stay in tenant; LLM call to in-region endpoint.

AWS Marketplace

Listed and procurable through AWS Marketplace. VPC deployment, AWS billing integration.

Embedded SDK

For ISVs and platform vendors building Capsule into their own product. Library-level integration that ships inside the host application.

Slack App

For teams using Slack as the operations UI. Capsule runtime stays in the customer environment; the Slack App is the surface that invokes it.

Note: a separate "Telecom-grade" topology (NFV / container / multi-region) is offered as a deployment variant for operator infrastructure — validated at SK Telecom, recognized at Deutsche Telekom T Challenge 2026. It composes with the modes above rather than replacing them.

See the architecture run on your environment.

Bring your deployment constraints, regulatory profile, and one real workflow. We demonstrate the data layer in your environment within 30 minutes.

Email : contact@cubig.ai

CUBIG LTD (United Kingdom)

Company Number: NI735459
Address: 21 Arthur Street, Belfast, Antrim, United Kingdom, BT1 4GA


CUBIG CORP (Republic of Korea)

Business Registration Number : 133-81-45679

E-Commerce Registration : 2023-Seoul-Seocho-2822

Address: 4F, NAVER 1784, 95, Jeongjail-ro, Bundang-gu, Seongnam-si, Gyeonggi-do, Republic of Korea

©️ 2026 CUBIG Corp. All rights Reserved.

Consent Preferences

Email : contact@cubig.ai

CUBIG LTD (United Kingdom)

Company Number: NI735459
Address: 21 Arthur Street, Belfast, Antrim, United Kingdom, BT1 4GA


CUBIG CORP (Republic of Korea)

Business Registration Number : 133-81-45679

E-Commerce Registration : 2023-Seoul-Seocho-2822

Address: 4F, NAVER 1784, 95, Jeongjail-ro, Bundang-gu, Seongnam-si, Gyeonggi-do, Republic of Korea

©️ 2026 CUBIG Corp. All rights Reserved.

Consent Preferences

Email : contact@cubig.ai

CUBIG LTD (United Kingdom)

Company Number: NI735459
Address: 21 Arthur Street, Belfast, Antrim, United Kingdom, BT1 4GA


CUBIG CORP (Republic of Korea)

Business Registration Number : 133-81-45679

E-Commerce Registration : 2023-Seoul-Seocho-2822

Address: 4F, NAVER 1784, 95, Jeongjail-ro, Bundang-gu, Seongnam-si, Gyeonggi-do, Republic of Korea

©️ 2026 CUBIG Corp. All rights Reserved.

Consent Preferences

Email : contact@cubig.ai

CUBIG LTD (United Kingdom)

Company Number: NI735459
Address: 21 Arthur Street, Belfast, Antrim, United Kingdom, BT1 4GA


CUBIG CORP (Republic of Korea)

Business Registration Number : 133-81-45679

E-Commerce Registration : 2023-Seoul-Seocho-2822

Address: 4F, NAVER 1784, 95, Jeongjail-ro, Bundang-gu, Seongnam-si, Gyeonggi-do, Republic of Korea

©️ 2026 CUBIG Corp. All rights Reserved.

Consent Preferences

Email : contact@cubig.ai

CUBIG LTD (United Kingdom)

Company Number: NI735459
Address: 21 Arthur Street, Belfast, Antrim, United Kingdom, BT1 4GA


CUBIG CORP (Republic of Korea)

Business Registration Number : 133-81-45679

E-Commerce Registration : 2023-Seoul-Seocho-2822

Address: 4F, NAVER 1784, 95, Jeongjail-ro, Bundang-gu, Seongnam-si, Gyeonggi-do, Republic of Korea

©️ 2026 CUBIG Corp. All rights Reserved.

Consent Preferences