Core Concepts¶
📦 v0.1.0 — CLI-first. Three products ship (ahmed, drivaer-notchback, onera-m6). These are the only products solvers and agents can interact with. Product scaffolding and custom geometry are coming in v0.2.0. Post-launch (gated): visualisation, releases, freezing.
This page covers the foundational ideas behind Arxyne. Understanding these concepts will help you reason about what the platform does and why.
USD Twin — Single Source of Truth¶
Every product in Arxyne is an OpenUSD composition. USD provides the schema, the layering semantics, and the composition engine. All tools — CLI, Python API, MCP gateway, agents — read from and write to the same USD stage.
Each product is a stack of composition layers with defined opinion strength (weakest → strongest):
| Layer | Content | Status |
|---|---|---|
| Design Intent | Targets, specs, requirement traceability | Populated |
| Benchmark | Competitors in same schema | Per-product |
| Prototype | Simulation results, provenance | Live |
| Manufacturing | Factory config, BOM | Stub |
| In-Service Twin | VIN, telemetry, OTA | Stub (strongest) |
Design intent is strongest in practice — layers 4–5 are stubs for current products.
Dynamic sublayers extend the composition:
simulation_runs/<solver>/<timestamp>/result.usda— per-run KPI resultsreleases/<version>.usda— named, frozen lifecycle snapshotstrajectory_<manoeuvre>.usda— Chrono pose for Omniverse replay
Products¶
A product is defined per-programme in products/<product>/. It declares:
- A display name and type (
sedan,wing,research_body, …) - Engineering targets for each KPI (
arxyne:target:cd,arxyne:target:lateral_g, etc.) - A
solverCaseTemplatebinding that maps the product to solver geometry - Requirement traceability as nested
arxyne:req:*scopes
Products can have variants — design branches that inherit from the parent via USD sublayers and override only what differs. Variant support is planned for v0.2.0.
Targets & Traceability¶
Engineering targets live in the product's design_intent.usda layer as namespaced attributes:
double arxyne:target:cd = 0.299
double arxyne:target:cd_tolerance = 0.05
double arxyne:target:cl = 0.345
double arxyne:target:cl_tolerance = 0.245
The requirements hierarchy — from programme goal down to engineering targets — is preserved as traceability context using nested Scope prims with arxyne:req:description and arxyne:req:level attributes. This provides audit lineage from market intent to gate-driving values.
Gates¶
Gates are the validation mechanism: each solver KPI result is compared to its design-intent target.
The workflow derives the solver domains a product needs (e.g. aero,
dynamics), dispatches the solver, reads the result, and evaluates:
- Aero KPIs (
cd,cl,cm_pitch):within— |result − target| ≤ tolerance → PASS - Dynamics (
lateral_g):gte— result ≥ target → PASS - Other dynamics:
lte— result ≤ target → PASS
Gate status vocabulary:
PASS— result meets the targetFAIL— result violates the targetNO_TOL— tolerance missing, gate cannot evaluateINCONCLUSIVE— no gates evaluated (never reported as pass)
The Three Verbs¶
Every interaction with Arxyne maps to one of three verbs:
| Verb | CLI | Role |
|---|---|---|
| AUTHOR | --brief "..." |
LLM-driven. Agent receives intent, runs simulations, assesses results. |
| EXECUTE | --run-workflow |
Deterministic. Derives domains, dispatches solvers, evaluates gates. No LLM. |
| READ | --ask "..." |
LLM-driven. Conversational query against the USD twin. |
This separation is load-bearing for certification: workflow execution is reproducible and auditable because no LLM participates in the gating loop.
MCP Gateway + Platform API¶
Arxyne exposes its capabilities through a single Model Context Protocol gateway plus a direct Python API for the USD twin:
| Surface | Purpose | Operations |
|---|---|---|
| MCP Gateway | Dispatch simulations to any solver (OpenFOAM, XLB, Chrono, DoMINO) on one port | Write |
| Platform API | USD product twin, gates, provenance (Python / CLI) | Read + Write |
Any MCP-compatible agent framework can dispatch Arxyne solvers and query the twin directly — the CLI is just one transport. All solvers run through one gateway as pure Docker containers; the gateway can run locally, on-prem, or on a remote GPU host.
Architectural boundary
There is no Geometry/PLM MCP as a peer. Arxyne does not own CAD preparation. The input boundary defines what prepped geometry looks like; upstream tools (ANSA, HyperMesh, CAD-side agents) produce it. Arxyne validates and consumes.
Why Workflow Execution is Agent-Free¶
This is a deliberate architectural choice:
- Deterministic = certifiable. An LLM in the gating loop would make the audit trail non-reproducible. Regulators sign off on the process — the process must replay identically.
- The agent's value is upstream and downstream, not in the middle. Upstream: turn intent into requirements (
--brief). Downstream: interpret failures and propose iterations. The execution itself — compute Cd, check against target, write status — is a deterministic function. - Lower latency, lower cost, fewer failure modes. No LLM calls in the hot path means faster workflow runs and no risk of malformed gate decisions.
The platform's posture: agents are brains that author intent and interpret results. Arxyne is the harness that executes deterministically between those two phases.