Deductive Causal Architecture

Summary

Standard inductive AI architectures rely on probabilistic next-token predictions that inevitably trigger recursive model collapse and statistical variance decay (). Deductive Causal Architecture (DCA) resolves this structural failure by replacing statistical pattern matching with non-commutative operator algebra, continuous state manifolds, and invariant deterministic logic that models authentic real-world causality. It sits at the ingress of a data center, safeguarding user-facing applications and providing the underlying deterministic framework that enables them to retain competitive market dominance. Unlike probabilistic sequence engines that guess tokens from historical correlation, DCA observes live interactions and produces a sovereign cause-and-effect model that the customer owns outright. For every interaction it records what state the user was in, what the system did, and what state followed. From those records it trains a model that predicts the effect of an action on a user. Each customer generates that model as an asset they own.

The design has two halves. Sentio, the platform, runs on ordinary virtual machines and handles sessions, audio and vectorization. EDAA^™ (section 2.4), the proprietary engine, is a dynamic tensor-based system that calculates human intent in real time. It runs, together with the interaction datastore, inside a hardware-encrypted enclave that ensures the complete intelligence layer is owned by you. Data flowing through Sentio and EDAA^™ produces your alpha, trained inside the data center equipped with DCA. In other words, you own your intelligence layer by understanding the ontology of your users, and cause and effect, in real time.

Both sides of the sovereign AI chain

DCA connects both sides of the sovereign AI chain.

Data centers gain protected infrastructure for delivering deployable AI systems.

Governments and companies gain operational intelligence they can own, audit, and scale.

DCA and all its components are developed by Own Experiences, SL from 2021 to 2026.

Sourced external literature, linked in the text Measured Virtue measurement Specified design commitment Proprietary mechanism not disclosed

Terms with a dotted underline show a definition on hover, or on tap on a phone.

01The problem: acting on people from text statistics

The systems DCA is compared against in this memo are inductive models based on stochastic probabilistic model. A language model is trained to predict the next token of text given the tokens before it:

Autoregressive factorisation used by transformer language models.

This objective is very good at producing fluent, relevant text. It does not, by construction, learn what happens to a person when the system does something to them. That distinction matters most in rule-bound, human-facing interactions: where an assistant can be talked into an unauthorised discount or an invented legal promise, and where the user is under time pressure or stress.

Why inductive systems depend on the past

Inductive sequence models predict from what has already been seen. A -th order Markov model makes the next token depend only on a fixed window of previous tokens, and scores a sequence as a product of those factors. The product is commutative: reordering its factors does not change the result.

Markov chain factorisation.

Transformers replace the fixed window with attention over the whole context:

Scaled dot-product attention (Vaswani et al., 2017). Without positional encodings, self-attention is permutation-equivariant: shuffling the input tokens shuffles the outputs the same way, so word order enters only through an added position signal.

Both approaches rely on the past: the tokens already in the context window and, across sessions, patterns learned from past data. DCA recalculates the user's state every time, at every turn, from the live inputs of that turn, so each decision is made on the state now rather than on stored history.

Structural weaknesses of the inductive approach

Rules can be talked around. Safety behaviour in language models is trained, not enforced. Wei, Haghtalab and Steinhardt identify two structural reasons it fails: capability and safety objectives compete, and safety training does not generalise to every domain the model can operate in. Sourced Zou et al. showed that automatically generated adversarial suffixes transfer across commercial models. Sourced

Correlation is not causation, formally. On Corr2Cause, a benchmark of more than 200,000 questions asking whether a causal relation follows from stated correlations, language models perform close to random, and fine-tuned models fail on out-of-distribution rephrasings. Sourced On CLadder, which tests associational, interventional and counterfactual queries against ground-truth causal graphs, the authors report the task is "highly challenging" for current models. Sourced

The evidence is not one-sided. Kıcıman et al. report 97% accuracy on pairwise causal discovery and 92% on counterfactual reasoning benchmarks, while noting that models show unpredictable failure modes and ignore the actual data, relying on text knowledge instead. Sourced The fair reading: language models carry a lot of causal knowledge written down by people, but they do not estimate causal effects from the data in front of them.

