Roadmap

Where DK Studio is heading. The sequence below is an order of work, not a schedule, and it carries no dates.

Where the work is heading

A richer test model. The case model grows to carry steps, expectations, driver bindings and preconditions, so a case reads as an executable instruction rather than a row in a table.
Deeper authoring. Cases are composed from reusable building blocks, and a suite is assembled by selecting cases across protocol families, device types and projects.
A continuous run model. Runs execute across the agent pool with live progress, retries on failure, and per-execution evidence attached to each step.
Scheduling and reporting. A run has a trigger and a result you can read, export and share with the people who own the vehicle programme.
Data-driven definition. Matrices over the same case model, so one case covers a parameter sweep instead of being copied by hand.
More AI in the loop. Case drafts from a requirement, screen understanding of a failed run, and failure clustering that points at the likely cause.

These shape the product permanently, and are worth knowing before you build on it.

Boundary	What it means for you
The platform orchestrates, it does not implement protocols	The platform does not implement CCC, ICCE or ICCOA itself. Those procedures live in drivers and scripts your team writes on the bench, and the platform runs them, schedules them and reports on them. COT is DK Studio's own protocol and ships with a driver of its own. See Supported protocols.
The agent runs on a general-purpose machine	The agent lives on a PC or rig with Node and `bash` beside the bench — not inside the ECU, the reader or the phone.
Two deployment modes	You choose where the studio runs: a hosted studio operated by DK Studio, or an in-house installation on your own infrastructure with your own database. The two are the same product — the same REST API, the same agent protocol, the same case model. See Deployment modes.
The agent dials out	The agent initiates every connection. Your benches stay behind corporate NAT with no inbound ports and no VPN client on the rig. See Network requirements.

No published dates. Nothing in this documentation commits to a release date.
The plan follows the benches. The order above reflects what the platform needs in order to be useful on a real test rig. If your workflow needs something in a different order, that is worth saying — the sequence is not carved in stone.
Version lines move independently. Each line has its own content directory and its own frozen titles; a new line does not rewrite the previous one. See Version compatibility for how the version numbers work.