Deployment Models · Expectation Management

We know where you are.
Here is how you get to where you need to be.

DXMachine is a workflow execution platform. AI agents participate in completing regulated compliance workflows — and the attestation architecture is what makes those agents legally and regulatorily acceptable. The full architecture runs on bare metal. That is not where every organization starts. Here is the honest path from where you are today.

A note on bare metal: The bare metal execution model is not ideological. It is the only architecture that allows hardware-level attestation — a TPM 2.0 measured boot chain that lets an examiner verify not just what a log says, but that the system producing it was running exactly the software it claimed. Azure and Kubernetes can run DXMachine workflows. They cannot produce the same attestation guarantees. We will tell you exactly what that means for your compliance posture.
Three Deployment Tiers

Start where you are.
Build toward where you need to go.

No organization is required to start on bare metal. The architecture is designed to deliver value at every tier — with honest documentation of what each tier can and cannot attest to.

Tier 1 · Legacy Compatible
DXMachine on Existing Infrastructure
Run DXMachine workflows on your current cloud, VM, or container environment. Lower deployment friction, reduced attestation scope.
Right for: Organizations evaluating DXMachine, managing existing tool debt, or operating in environments where infrastructure change requires long approval cycles.
Tier 3 · Full DXMachine
Bare metal, purpose-built Agent Host
Purpose-built Linux image, TPM 2.0 hardware attestation, full capability enforcement. The complete architecture. Maximum regulatory defensibility.
Right for: New workflow deployments, defense and ITAR-controlled environments, highest-stakes compliance, organizations for whom examiner-ready proof is a hard requirement.
Detailed Comparison

What each tier delivers —
and what it honestly does not.

Every row below reflects the real architectural difference between tiers. The expectation management column is not fine print — it is the most important column on this page.

Dimension Legacy · Tier 1
Existing Infra
Hybrid · Tier 2
Mixed Deployment
Full DXMachine · Tier 3
Bare Metal Agent Host
Execution Environment Your existing cloud, Azure, K8s, or VMDXMachine workflow engine runs on general-purpose infrastructure you already control. DXMachine Agent Host alongside existing infraCompliance-critical workflows run on the Agent Host. Other systems continue unchanged. Purpose-built Yocto Linux imageNo general-purpose OS. No shell. No SSH. No installer. Absence is structural, not advisory.
Hardware Attestation Workflow records onlyAudit trail reflects what DXMachine recorded. No cryptographic proof of execution environment integrity. Full attestation on DXMachine-managed workflowsTPM 2.0 measured boot on Agent Host workloads. Legacy workloads carry standard records only. TPM 2.0 measured boot — full chainHardware-backed signing key. Cryptographic record of every component loaded at startup. Examiner-verifiable.
AI Agent Trust Model Advisory policyAgent capabilities governed by application-layer controls. Enforceable within DXMachine but not at the OS layer. Capability-gated on Agent Host workloadsSigned JSON capability manifests for workflows running on the Agent Host. Standard controls elsewhere. Structural enforcement — absence is physicalA capability that does not exist cannot be exploited. No shell means no shell. Not a policy. Not a configuration.
Regulatory Defensibility Documented workflow recordsAudit-ready artifacts for DXMachine-managed work. Examiner will ask about execution environment. Honest answer: general-purpose infrastructure. Defensible for Agent Host workflowsHardware attestation available for compliance-critical workflows. Examiner can verify execution environment for those workloads. Examiner-ready, cryptographically verifiableEvery execution record signed by a TPM-resident key. Examiner can verify not just the log but the system state that produced it.
ITAR Suitability Not recommendedCloud or shared infrastructure creates potential unauthorized export exposure for ITAR-controlled data. Legal review required before use. Suitable for ITAR workflows on Agent HostITAR-controlled workflows routed exclusively through on-premises Agent Host. Segregation must be enforced by deployment architecture. Designed for ITAR environmentsCompute runs on hardware you control, in a facility you control. No foreign cloud exposure. Sovereignty is structural.
Pricing Model Standard token exchange spreadDomain-specific markup on AI compute. Specific mechanics co-developed with design partners. Tiered — Agent Host workflows at full rate, legacy at standard ratePricing reflects value delivered per workflow tier. Hybrid deployments priced by workload type. Full value-based pricingToken exchange spread differentiated by workflow domain. CMMC Level 3 commands different margin than a change advisory workflow. The architecture captures that difference.
Migration Complexity
Low
Deploy on existing infrastructure. Standard integration. Fastest path to first workflow running.
Medium
Agent Host provisioning alongside existing systems. Workflow routing decisions required. Weeks to initial deployment.
Greenfield or parallel run
New workflows start here. Existing workflows transition over a defined period. Highest setup investment, highest long-term return.
Expectation Management Get you in the door. Prove the workflow value.A regulator who asks about your AI execution environment will receive an honest answer: general-purpose infrastructure. This is the evaluation tier, not the production compliance tier for high-stakes examination workflows. The realistic path for most organizations.Most enterprise customers start here. Compliance-critical workflows get full attestation. Legacy workflows transition on their own timeline. This is how regulated organizations actually adopt new infrastructure. The architecture delivering its full thesis.This is what DXMachine was designed for. Not every organization starts here. Every organization with serious compliance obligations should plan to get here.
The Bare Metal Argument