Text does not see the state of the person. A transcript carries words. It does not carry heart rate, hesitation, or the difference between a calm question and the same question asked under stress. Psychology separates "hot" cognition, driven by emotion and arousal, from "cool", deliberate cognition (Metcalfe and Mischel, 1999; Abelson, 1963), Sourced and it is under hot cognition, urgency and duress that text-statistical systems break down. DCA is built to track that state.

Commitments are unreliable. Because the system is predicting words rather than checking rules, a conversational model can be persuaded into giving an unauthorised discount, inventing a legal promise, or breaking a business rule.

Training on its own output degrades it. When models are trained on model-generated text, errors compound across generations until outputs lose variance and degrade, a failure known as model collapse (Shumailov et al., 2024). Sourced

Cost and memory grow with the conversation. Self-attention compares every token with every earlier token, so the work over a conversation of tokens grows as , and the key-value cache held for each live session grows with its length. Under burst traffic that memory, not compute, is what runs out.

Inference is memory-bound. Generating each token means fetching large parameter matrices from memory for relatively little arithmetic, so the ratio of operations to bytes moved is well below one and inference clusters wait on memory bandwidth rather than compute.

Data leaves the perimeter. Prompts and transcripts are frequently sent to centralised model APIs outside the organisation's boundary.

Nothing durable is left behind. Each interaction consumes tokens and ends; the customer is left with no asset that captures what was learned from their own users.

ExplainerWhy more text data cannot close the gap

Pearl's causal hierarchy has three levels: association (what tends to co-occur), intervention (what happens if I act), and counterfactual (what would have happened had I acted differently). Bareinboim, Correa, Ibeling and Icard proved the Causal Hierarchy Theorem: for almost every causal model, the levels stay distinct, so questions at one level generally cannot be answered with data from a lower level alone.

A text corpus is level-one data. Scaling it improves association. It does not, without further assumptions, produce answers about the effect of an intervention. To answer "what will this action do to this user", a system needs data in which actions were taken and outcomes observed.

02DCA: what it computes

2.1The record DCA keeps, and what it produces

EDAA^™ sits behind a narrow interface: a vector and a tenant context go in, an analysis comes out. This part covers the record DCA keeps for each interaction, what customers configure, and what DCA produces.

Figure 1. The triad is DCA's unit of observation. User state is represented on 50 continuous variables, each on a 0 to 100 scale. Specified What the variables mean and how state is computed is not disclosed. Proprietary

Inputs

Each interaction turn carries a session identifier and one request of type text, voice (audio bytes) or trigger. Alongside it the client may send behavioural, physiological and environmental signals: for example heart rate, EEG values, or a named environmental object with its new value. Specified

How customers shape behaviour

Customers shape behaviour by configuring four things: feeds (knowledge the experience draws on, entered manually or extracted from uploaded PDFs), attributes, logics (the rules and flows of the experience, built through the API or a visual blueprinting tool), and integration channels. A project binds these to one use case.

Outputs

Per turn, EDAA^™ returns an analysis that Sentio turns into one or more response objects. Each object has a type (statement, question, image, video, sound or music) and a value. Over time, each tenant accumulates triads, from which DCA trains the tenant's cause-and-effect model. Specified

Output	Produced for	Form	Trained from
Cause-and-effect model	Every tenant, whether or not a model is connected	Standalone model file, ONNX or H5, downloadable	The tenant's triads
Adapter (LoRA)	Tenants who connect an open-weights generative model and ask for it. Optional, and not Virtue's recommended path (section 5)	Low-rank weight delta for the customer's own model	DCA's learning, applied on top of the customer's base weights

ExplainerWhat an adapter (LoRA) is, and why it is the delivery format

Low-rank adaptation freezes a model's original weights and learns a small update expressed as the product of two thin matrices:

Hu et al. report that for GPT-3 175B this cuts trainable parameters by a factor of 10,000 and training GPU memory by a factor of three, with no added inference latency. The adapter is a separate file of a few hundred megabytes that loads onto the base model the customer already runs. LoRA is a standard format. What is specific to DCA is what the adapter is trained on: cause and effect observed in live interactions.

