Time-Domain System Equivalent logoTime-Domain System EquivalentLinear dynamics, solved faster.Discuss Integration

SDK

A new capability layerfor the simulator you already ship.

Your simulation product gains validated subsystem dynamics as a runtime capability through one shared library, one stable C ABI, and an integration footprint narrow enough to audit in an afternoon.

Designed for Embedding

Fits inside your architecture. Stays out of your way.

The SDK is built for teams that ship simulation products at scale. The integration footprint is deliberately narrow, the runtime contract stays reviewable, and the host never loses control of its own solver loop.

Link one library. Keep everything else.

C-first headers, stable ABI, one shared library. The host links against a narrow public API and keeps full ownership of build system, runtime layout, and release cadence.

Every side effect is visible.

No background threads, no hidden state, no implicit initialization. Every resource is created, used, and destroyed through a contract the host can audit and reason about.

The host never loses the loop.

Time stepping, solver policy, system assembly, and acceptance logic stay with the host. The SDK evaluates operators when asked, nothing more and nothing less.

Built for Shipping Products

Built to ship, not just to demo.

Simulation infrastructure teams need more than a fast prototype. They need a dependency whose ABI, diagnostics, backend policy, and deployment surface can survive release engineering and downstream support.

Ship updates without breaking hosts.

Forward-compatible struct layout with version tags. Binary compatibility across SDK releases without recompilation, the kind of guarantee that matters when your product ships to thousands of seats.

One API, multiple backends.

CPU reference, optimized BLAS, and GPU acceleration through CUDA, selectable at runtime. Switch backends without touching a single line of host code.

Diagnostics that ship, not scaffolding that disappears.

Error reporting, model state inspection, telemetry export, and performance profiling are first-class capabilities, present in every release build, not stripped out before deployment.

Extend where you need to. Fork nothing.

Plugin system for custom solver backends. Adapter layer for domain-specific input preparation. The SDK grows with your product without diverging from the core.

Deployment and Validation

Operational readiness ships with the product, not as an afterthought.

The SDK defines a deployment surface teams can actually support: trusted plugin loading, package-level validation, and first-response diagnostics that help operators separate integration mistakes from packaging drift and environment problems.

Trust the plugin before the host ever calls it.

Simulation engine plugins load through a documented manifest contract. In production mode the host can require manifest-driven discovery, SHA-256 verification, and Ed25519 signature checks before a plugin is accepted.

Give field teams a first diagnostic move.

`tdse_plugin_doctor` reports ABI compatibility, plugin health, manifest entry match, and integrity status. That gives deployment teams a stable first-response tool before they escalate into deeper runtime or host-loop triage.

Validate the installed package, not just the source tree.

Linux tarball, DEB, and RPM forms are part of the supported delivery surface. Package validation covers relocation, install completeness, and downstream consumption through CMake and `pkg-config`, not just local developer builds.

Keep runtime evidence structured when integration fails.

Create diagnostics, pack inspection, state snapshots, and structured status reporting are meant to survive real host integration failures. When a model does not create or a step loop misbehaves, the SDK exposes enough evidence to separate bad pack content, lifecycle misuse, and deployment drift.