Why the architecture is the way it is —
and why we are honest about the tradeoffs.

The bare metal requirement is the most unusual claim on this site. It deserves a direct explanation rather than a marketing paragraph.

Why bare metal
TPM 2.0 attestation requires a measured boot chain that starts at the firmware layer. A hypervisor or container runtime breaks that chain. You can attest that a VM is running a certain image — but the attestation is produced by software running above the hardware, not by the hardware itself. For an examiner who needs to verify execution environment integrity, that is a meaningful difference. Bare metal is the only path to hardware-root attestation.
The honest tradeoff
Bare metal limits deployability. Most enterprises run Kubernetes, VMs, or cloud platforms. Requiring bare metal creates adoption friction, longer procurement cycles, and a harder initial conversation. We accept this tradeoff deliberately. The organizations that need hardware attestation — defense contractors, ITAR-controlled environments, financial institutions under examination — cannot get it any other way. We built for them first.
Why Azure is a viable starting point
Azure, AWS, and GCP can run DXMachine workflows. The workflow engine, the EAV card model, the board architecture, the audit trail — all of this works on general-purpose infrastructure. What you cannot get on cloud infrastructure is hardware-root attestation. For organizations whose compliance posture does not require it today, that is a fine place to start. The architecture is designed so you can transition to bare metal when your requirements demand it.
Why not just use a TEE
Trusted Execution Environments (Intel SGX, AMD SEV) offer hardware-backed isolation on cloud infrastructure. They are a legitimate architecture. They also introduce significant complexity, vendor dependency, and attestation surface area that we believe is harder to explain to a regulator than a simple bare metal deployment. Our architecture is designed to be auditable by a compliance examiner, not just a security researcher. Simplicity of the trust model is a feature.

"The question is not whether Azure is trustworthy. The question is whether the examiner will accept 'we used Azure' as a sufficient answer. For some workflows, yes. For others, no. We will tell you which is which."

The Honest Part

What we will not
tell you.

We will not tell you that Tier 1 delivers the same compliance posture as Tier 3. It does not. The audit trail is real in all tiers. The hardware attestation is only available in Tier 2 and Tier 3. An examiner who specifically asks about execution environment integrity will receive a different answer depending on which tier you are on. We believe you should know this before you buy, not after your first examination.

We will also not tell you that the transition from Tier 1 to Tier 3 is trivial. It requires infrastructure decisions, procurement cycles, and organizational change. The hybrid path exists because we understand that regulated organizations cannot rebuild their infrastructure in a quarter.

What we will tell you is that the workflow value — the card model, the audit thread, the AI agent participation in completing compliance work — is real at every tier. You are not buying a governance layer. You are replacing the specific compliance workflows your team is managing in spreadsheets and disconnected tools, with a platform that produces examiner-ready artifacts as a native output of normal work.

The tier determines the strength of the attestation. The workflow value is present regardless of tier.

Tell us where you are.
We will tell you the honest path forward.

No SDRs. No drip campaigns. A direct conversation about your compliance environment, your infrastructure constraints, and which tier makes sense for where you are today.