Praxis
From design intent to a signed commissioning package.
Give Praxis a design package and a model of the line it will run on, and it returns one signed artifact: the control logic, the setpoint windows, the motion programs, the coverage on every parameter, and the record of everything it assumed. Or it returns nothing, and names what it was missing.
The contract, both ends.
Reference vertical is footwear, high-mix low-volume — the segment where the cost of commissioning a new SKU dominates and the trial is a production run nobody wanted.
IN
Design intent + line twin
3D last, upper and sole geometry. Graded 2D patterns and the tech pack. BOM with material data sheets. An AutomationML line model with STEP/JT asset geometry, machine capability and I/O structure.
PRIOR
Historical corpus
Past run outcomes, batch and thermal history, material lot variation, observed machine drift, and continuous in-line telemetry where it exists.
OUT
One signed .aasx
A single Asset Administration Shell package per SKU commissioning run, signed across every part.
The artifact is specified before the engines.
Until the shape of the emitted artifact is fixed, the generation layer has no defined contract to build against. So the output was designed first, and everything upstream is constrained by it.
AtomicityA commissioning run is one decision. Splitting it into eleven files invites partial deployment — the cement dryer gets the new profile, the lasting machine does not.
SigningSignature coverage across the package is what makes “this recipe was physics-validated on this date against this twin revision” defensible rather than claimed.
TraceabilityOne package ID maps to one production run maps to one field-feedback record. That is what closes the learning loop cleanly.
NeutralityAASX and PLCopen XML are both published open standards, so nothing in the deliverable is hostage to a single controls vendor.
THREE DELIVERY MODES, ONE ARTIFACT
ModeMechanismWhen it is used
Package exportSigned .aasx downloadThe default. Handed to controls engineering for review and import. Archivable, auditable, and works with zero network access to the line.
Direct importPLCopen XML into the vendor IDEThe PLC submodel is extracted and imported into TwinCAT, TIA or CODESYS. A neutral format means we do not maintain N vendor code generators.
Live pushOPC UA write to setpoint tagsNon-PLC parameter stations — dryer temperature, press dwell — where the value is a tag rather than a program. Gated behind explicit human release.
Seven layers. The feedback path is what makes the second SKU cheaper.
Ingestion normalizes heterogeneous inputs into one graph; the physics core solves; the generators emit; the assembler seals. Twenty-one engines sit inside these layers, each with one job and one output contract, so any of them can be swapped without disturbing its neighbours.
L0
Ingestion & Normalization
Parses every input format into one internal representation: the Commissioning Intent Graph.
L1
Process Route Synthesis
Derives the required physical transformations from the geometry itself, then maps each operation onto a station the twin says can perform it. Output: an ordered route.
L2
Physics Solve Core
The differentiator. Solved, not searched.
Differentiable physics kernel
thermal · cure · flow
Neural operator surrogates
fast, mesh-free
Inverse solver
target spec → parameter set
World-memory
path-dependent process history
L3
Recipe Optimization
Search over the feasible parameter space against a multi-objective cost: cycle time, energy, defect risk, material yield. Emits a window, not a point.
L4
Uncertainty & Validation
Conformal prediction bounds on every emitted parameter, then a virtual commissioning pass of the generated logic against the line twin.
L5
Artifact Generation & Packaging
PLC code → PLCopen XML. Setpoints → parameter submodels. Motion → pattern programs. All sealed and signed into one .aasx.
L6
Delivery & Field Feedback
Export, import or live push. Production outcomes return to world-memory, which is what makes the second SKU cheaper than the first.
FIG. 1 — LAYER ARCHITECTURE. L0 → L5 IS THE FORWARD COMMISSIONING SOLVE; L6 RETURNS OUTCOMES TO WORLD-MEMORY AND COMPOUNDS ACROSS SKUs.
Three of these stages can refuse.
A blocked run that names a missing adhesive data sheet is a better product than a completed run that guessed at cure kinetics. The gates are the architectural expression of that.
01
Ingest
Parse and normalize.
02GATE
Completeness
Missing TDS? Stop.
03
Route synthesis
Operations → stations.
04GATE
Capability
No capable station? Stop.
05
Physics solve
Inverse solve per operation.
06
Optimize
Multi-objective, windowed.
07
Bound
Conformal coverage per parameter.
08
Generate
PLCopen XML and setpoints.
09GATE
Virtual commissioning
Fails against the twin? Return to 06.
10
Seal & sign
One .aasx package.
11
Deploy & observe
Outcome returns to world-memory.
FIG. 2 — RUNTIME PIPELINE. GATES HALT THE RUN AND RETURN A NAMED GAP INSTEAD OF PRODUCING OUTPUT. A FAILED VIRTUAL COMMISSIONING AT 09 RE-SOLVES FROM 06.
The engine register.
Twenty-one engines across seven layers, plus three cross-cutting services. Listed in full because an architecture you cannot audit is an architecture nobody can disagree with.
L0 — INGESTION & NORMALIZATION
E1Design Intent ParserReads footwear CAD output, graded 2D patterns and the tech pack. Extracts geometry, seam and stitch lines, part boundaries, material assignment per part.
E2Line Twin LoaderIngests the AutomationML line model plus STEP/JT asset geometry. Builds the station inventory: what machines exist, their kinematics, their controllable parameters, their I/O.
E3Material Property ResolverResolves every BOM line to a physical property set — adhesive cure kinetics, polymer rheology, substrate stiffness. Where a TDS is missing it raises a blocking gap rather than substituting a default.
E4Intent Graph BuilderFuses E1–E3 into the Commissioning Intent Graph, binding geometry to material to target spec to available station. Everything downstream reads only this.
L1 — PROCESS ROUTE SYNTHESIS
E5Operation DecomposerDerives the sequence of physical transformations from the product itself — cut, close, last, cement, mould, cure, press, finish — without assuming a fixed process template.
E6Capability MatcherMaps each required operation onto a station that can physically perform it. Flags operations with no capable station as a tooling or capex gap.
E7Route SequencerOrders operations under precedence and buffer constraints, producing the route the rest of the pipeline solves against.
L2 — PHYSICS SOLVE CORE
E8Differentiable Physics KernelForward and backward solve across the coupled domains that matter in footwear: heat transfer, adhesive cure kinetics, viscoelastic deformation under lasting load, polymer flow and shrinkage in injection.
E9Neural Operator SurrogatesFast, mesh-free approximations of the kernel for use inside optimization loops. Where surrogate and kernel disagree, the kernel is authoritative.
E10Inverse SolverRuns the physics backward: given the target bond strength, dimensional spec or cure state, solve for the parameter set that lands inside the tolerance window.
E11World-Memory StoreHolds path-dependent history — prior thermal exposure, material lot behaviour, observed machine drift — so the solve reflects the line as it is, not as it was specified.
E12Sensitivity ReporterReturns the gradient as well as the answer: how far each output spec moves per unit change in each input parameter. This is what makes the what-if mode possible.
L3 — RECIPE OPTIMIZATION
E13Constrained SearchExplores the feasible parameter space under machine limits, material limits and safety envelopes. Search, not guesswork — and bounded by the physics solve rather than free-running.
E14Multi-Objective EvaluatorScores candidate recipes on cycle time, energy per pair, predicted defect rate and material yield. Weighting is explicit and user-visible, never hidden.
E15Tolerance Window GeneratorEmits an operating window per parameter. A dryer temperature of 78–84 °C with a named centre is deployable; 81 °C alone is not.
L4 — UNCERTAINTY & VALIDATION
E16Conformal Prediction WrapperAttaches distribution-free coverage bounds to every emitted parameter and every predicted outcome. Nothing leaves Praxis unbounded.
E17Virtual Commissioning HarnessExecutes the generated logic and motion programs against the line twin, checking sequence, interlocks, cycle time and collision before any hardware is touched.
E18Credibility AssessorAssembles the V&V argument: which claims are physics-derived, which are surrogate-derived, which rest on historical priors, and what the coverage is on each. Ships as a submodel.
L5 — ARTIFACT GENERATION & PACKAGING
E19PLC Code GeneratorEmits IEC 61131-3 program organizational units as PLCopen XML — Structured Text for recipe logic, Sequential Function Chart for station sequence. Vendor-neutral by construction.
E20Setpoint & Motion EmitterWrites non-PLC station parameters as structured submodels, and motion and pattern programs for stitching jigs and knit machines.
E21Package AssemblerSeals every submodel plus the validation report and provenance ledger into one signed .aasx, versioned against the twin revision and design revision it was solved from.
CROSS-CUTTING SERVICES
X1Job OrchestratorSchedules solve jobs across compute, handles long-running physics runs, streams progress to the interface. This is what makes the live view honest rather than a loading animation.
X2Provenance LedgerRecords every input revision, engine version and decision that shaped the output. Without it no package is auditable and no field failure is diagnosable.
X3Gap RegisterEvery missing TDS, unmatched operation or out-of-envelope request is logged as a named blocking item. Praxis states what it does not know rather than defaulting past it.
What is actually in the package.
Every submodel is independently extractable; the signature covers the whole package. What is missing from it is stated at the same size as what is in it.
SIGNED PACKAGE — OPEN PACKAGING CONVENTIONS ZIPSKU-4471_rev3_commissioning.aasx
SUBMODEL 01Control logicPLCopen XML (IEC 61131-10) · ST + SFCinjection recipe · vulcanizing program · lasting sequence
SUBMODEL 02Setpoint recipesstructured parameter submodel · per stationdryer temp + dwell · press dwell and pressure · each as a window
SUBMODEL 03Motion & pattern programsstitch-jig pattern files · knit strand pathsneutral description + vendor-native export where required
SUBMODEL 04Validation reportvirtual commissioning pass/fail · cycle time forecastconformal coverage per parameter · V&V credibility argument
SUBMODEL 05Provenancedesign revision · twin revision · engine versionsmaterial lot assumptions · every gap raised during the run
SUPPLEMENTARYReferenced binariestooling geometry · fixture CAD · metrology placementhuman-readable commissioning brief
EXCLUDED BY DESIGN. Safety logic, safety-rated function blocks and vendor hardware and I/O configuration are human-authored and are not generated. PLCopen XML transfers program logic, not vendor hardware configuration or safety logic — those will not round-trip cleanly. This is a hard boundary in Draft 1, not a gap to close later.
The product surface.
The engines above are the backend. This is what a controls engineer actually touches, and why each piece of it earns a place in the first version.
FeatureWhat it doesWhy it belongs in v1
Commissioning runDrop in a design package, select a line twin, get a signed artifact back.The core loop. Everything else is in service of this.
Live solve viewPer-station progress through the pipeline, with the current gate state and any raised gaps visible as they occur.Physics solves are slow. A run that takes an hour with no visibility reads as broken.
Gap registerA named list of what blocked or degraded the run: missing TDS, unmatched operation, out-of-envelope request.Turns a refusal into a task list. It is a feature, not an error screen.
What-if queryChange one variable, see the coupled downstream effects across stations without a full re-solve, using the gradients from E12.The highest-frequency engineering question on any line, and cheap once E12 exists.
Variant recompileNew colourway, new size range, revised material: re-solve only the affected operations and carry the rest forward.The economic argument for high-mix low-volume. The second SKU must cost a fraction of the first.
Package diffCompare two commissioning packages parameter by parameter, with the reason each value changed.Controls engineers will not import a black box. They will import a reviewed diff.
Field feedback intakeReturn observed run outcomes against the emitted window and update world-memory.Without it the system never improves and every SKU starts cold.
DEFERRED — NATURAL-LANGUAGE SETUP ASSISTANCE. IN V1 THE INPUT CONTRACT IS FILES AND THE GAPS ARE STRUCTURED; FREE-TEXT INTENT WOULD ADD AN AMBIGUITY SURFACE WHERE THERE IS CURRENTLY NONE.
Draft 1 is a proposal, not a settled design.
These are the parts that need resolving before the next draft, stated rather than smoothed over.
Motion program neutrality
PLCopen XML solves PLC logic portability. There is no confirmed neutral equivalent for stitch-jig pattern files or knit-machine strand programs — these appeared machine-native in every source reviewed. Draft 1 assumes a per-vendor adapter, and that assumption needs testing against real machine vendors.
Twin availability
The architecture assumes an AutomationML line model exists. Most footwear plants will not have one. Who builds it, how long it takes, and whether Praxis needs a twin-authoring mode is unresolved and materially affects time-to-value.
Material data coverage
E3 blocks on a missing TDS. If adhesive and compound coverage is thin in the target segment the gate fires constantly and the product feels obstructive. This needs a survey before the strictness of that gate is committed to.
Cutting is out of scope
Deliberately. The cutting station already has a mature closed CAD-to-machine path. Praxis treats the nested cut file as an input that passes through, not an output it generates.
Validation depth against runtime
Full virtual commissioning at gate 09 may dominate total runtime. Whether it runs on every solve or only on release candidates is a product decision with real consequences for how the tool feels.
HIGH CONFIDENCE
The output format decision — PLCopen XML inside AASX. Both are published open standards with the exact properties required.
MEDIUM CONFIDENCE
Layer decomposition and engine boundaries. Internally coherent, but not yet tested against an implementation.
LOW CONFIDENCE
Motion program portability and twin availability. Both need external validation before Draft 2.
NEXT PROGRAMME
Tether