2.2Inductive models vs DCA

Dimension	Inductive language model	DCA
Foundational substrate	Commutative token probabilities:	Continuous 50-dimension manifold, , and non-commutative matrices Proprietary
Cognitive domain	Statistical corpus pattern matching	Real-time intent validation: dynamic tracking of situation, environment and user state
Computational complexity	Quadratic: attention cost over tokens	Linear: over turns, because the number of state variables stays constant
Information stability	Model collapse	Stops data degradation
Safety enforcement	Soft prompt guardrails, RLHF tuning, secondary filters; bypass is documented (Wei et al.; Zou et al.)	Hard mathematical locks: zero-eigenvalue subspace projection () Proprietary
Operational unit	Disconnected prompt-response token pairs	The causal triad : cause, action, effect
Inputs	Text (and, in multimodal models, images or audio as tokens)	Text, voice, triggers, and behavioural, physiological (heart rate, EEG) and environmental signals
Compute per request	About FLOPs per generated token (Kaplan et al., 2020) for an -parameter model; roughly for a 7B model	2,863 FLOPs for the five EDAA^™ models executed per request; the figure covers those models only Measured
Data boundary integrity	Prompts frequently leave the perimeter to centralized APIs	Zero customer content, audio or transcripts leave the hardware enclave
Customer asset creation	Ephemeral token consumption; no persistent asset	A sovereign cause-and-effect model and, optionally, a LoRA adapter

Read with careThe compute row is not a like-for-like comparison

A language model generates language; the EDAA^™ models evaluate a vector. The 2,863-FLOP figure covers only the operations inside the five models executed per request. In a DCA deployment the largest compute line is the vectorization step on the open compute tier, which uses an off-the-shelf encoder. The row is included to show where the cost sits, not to suggest DCA does the same job with about seven orders of magnitude less arithmetic.

2.3Correlational and causal systems, side by side

DCA is not a better language model. It answers a different question. A language model estimates the probability of the next token. DCA targets the effect of a system action on the user's state. In standard causal notation, the quantity of interest is:

The effect of action

on the user's next state

, given the prior state

. Standard notation (Pearl, Causality); this is the target, not EDAA^™'s internal formulation.

DefinitionWhat "deductive" means in DCA

In DCA, the deductive step is identifying which action produced the observed change in a user's behaviour. It refers to attribution from observed cause and effect, not to formal logical deduction from axioms. The name is kept because it describes the direction of reasoning, from an observed effect back to the action that caused it; readers should not take it to mean proof-theoretic guarantees.

Figure 2. Where each system's training data sits on Pearl's hierarchy. DCA's records have the form of interventional data because the system acts and then observes. Whether a particular effect is identified from such data depends on how action selection and confounding are handled, which is part of the proprietary method.

Not disclosed in this memo

The following are Virtue intellectual property. They are named here so readers know exactly where the description stops.

How the 50 continuous intent variables are defined and computed from the input vector.
How the effect of an action is identified from interaction records, including handling of confounding.
The transition matrices, and the form of the free-energy function used for action selection.
How the prior, current and next states are processed together.

2.4Architecture: Layer Zero

"Layer Zero" means position: DCA sits at the data center's ingress, beneath the applications customers build and in front of any generative model they connect. It is split along one line. Everything that holds durable customer data or proprietary models in plaintext is inside the enclave. Everything that handles transient, derived data runs outside it, on the data center's existing virtualization estate, where it scales cheaply.

Figure 3. The hatched boundary is the only part that needs dedicated hardware. The data centre dashboard (purple links) manages tenants and configuration through the Sentio gateway and reads usage and insights from the data tier. Sentio is the only caller the enclave accepts, over one persistent gRPC channel carrying unary calls: a vector and an opaque tenant identifier in, an analysis out. No raw audio or customer content enters the enclave, and no general data-read interface leaves it.

EDAA^™: the confidential causal engine

