TRAIN is a managed Causal AI application installed inside infrastructure you control. The architecture is infra-agnostic (container, virtual machine, or internal HPC) and runs on cloud, on-premises or hybrid. Software installation typically takes one to two weeks after infrastructure readiness; a scoped pilot or application rollout typically takes 6–12 weeks, depending on data and validation requirements. Parabole supports configuration, updates and maintenance from there.
Scroll down · delivery, the three architectures, and requirementsThe platform is delivered through a secure, credential-protected portal or supported cloud marketplace, with signed installers, infrastructure templates, a manifest, release notes, and checksums.
Local and network installer packages, ARM templates for Azure, and Terraform configurations for multi-cloud. A manifest carries version details, release notes and SHA-256 checksums; optional configuration files and scripts are digitally signed.
Secure, credential-protected HTTPS links by portal or email, or Azure Marketplace for one-click provisioning. Patches and upgrades are delivered the same way as the initial deployment, with email notification of each release.
Semantic versioning (for example, v1.2.0) supports traceability. The license is organization-specific and validated during installation; it defines access and feature entitlements for the deployment.
Every model runs the same platform components: a network layer, teaching and runtime services, language and optimization services, and the stateful stores. What changes is how the compute is packaged. Each diagram shows the components, their interconnections and deployment tiers, inside your private network.
Platform components run as isolated, scalable containers under an orchestrator such as Kubernetes: high availability, horizontal scaling, rolling updates and fault isolation, suited to teams already running CI/CD and cloud-native practices. Services split across a data-services node, a CPU node set and a GPU node set; databases and messaging run as managed services or self-hosted in the cluster.
| Resource | Description | Configuration | Runs |
|---|---|---|---|
| Data services node | Node, no GPU | 16 core · 128 GB RAM | User management, application frontend |
| CPU node set | Node set, no GPU | 16 core · 128 GB RAM | API services, data & knowledge services |
| GPU node set | Nodes with GPU | 80 GB VRAM | Language services, teaching & runtime services |
| Databases | Managed or self-hosted | 16 core · 128 GB RAM (self-hosted) | PostgreSQL and GraphDB |
| Storage | Cloud object storage | N/A | Artifact storage |
Best for · cloud-native teams · CI/CD · elastic scaling
Each core service runs on a dedicated virtual machine (separation of concerns, resource isolation and straightforward debugging), for environments where container orchestration isn't available or preferred: on-premises or regulated cloud setups needing long-running VMs, tight control over the OS and networking layers, manual provisioning and custom security hardening.
| Server | Type | Configuration | Runs |
|---|---|---|---|
| Server 1 | VM with GPU | 40 GB VRAM · 60 core · 480 GB RAM | Parabole platform: teaching & runtime |
| Server 2 | VM, no GPU | 16 core · 128 GB RAM | Utility services, graph database |
| Server 3 | VM with GPU | 80 GB VRAM · 60 core · 480 GB RAM | Language services |
| Server 4 | VM, no GPU | 8 core · 64 GB RAM | Optimization service |
| Storage | Cloud / local disk / NAS | N/A | Artifact storage |
Best for · on-premises · regulated cloud · traditional IT operations
For organizations with internal high-performance computing (HPC), the TRAIN server hosts application services and submits GPU workloads (including language modeling, training, and inference) to the cluster through SlurmCTLD.
| Resource | Description | Configuration | Runs |
|---|---|---|---|
| TRAIN server | On-prem Linux VM | 60 core · 512 GB RAM | Teaching, runtime, job & utility services, GraphDB, PostgreSQL |
| SLURM head node | HPC controller | Managed by customer IT | Accepts job submissions |
| SLURM compute nodes | GPU-enabled HPC nodes | 80 GB VRAM | Executes ML / AI workloads |
| Shared storage | NFS or parallel file system | High IOPS, reachable by both | Model data and job output |
Best for · sites with an existing Slurm-based HPC cluster
The architecture supports multiple applications on a shared platform instance. Commercial terms scale by deployment, model, and application scope.
Each environment (its own hardware and software, its own MES, ERP, SCADA and historian) runs one instance. Environments never share an instance, so a deployment in one region and one in another scale, upgrade and are governed independently.
A single instance serves many sites. Bringing a new plant onto an existing instance is a configuration and connectivity step against infrastructure you already run, not a new deployment.
Every causal model is pinned to one point in the plant: a site (the data origin), a manufacturing process and a product or family. Change any one coordinate and it is a different model; keep all three and one model covers that address. Retraining and updates keep the same address; they do not create a new model.
Multiple causal applications can run on a governed model. Licensing and metering are defined in the applicable commercial agreement.
Azure deployment is supported through ARM templates; supported cloud environments can be provisioned through validated Terraform configurations.
Full control of the OS, network and upgrade path, including air-gapped environments.
Integrates cloud and on-premises resources, including HPC and edge nodes.
| Method | When to use |
|---|---|
| Local installer | Air-gapped or on-premises environments with no internet access or strict security controls. Transfer the package, run the installer, validate. |
| Network installer | Environments with outbound HTTPS access to the Parabole repository: the quickest path where internet access is allowed. |
| ARM template | Azure-only deployments that want native platform integration. |
| Terraform | Custom or multi-cloud and hybrid deployments that need flexibility across providers. |
| HPC integration | On-premises environments with a Slurm-based HPC cluster; requires shell access to submit jobs to SlurmCTLD. |
Hardware is listed per architecture above. These requirements are common to every model.
| Layer | Requirement |
|---|---|
| Operating system | Ubuntu 22+ or RHEL 8+ (64-bit, systemd) |
| Runtimes | Python 3.10+ · OpenJDK 17+ |
| Databases | PostgreSQL 15+ (on-prem or cloud-managed) · Ontotext GraphDB 10+ or equivalent RDF store |
| Messaging | Kafka and Zookeeper for data ingestion |
| GPU | CUDA 12.4+ with NVIDIA drivers |
| Web | Nginx for UI, reverse proxy and SSL |
| Containers (if used) | Docker · Kubernetes 1.25+ · Helm 3.10+ |
Inbound: 443 HTTPS, 22 SSH, 8585 APIs, 8888 UI, 5010 internal. Static DNS entries for service discovery and SSL. The network installer additionally needs outbound 443 to the Parabole repository, proxy-aware for corporate firewalls.
Cloud object storage (Azure Blob, OCI Object Storage) or local high-IOPS storage for logs, models and backups. Backups are run by the customer's IT team according to organizational policy.
Supports least-privilege IAM/RBAC, MFA for privileged access, audit logging, encryption at rest, and TLS in transit. Supported secrets-management integrations are confirmed during architecture review.
High-availability and disaster-recovery options, including supported multi-region patterns, are defined during architecture review; RPO and RTO are agreed in the applicable SLA.
A RACI split makes ownership explicit across infrastructure, security and the installation itself.
| Task | Cloud admin | DevOps / customer IT | Security admin | Vendor support |
|---|---|---|---|---|
| Infrastructure provisioning | R | A | C | R/C |
| Network configuration | R | C | A | R/C |
| Deployment script execution | C | R/A | I | R/C |
| Security & access configuration | C | R | A | C |
| Platform installation | C | R/A | I | R |
| Post-install validation | C | R | C | R/C |
| Backup & DR setup | R | A | C | C |
| Monitoring setup | R | A | C | C |
| Troubleshooting & support | C | R | C | R/A |
R responsible · A accountable · C consulted · I informed. Roles needed: cloud administrator, DevOps engineer or customer IT, security administrator, and Parabole vendor support, with working knowledge of Linux CLI, YAML and Bash, Terraform or the Azure CLI, and SSH / TLS / VPN / firewall administration; Kubernetes where the container model is used.
Duration depends on complexity. A pre-check script validates the environment before anything is installed.
Define scope, assign roles against the RACI, and confirm prerequisites. Run precheck.sh from the package to validate CPU, RAM, Python, CUDA, open ports, DNS resolution and disk.
Stand up servers or nodes, networking and storage for the chosen architecture.
Run the installer for the chosen method, then wire in external data sources (object storage, PostgreSQL, GraphDB) and define user roles and permissions from the admin dashboard.
Confirm that the health endpoint returns 200 OK, review logs, and run smoke-tests.sh. Monitor CPU and memory utilization, GPU availability, database health, and latency.
Document the deployment, train the operating team, and transition to support.
Regular releases for bug fixes, features and security patches, delivered the same way as the initial deployment. Customers are notified by email of every new release or patch.
Logs are stored under <parabole-path>/logs/. For installation, API, or license errors, review the service logs and troubleshooting guide before contacting support.
Response targets are defined by severity and the applicable support agreement. Contact support@parabole.ai with a summary, diagnostics, and priority.
Bring your cloud, DevOps and security leads. We will map TRAIN onto your environment and agree the topology at an architecture review.