Design Intent & Targets¶

Engineering targets in Arxyne live in the product's design intent layer. Gates evaluate simulation KPIs against those targets. The requirements hierarchy is preserved as traceability context authored directly in USD — there is no separate requirements.yaml file.

Where Targets Live¶

Each product's targets are authored in products/<product>/layers/design_intent.usda as typed attributes on the product prim:

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
double arxyne:target:cm_pitch = 0
double arxyne:target:cm_pitch_tolerance = 0.1
double arxyne:target:lateral_g = 0.8
double arxyne:target:yaw_rate_dps = 13
double arxyne:target:roll_angle_deg = 3

These targets are what the gate engine compares results against. Targets are seeded at product creation and live in design_intent — "what we want to make."

Traceability Hierarchy¶

The hierarchy from market insight down to engineering targets is preserved as traceability context, authored as nested Scope prims under a Requirements scope in the root composition file:

Level	Name	Example
1	Target Customer / Programme Goal	"Validate CFD solver against published wind-tunnel data"
2	Customer Desires / Capability	"Simulation reproduces published aerodynamic coefficients"
3	Product Strategy / Method	"Steady-state RANS with kOmegaSST achieves acceptable accuracy"
4	Engineering Definition	"Ahmed 25° rear slant — Cd ≈ 0.299, Cl ≈ 0.345 from tunnel data"

These levels provide audit traceability. The gate-driving target values themselves live in the arxyne:target:* namespace in design_intent.usda, not in the traceability scopes.

Example (Ahmed body)¶

def Scope "Requirements"
{
    def Scope "SolverValidation"
    {
        custom string arxyne:req:description = "Validate CFD solver against published wind-tunnel data"
        custom int arxyne:req:level = 1

        def Scope "AerodynamicAccuracy"
        {
            custom string arxyne:req:description = "Simulation reproduces published Ahmed body aerodynamic coefficients"
            custom int arxyne:req:level = 2

            def Scope "RANSValidation"
            {
                custom string arxyne:req:description = "Steady-state RANS with kOmegaSST achieves acceptable accuracy"
                custom int arxyne:req:level = 3

                def Scope "Ahmed25degBaseline"
                {
                    custom string arxyne:req:description = "Ahmed 25° rear slant — Cd ≈ 0.299, Cl ≈ 0.345 from tunnel data"
                    custom int arxyne:req:level = 4
                }
            }
        }
    }
}

Traceability Attribute Reference¶

Attribute	Type	Description
`arxyne:req:description`	string	Human-readable description of this level
`arxyne:req:level`	int	Hierarchy level (1–4)

How Targets Drive Gates¶

The workflow engine derives the solver domains a product needs from its capabilities (aero always; dynamics if the product has dynamics), dispatches the solver, then evaluates each KPI result against the matching design-intent target:

cd / cl / cm_pitch → aero solver (OpenFOAM / XLB / DoMINO), compared to arxyne:target:cd / arxyne:target:cl / arxyne:target:cm_pitch using the within operator (|result − target| ≤ tolerance).
lateral_g → Chrono, compared using gte (higher grip is better).
yaw_rate_dps / roll_angle_deg → Chrono, compared using lte.

Missing tolerances for within gates produce a NO_TOL status — the gate cannot evaluate without an explicit tolerance authored in design intent.

Gate evaluation is deterministic — no LLM participates. See Workflows.

Runtime Status¶

Simulation results (currentCd, currentLateralG, etc.) are written to the prototype layer, keeping "what we want" (design intent) distinct from "what we measured" (prototype).