EDAA^™ (Emotional Data Analysis and Automation) is the proprietary confidential causal engine within DCA Layer Zero. It operates as a real-time, hardware-isolated kernel that evaluates human intent and path-dependent causal state transitions in a non-commutative, deterministic manner. Specified

1 · Real-time non-commutative intent evaluation

Statistical token-correlation engines such as autoregressive LLMs treat inputs commutatively. EDAA^™ evaluates intent in a non-commutative way, where order changes the result:

In operational workflows the sequence of execution dictates validity. Executing action A (identity verification) before action B (fund disbursement) yields an admissible state; executing B before A is an invalid breach. EDAA^™ models transitions as linear matrix transformations on state vectors where the algebraic commutator is non-vanishing:

If a request attempts an out-of-order transition, such as invoking M_B without the prerequisite state established by M_A, the composite transition evaluates to the zero subspace.

2 · Technical architecture: a real-time ensemble of deductive models

EDAA^™ is a suite of proprietary deductive causal models and state-evaluation logic running inside a hardware-isolated, AMD SEV-SNP encrypted virtual machine equipped with NVIDIA Confidential Computing GPUs. It takes the multimodal intent vectors that the Sentio gateway derives from speech, biometrics or text, and executes single-pass evaluations in real time to return deterministic action decisions.

The model suite operates by active inference, derived from the Free Energy Principle: it selects the intervention A_t^* that minimises variational free energy . This resolves cognitive friction and reduces entropy within the user's cognition during high-stress interactions (hot cognition).

Selection rule as stated; the form of

used by EDAA^™ is not disclosed. Proprietary

3 · State space cardinality and tensor representation

EDAA^™ parameterises human intent without concatenating raw text buffers. State trajectories are projected onto a compact 50-dimensional hypercube:

At a coordinate resolution of

, each dimension has 10,001 steps.

Unauthorised or prohibited states are mapped to orthogonal projection subspaces whose spectrum is zero. A trajectory that attempts an illegal state meets an exact zero eigenvalue, which triggers deterministic socket severance in 15 ms. Specified

