DART 7 Architecture

Load this skill when working on the DART 7 simulation World, on
solvers/physics domains/compute backends, or whenever a task needs the
big-picture map of how DART 7 is generalized for multi-physics, multi-solver,
and multi-backend simulation.

The design in one sentence

The World owns topology, time, and a configured set of solvers; each
solver advances the dynamics of the entities in its physics domain, and
couplers mediate interactions between domains — with parallelizable work
expressed as compute-graph nodes that any backend executor runs.
Users configure method families and policies, never solver registries,
component storage, or execution backends.

Why three axes of choice

• Research, apples-to-apples. A new paper's algorithm should be reproducible
  and benchmarkable inside DART against baselines on shared foundations, not in
  a fork. New methods enter through DART-owned solver families.
• End-user choice. Users pick the solver method and (internally) backend that
  fit their accuracy/speed/platform needs.
• Auto-configuration. Defaults are selected from scene content so the easy
  path stays trivial; the backend seam is designed for later platform/scene-scale
  awareness without changing the public API.

Design vs current state (read both)

docs/readthedocs/architecture.md is the single-page map of the design and
the options at each seam, with honest status markers.
docs/design/dart7_architecture_assessment.md is the verified record of
where the implementation still diverges from that design (no internal solver
contract yet, conceptual-only Model/State split, executor seam unused by
dynamics stages, missing apples-to-apples substrate) and owns the standing
rule: new solver families enter only through
docs/plans/solver-family-intake.md, including contract conformance and
machine-recorded solver identity in all benchmark evidence. PLAN-091 retired
the first living hardening packet plan; current follow-up work routes through
docs/plans/dashboard.md, the intake checklist, and the durable owner docs
named in the assessment. Do not write new code that copies a pattern the
assessment still lists as a verified finding.

Key owner documents

The architecture page's Source-of-truth map is the single owner of the full
topic → owner-doc mapping (solver, API, extension, compute, differentiable,
clean-break, north-star). The docs an agent most often needs inline:

Topic	Document
Solver abstraction, domain assignment, coupling, schedule	docs/design/simulation_solver_architecture.md
Verified findings, standing rule, competitor lessons	docs/design/dart7_architecture_assessment.md
Public C++ / dartpy API shape and promotion rules	docs/design/simulation_cpp_api.md, docs/design/simulation_python_api.md
CPU / SIMD / GPU decision framework	docs/design/scalable_compute_decisions.md
DART 7 vs DART 6 topology · live progress / parity gates	docs/design/dart7_clean_break_strategy.md, docs/plans/dashboard.md

Public-facade rules (do not violate)

• Do not expose Solver, Coupler, PhysicsDomain, ECS storage, component
  types, executor/backend types, or solver registries as public API.
• Select behavior by documented method-family names and policy value objects.
• Backend names (CUDA, Taskflow, SIMD ISA) may appear in build flags,
  diagnostics, and benchmarks — never in public types, namespaces, or required
  configuration.
• Keep the easy path (World + addRigidBody/addMultibody + step) free of
  solver vocabulary.
• Fallbacks must never silently substitute algorithms: validate capabilities
  at finalize or record the substitution in diagnostics.

Verification

Use docs/ai/verification.md to select the docs-only or code gate set for the
change. Implementation work that realizes parts of this architecture also
follows the gates in docs/design/simulation_solver_architecture.md, the
solver-family intake checklist, and any active owner plan named in
docs/plans/dashboard.md.