Zero-eigenvalue lock (

4 · Turing compute volume (FLOPs)

Because state evaluation is decoupled from autoregressive parameter matrices, EDAA^™ runs on classical CPU cores inside the enclave at a fixed 2,863 FLOPs per request: the number of parameters stays the same whatever the request length. In benchmark tests, scaling inputs from basic biometrics to multimodal 64-channel EEG and spatial tracking raised compute by 10 FLOPs, from 2,853 to 2,863 per request, which Virtue attributes to its tensor-network state parameterisation scaling independently of raw input complexity. Measured

Read with careWhat the equations above do and do not disclose

The equations state the properties EDAA^™ is designed to have: order-dependent transitions, a zero-eigenvalue lock on forbidden states, a fixed 50-variable state and a free-energy selection rule. They do not disclose the matrices, how the 50 variables are computed, or the form of . A reader can check the properties against behaviour, not against the mechanism.

The request path

A customer application opens a session with Sentio through the data center's load balancer, over end-to-end HTTP/2: a gRPC stream for real-time speech, or a REST call.
For streaming voice, Sentio buffers audio until it detects a configured period of silence, then closes the buffer and treats the utterance as one request.
Audio is transcoded to a standard format and sample rate.
The vectorization service converts the input into a fixed-length vector. This is the heaviest compute step in the platform.
Sentio sends the vector and an opaque tenant identifier to EDAA^™.
Inside the enclave, up to five of the roughly fifteen resident models evaluate the vector. The analysis and the interaction record are written to the encrypted datastore.
The analysis returns to Sentio, which builds the response objects and, where configured, passes the enriched context to the customer's own model.
Interaction telemetry flows to the data tier for warehousing. Cause-and-effect data is recorded inside the enclave and, once enough has accumulated, feeds DCA training.

Why the dedicated machine stays modest

A streaming session is held open for as long as the customer speaks, plus the silence window. At peak that is several thousand concurrent sessions, all held in the compute tier on ordinary virtual machines. The enclave handles only short calls carrying a small vector, so its size is governed by model latency, not by how long anyone spoke.

Response time

For voice requests, response time is budgeted as a Response time is budgeted as a real-time factor (RTF) against the length of what the user said:

Measured from the moment Sentio closes the audio buffer to the moment the response is delivered. The silence-detection window is an interaction design parameter and is excluded. Specified

The real-time factor applies to voice requests only. All other requests, such as text and triggers, have a flat response time between 900 ms and 1.5 s. Specified

Figure 4. RTF 1.5 applied to a two-second voice utterance, drawn at 80 px per second except the silence window. Expected utterances are ordinary spoken questions of up to about seven seconds, giving a budget of up to 10.5 seconds.

Behaviour at capacity

Each deployment tier has a request-rate ceiling. Above it, real-time requests are refused with an explicit response, not queued: holding a real-time interaction past its budget produces a failed interaction more slowly and at higher cost. Content ingestion and batch work are queued and drained by autoscaled workers. Autoscaling does not protect the real-time path, because starting a worker and loading a model takes tens of seconds, so real-time capacity is provisioned ahead of demand. Specified

03Key results

The results below are reported in the DCA research paper published on Zenodo, which sets out the method, the data and the full figures. Read the paper on Zenodo.

Result	Value	Context
Aggregate operational incidents	−75%	HERS field deployment: 29 tram drivers, two months, against the operator's data from previous years Measured
Signals passed at danger	0	From 1.11–1.37 per monitoring period before deployment Measured
Emergency brake applications	≈−73%	From 3.35–4.12 per period to 1 Measured
Anticipatory lead time	5 min	State shift detected before an event, allowing a warning ahead of it Measured
Simulation scale	10,000	Human digital twins, more than 190,000 sequential perceptions Measured
Peak request rate reached	1,000 RPS	Production, Virtue's centralized cloud deployment, same technology as the data center design Measured
Compute per request	2,863 FLOPs	The EDAA^™ models executed per request Measured

The field deployment is a before-and-after comparison without a concurrent control group.

04Operating DCA

The hardware commitment is two dedicated enclave machines per site, one primary and one standby. Everything else runs as ordinary virtual machines on the virtualization platform already in place (VMware vSphere, Nutanix, OpenStack or KVM). No new hypervisor, storage array or network fabric is required.

4.1Five hardware invariants

AMD SEV-SNP enabled in BIOS, secure processor operational. SEV-SNP encrypts guest memory with keys held by the processor and adds integrity protection so the hypervisor cannot remap or replay the guest's pages (AMD white paper). The confidential VM cannot launch without it. This specification assumes AMD EPYC processors.
GPU in Confidential Computing mode, NVIDIA H100 or H200, with the shipped driver and firmware (NVIDIA documentation). Training runs on customer data that never leaves the enclave, so the accelerator has to sit inside the protected boundary.
Local NVMe only. Shared or network storage defeats the boundary.
Bare metal, single purpose. No hypervisor beneath the enclave and no co-hosted workload. A hypervisor under an enclave whose purpose is to exclude the hypervisor operator defeats the design.
Physical separation of primary and standby, separate racks and power where the site allows.

If your data center runs NVIDIA-based infrastructure

Many data centers are built mainly around NVIDIA hardware. The specification above is the reference design, not a precondition for talking to us. Where your estate differs, Virtue will try to accommodate it: during readiness we work with your team on how the enclave can be installed on the hardware you already operate, and adapt the deployment where the platform allows.

Enclave machine	Tier 1 · 250 RPS	Tier 2 · 500 RPS	Tier 3 · 1,000 RPS
Processor	2 × EPYC 9004, 32 cores per socket	2 × EPYC 9004, 32 cores per socket	2 × EPYC 9004, 48 cores per socket
Memory	256 GB	384 GB	512 GB
GPU	1 × H100 or H200, CC mode	Same	Same; H200 (141 GB) where a 70B-class connected model will be trained
Storage	4 × 3.84 TB NVMe, RAID 10	8 × 3.84 TB NVMe, RAID 10	8 × 3.84 TB NVMe, RAID 10
Network	10 GbE bonded	10 GbE bonded	10 GbE bonded
Virtual machines	19	24	28

Select a tier against two figures: the peak request rate to be guaranteed, and the largest connected model whose adapter will be trained. The second matters because the GPU must hold that model's weights alongside the training workload; open-weights models from 7B to 70B parameters are supported, and the encrypted volume also holds a staged copy of each such model. Above a tier ceiling the platform continues to serve, but response time is no longer guaranteed. Specified

DetailVirtual machine allocation by role

Role	vCPU	RAM	Disk	T1	T2	T3
Ingress proxy	8	16 GB	100 GB	2	2	2
Kubernetes control plane	8	16 GB	200 GB	3	3	3
Gateway and portal	16	64 GB	200 GB	2	3	3
Vectorization	16	64 GB	200 GB	2	4	8
Transcoding, services	16	64 GB	500 GB	2	2	2
Data workers	16	64 GB	500 GB	1	2	2
Streaming ingestion	8	32 GB	1 TB	3	3	3
Analytical warehouse	16	128 GB	2/3/5 TB	3	3	3
Transformation	8	32 GB	200 GB	1	2	2

Vectorization is the largest compute line and sits outside the enclave, so it can move to ordinary, non-confidential GPUs where spare capacity exists, reducing the CPU worker count by up to 60%. That is the one place in the design where an accelerator buys throughput more cheaply than processors.

Sizing sketch

Sustained request rate 100 RPS

Warehouse retention 3 months

Utterance length 2.0 s

Peak rate to guarantee 250 RPS

750 GBwarehouse data, before replication

3.0 svoice response budget at RTF 1.5

Tier 1smallest tier covering the peak

Warehouse , derived from 1 TB per month at 400 RPS. Tier also depends on the largest connected model; confirm during readiness.

4.2Network essentials

DCA is internal. It is not exposed to the public internet, and the DNS name belongs to the data center. The existing load balancer owns the virtual IP with the two ingress nodes as backend members: no VRRP and no additional load-balancing product. HTTP/2 with ALPN must run end to end through the load balancer, with no downgrade to HTTP/1.1 and no request buffering, because streaming interaction does not survive a downgrade. The load balancer idle timeout sits at or above the longest expected session including the silence window. The enclave tier is reachable only from the compute tier. An accurate time source is required by all hosts, since enclave verification and one-time passcodes both depend on it. Virtue engineering reaches the site through a jump host that the data center logs and audits. Specified

4.3Custody: the key nobody holds

The interaction datastore is encrypted with a key generated inside the enclave and bound to its verified state and to the physical processor. It is never written out, transmitted or escrowed. Neither the data center nor Virtue can recover it. That is what makes the privacy claim hold, and it has a cost.

Event	Effect on stored interaction data
Enclave restart	None. The key is re-established.
Host OS patching outside the enclave	None.
Planned enclave update through the controlled procedure	None. State is exported inside the running enclave and re-protected against the new image.
Unplanned change to the enclave image	Permanently unreadable
Platform firmware change	Permanently unreadable
Mainboard or processor replacement	Permanently unreadable

The warm standby enclave holds a continuously updated sealed replica, with keys established directly between the two enclaves, so the guarantee holds across both machines. Promotion to the standby is exercised during acceptance. Where permanent loss on total hardware failure is not acceptable, a two-party split escrow is available as an alternative custody model, at the cost of the "held by nobody" property. Specified

4.4Threat model

Scenario	Protected	Mechanism
Hypervisor or platform admin reads enclave memory	Yes	Memory encrypted by the processor; keys not available to the host
Storage media removed from the chassis	Yes	Volume key exists only inside the running enclave
Site staff extract the proprietary models	Yes	Models arrive encrypted; usable only in an enclave that has proved its identity
Virtue staff read customer data	Yes	Virtue does not hold the volume key
Customer's model weights exposed to Virtue or site staff	Yes	Weights held inside the enclave under the same protection
A compute tier node is compromised	Partial	Audio and vectors in flight are exposed; stored history is not reachable
Malicious code inside the enclave image	No	Addressed by release control and verification, not hardware

4.5Zero-knowledge proofs

Zero-knowledge proofs are cryptographic protocols that let one party prove to another that a statement is true without revealing any information beyond the validity of the statement. The architecture uses them in three ways: Specified

Cryptographic human attestation. They act as a cryptographic watermark, verifying that a human originally generated the interaction feedback and that actions are psycho-emotionally safe, without exposing the identity of the human participant.
Compliance and validation. They let third-party auditors, such as SOC 2 auditors, verify system safety and compliance with European AI regulations without compromising individual privacy.
Integration within the enclave. They are integrated into the trusted execution environment to generate verifiable statutory audit proofs alongside the client's sovereign “Encrypted Alpha”.

4.6Data boundary

No customer interaction content leaves the data center. Every external connection is outbound over TLS; no inbound firewall rule is needed for any function.

Crosses the perimeter, outbound

Enclave verification and model key release (blocking if denied)
Signed application images and encrypted model releases
Subscription and tier-limit checks
Allowlisted health telemetry: host, service and enclave metrics, aggregate counters
OS repositories and time source

Never exported

Audio, vectors, transcripts, analyses, triads
Connected model weights, adapters, checkpoints
Feeds, attributes, logics, interaction channels, project definitions
End-user identifiers, tenant names
Keys, secrets, certificates; logs with payloads

4.7Scaling and training capacity

Ingress, compute and data scale horizontally. The enclave scales vertically, because the models cannot leave it: a larger chassis, then a four-socket platform, then a second enclave with tenants divided between them.

Training runs on the enclave's single GPU as a batch queue, serial by default. Concurrent jobs fit only when their base models fit in GPU memory together, and GPU partitioning is unavailable in Confidential Computing mode. A training run takes hours; ten tenants reaching the threshold in the same week is a delivery window measured in days. Because live evaluation runs on CPU, a deep training queue never slows interactions. Specified

4.8Releases and entitlement

DCA retains version authority for models and the enclave image; sites do not select their own versions, which keeps behaviour consistent across deployments. Delivery is initiated outbound from the site, and model artefacts use the same transport and signing scheme as application images. Where outbound access is unavailable, the same signed artefacts are delivered to a local mirror or on removable media. Per-tenant limits are enforced from the subscription tier, so rate limiting and entitlement are one mechanism. The telemetry collector configuration is a deployed artefact the data center can read at any time; any change to its allowlist is a versioned change, not an operational adjustment. Specified

4.9Who operates what

Data center	Virtue
Racking, power, cooling, firmware, hardware replacement	Hardware specification and verification
Network, load balancer, DNS, certificates, firewall	Requirements and validation
OS and Kubernetes node patching outside the enclave	Cluster build, platform application, upgrades
Monitoring, first and second line, capacity	Third line, runbooks, enclave incidents
Administration of your own tenants	Enclave image and model releases, exclusively

05Using DCA

You become a tenant of the DCA instance your data center operates. Connecting a model of your own is optional. What changes with your choice is what you receive.

Figure 5. The difference between the three options is one edge: open weights staged into the enclave, which adds the adapter as a second output. Every tenant receives the cause-and-effect model. Proprietary API models such as GPT or Gemini fall under the second lane because their weights cannot be obtained. The adapter is optional and not Virtue's recommended path.

Two integration modes

The data center can use the Virtue portal as its administration console and call the APIs for interaction traffic, or build its own portal and use the APIs as a backend. Both modes run at once on the same deployment for different customers. Portal sign-in for administrators is by email one-time passcode through the data center's own mail relay; self-registration is disabled and federated sign-on is not available in the current release. Specified

Connecting a model is a feeding step, not a routing setting

Registering a connected model does more than tell the gateway where to send traffic. DCA draws on the connected model's knowledge to build solutions on top of it, which is why model connection sits in the parametrization sequence rather than in network configuration. A customer who connects nothing still runs a complete experience from their own feeds and logics.

The cycle

Connect (optional). Your model is hosted in the data center and its connection registered with DCA. For open weights, the weights are staged into the enclave's encrypted volume once.
Build. Create projects and configure feeds, attributes and logics.
Observe. Interactions run through DCA. Triads accumulate inside the enclave.
Train. Your job enters the training queue and runs on the confidential GPU.
Continue or leave. Keep DCA running for refreshed outputs as interactions change, at no extra cost beyond the hardware already in use, or stop and keep what was produced.

What you own

The cause-and-effect model is a standalone file in ONNX or H5 format, delivered per tenant. It is usable without DCA running. The adapter, where trained, loads onto the model you already own and host. Exit is a working artefact, not a migration project. Specified

Both outputs leave the enclave through its one export path and are signed on the way out, so you can verify they were produced inside an enclave that passed verification. Training data, base weights and intermediate checkpoints have no export route.

Virtue's recommendation on the adapter

The adapter (LoRA) is available, but Virtue does not recommend it as the path to take. Staying on the DCA architecture carries no extra cost beyond the hardware the data center already provides and is already paying for, and it keeps the tenant's cause-and-effect model current as interactions change. That continuing, causal understanding of users is the tenant's unique selling point; a one-off adapter freezes it at the moment it was exported.

What makes this different from fine-tuning

DCA does not train on historical records. It trains on cause and effect observed across live mediated interactions: what the person brought to the interaction, what the system did, and what followed. That signal does not exist in a transcript archive and cannot be reconstructed from one. Where an adapter is produced, it is delivered as a LoRA because that is the efficient, portable way to ship it. The format is ordinary; what it was trained on is not. Both outputs are small against a base model: typically a few hundred megabytes against tens of gigabytes.

Roles and your users' identity

Four actors exist on a deployment. The platform administrator, held by Virtue only, administers across all clients and tenants. The client is the data center, which manages the tenants beneath its assigned solution and sees tenant assets from an insights point of view. Each tenant is one customer account, isolated absolutely from every other tenant. External users are the people interacting with an experience; they have no administrative access.

DCA never holds personal details of your end users. Each is registered as an external user with an opaque alphanumeric identifier. Mapping that identifier to a real person happens in your own database and stays there. No name, email address or phone number is required by or stored in the platform, whichever integration mode the data center chose. A tenant sees only its own feeds, attributes, interaction history, model registration and outputs; every feature and action is gated by a granular permission.

ComplianceDelivery of a model trained on your users' interactions

The model is delivered only to you, the party that already holds the underlying data and determines how it is processed; Virtue performs no cross-border transfer as part of this cycle. Training data contains no direct identifiers.

Readers should know that trained models can memorise training data, and European regulators do not treat model weights as automatically anonymous (EDPB Opinion 28/2024). Your data protection assessment should cover the model files you receive, including where you move them. The platform is designed to support GDPR, SAMA and NDMO requirements; it is not certified against them.

Designing for refusals

At the data center's tier ceiling, the interaction endpoint refuses new real-time requests with an explicit response. Treat that as a normal condition: retry or degrade according to your experience design. A refusal means the site is at its guaranteed capacity, not that something failed.

06Limits and open problems

Undisclosed mechanism. EDAA^™'s internals are proprietary, so external readers cannot audit how state is computed or how effects are identified. Trust rests on measured outcomes and on the enclave's verifiable boundary.
Causal identification from system-chosen actions. When a system chooses its actions based on the user's state, observed outcomes mix the effect of the action with the reasons it was chosen. This is a general problem for any system learning from its own interventions. DCA's handling of it is part of the proprietary method and has not been independently evaluated.
Evidence base. One uncontrolled field deployment, one simulation, and production throughput measured on cloud infrastructure rather than the enclave.
Locks are asserted, not externally verified. The zero-eigenvalue lock is a stated property of a proprietary mechanism; no independent evaluation of its failure rate has been published.
Durability. Stored interaction data is unrecoverable after total loss of both enclave machines, by design.
Trusted image. Hardware protects the enclave from its host, not from defects in the enclave image itself.
Training throughput. One GPU per enclave; adapter training for large models is effectively serial.