Dokime

Website · Getting Started · Tutorials · Examples · Documentation

Run repeatable engineering tests. Keep the evidence.

Dokime turns hardware and software test procedures into operator workflows, live measurements and HTML reports. Define a procedure, run it across operating conditions, and review the evidence behind each result.

Features

• Reusable Procedures: Define suites, typed parameters, ordered steps, acceptance criteria and explicit cleanup.
• Traceability: Capture and edit device and bench identity from steps; retain it with the execution and reports.
• Parameter Sweeps: Expand one template into operating points without copying the procedure.
• Measurements and Reports: Capture live data and retain plots and records in HTML reports, with links to execution artifacts. Stream row changes apply on plugin reload; saved measurements retain their original definitions.
• Operator Workflows: Combine automation with confirmations and manual checkpoints; keep responses with the execution.
• Equipment Plugins [plugin]: Extend Dokime with equipment operations, test suites and settings through its Rust and embedded Python authoring APIs.
• Remote Control [client]: Control an existing backend through the CLI or a programmatic client.
• Native Media Capture [media-native]: Attach screenshots, camera photos and audio where the platform supports them.

Why Dokime?

Engineering tests need a procedure, an operator, high-rate data and evidence someone can trust. Existing tools cover parts of that, so teams glue together sequencers, scripts, data tools and report generators.

Dokime keeps them together: publish your streams, and Dokime handles storage, live plots and the HTML report. Plugins are native processes with a clear structure, so you can use any instrument library.

Gate	Dokime	Manual Testing	Hand-Rolled Scripts	pytest Harness	OpenHTF	OpenTAP / PathWave	NI TestStand
Getting Started
Low Setup Effort	✓	✓	✓	✓	◐	◐	✗
Open Source	✓	–	–	✓	✓	◐	✗
Repeatable Procedures	✓	✗	✓	✓	✓	✓	✓
Pass/Fail Criteria	✓	◐	◐	✓	✓	✓	✓
Running It with People
GUI & Operator Flow	✓	◐	✗	✗	◐	◐	✓
Device & Bench Traceability	✓	◐	✗	✗	◐	◐	✓
HTML Report Generation	✓	✗	✗	◐	◐	◐	✓
Scaling the Test
Parameter Sweeps	✓	✗	◐	✓	◐	✓	✓
Storage Layer Abstraction	✓	✗	✗	✗	◐	◐	◐
Live Measurements	✓	✗	◐	✗	◐	◐	◐
Remote Control	✓	✗	◐	✗	◐	✓	✓
Long-Run Reliability	✓ *	◐	✗	✗	◐	◐	✓
Extending and Pushing Limits
Plugin Template	✓	✗	✗	✗	◐	✓	✓
Sidecar Plugin System	✓	✗	✗	✗	✗	◐	◐
Fast Stream Support	✓ *	✗	◐	✗	✗	◐	◐

✓ Built In · ◐ Partial Or Add-On · ✗ Build It Yourself · – Not Applicable · * Target, Not Yet Proven

	Dokime	OpenHTF	OpenTAP / PathWave	NI TestStand
Authoring Language	Rust and Python (embedded); C++ planned	Python	C#, Python	Several
Licence	Apache-2.0	Apache-2.0	MPL-2.0, Keysight GUI bundle	Commercial
Ready-Made Instrument Drivers	Plugin's choice	Some plugs	Vendor ecosystem	Extensive
End-Of-Line Readiness	Planned	Yes	Yes	Yes
Maturity	Young	Established	Established	Industry standard

Dokime is young. Choose an established test executive if you need mature production-line tooling or ready-made instrument drivers today.

Interfaces

GUI

The desktop brings the test library, active cycles, measurements and evidence together. Start with the built-in Local backend or select a saved remote in Settings. Export a .dokime-remote access file on the host and import or drop it on another desktop to connect. The desktop remembers that choice; operators do not need a source checkout. Windows installation needs no administrator rights; exposing remote access to other PCs may need an administrator to allow the app through Windows Firewall on the exporting computer. Linux x86-64 packages support Ubuntu 22.04+, Debian 12+ and current Fedora; RHEL and Rocky Linux lack WebKitGTK 4.1 and are unsupported. Install with the package manager so it resolves the desktop dependencies:

sudo apt install ./dokime_<version>_amd64.deb      # Ubuntu, Debian
sudo dnf install ./dokime-<version>-1.x86_64.rpm   # Fedora

Direct Ethernet cables support static or automatic IPv4 link-local addresses; see Direct Cable Between Two PCs.

Unavailable views show an inline failure card with retry and copyable technical details. Failed actions and background failures appear in toasts and remain in Notifications until cleared. Click either to inspect the full message, failure causes and available technical details, or copy them for troubleshooting.

Examples

CLI

Use dokime to run a server or control an existing backend. Use cargo dokime sidecar to create, build and inspect plugins, and cargo dokime installer to package prebuilt binaries with an organization pack. cargo dokime bindings proto exports protobuf contracts. The CLI reference contains the complete workflow, including finite query paging.

Examples

dokime server --application-root ~/dokime-lab
dokime status --backend lab --json
dokime operation list --backend lab

Python

Python can start a native backend with async with Backend(port=0) and export a GUI pairing file with backend.export_pairing(path, label="Bench"). The backend loads installed plugins and releases its data root when the context exits. Pass plugins=[Plugin(...)] to contribute Python operations, observers, settings and templates; see Python Authoring. The async Python client controls a running backend with owned cycle contexts, terminal evidence iterators and saved bundles with digest manifests. Lazy history and evidence queries read a fixed snapshot; optional Polars/Pandas helpers create bounded dataframes with captured types. The distribution is dokime-python; imports use dokime. Follow the locked remote tutorial for a complete example.

Examples

Start an authoring project with dokime new bench --lang python; its main.py starts the backend and exports a desktop pairing file, while plugin/ keeps instrument operations and suites together. Install with uv from this candidate's Git revision or a matching native wheel. The provisional distribution is dokime-python; registry publication awaits the naming decision.

Install the native wheel matching your backend and platform, selecting the optional extra for this dataframe example:

uv add ./dokime_python-0.1.2-cp313-abi3-win_amd64.whl --extra polars

from dokime import DokimeClient, ExecutionStatus

async with DokimeClient.from_pairing("lab.dokime-remote") as client:
    async for execution in client.executions(template="example.measurement", status=ExecutionStatus.FAILED):
        async with execution.telemetry("example.stream", fields=["counter"]) as samples:
            frame = await samples.to_polars(max_rows=10_000)
            print(frame, samples.metadata, samples.complete)

The Python client guide covers authentication, backend profiles, query limits and dataframe types. The example requires the corresponding installed template and stream; finite queries never follow or change execution state. The remote guide retains the complete setup and runnable lifecycle examples.

Rust

The Rust SDK defines plugins, test templates, equipment operations and typed evidence. Dokime builds on Harmos (workspace dependency pin) for contracts and managed plugin lifecycles.

Examples

The test-only OBC plugin simulates a charger without physical hardware. Follow its procedure and measurement examples to see the public authoring API in context.

Use the starter's dokime dependency with the plugin-sidecar feature. Authoring macros and contracts come through that facade. For example, the capture template declares validated parameters and cartesian expansion with:

#[dokime::parameters]
pub struct Parameters {
    #[parameter(label = "Rows", default = 100_000, min = 1, max = 200_000)]
    pub rows: u64,

    #[parameter(label = "Member", default = 0, expansion = "cartesian")]
    pub member: u64,
}

The same plugin uses #[dokime::observer] for its system measurements and #[dokime::criterion] for its pulse acceptance check.

Custom installers can declare [installer] identifier = "com.example.testhub" to keep their installation and storage separate from plain Dokime. They include plugins selected by version and feed name, plus external bundles from an organization pack or repeatable cargo dokime installer package --plugin <path> arguments. Release distributions and plugin archives are verified and cached. Bundled plugins install on startup without replacing newer installed versions. An optional [license] table adds the organization's own terms beside Dokime's unchanged Apache-2.0 license. See the installer guide for packaging options.

Quick Start

1. Download An Installer. Choose a matching release, the nightly prerelease or a successful CI candidate; the download walkthrough identifies the Windows and Linux packages.
2. Inspect Host Telemetry. The installer includes plugin-host.dokime, selected explicitly by the Dokime packaging task. Host streams arrive through the supervised plugin boundary.
3. Try The Test Fixture. In a source checkout, build the explicit OBC fixture, install its bundle, then run a charging template and inspect its measurements and report.
4. Write Your Plugin. Run dokime new bench --lang python for the Python starter, or use the Rust plugin starter and authoring commands.

Dokime is pre-1.0. Pin matching application, client and plugin revisions; public APIs and development storage formats may change. See the product guide for the detailed model and limitations.

CLI and authoring-tool releases use target-specific ZIP (Windows) or tar.gz (Unix) archives. See Install Tools With Mise for archive selection and the release download inventory. Distributors use dokime-distribution-<version>-<target>.zip; shipping plugins share native dokime-sidecars archives described by plugins.json format 2. Custom installers select plugins through top-level [[plugin]] entries: set either name for a release plugin or path for a bundle relative to the organization pack. Its plugins/ folder is storage only; files ship only when selected explicitly. See Native Installers for the manifest and equivalent repeatable --plugin arguments.

Configuration

Dokime stores application preferences in its SQLite storage root. Use Settings in the desktop application to change appearance, client timeouts, report plot defaults, telemetry cadence and remote listener preferences. Updates carry a revision; conflicting edits require refreshing before saving again.

The application folder derives from the installed distribution identifier, falling back to the compiled identifier when distribution.json is absent. Plain Dokime defaults to %LOCALAPPDATA%/com.stokker.dokime on Windows or ${XDG_DATA_HOME:-$HOME/.local/share}/com.stokker.dokime on Linux. dokime server --application-root <directory> selects another application folder; storage paths are bootstrap options, not editable preferences. Dokime ignores legacy config.toml and settings.json files and preserves them; settings live in the database. Telemetry uses ZSTD-compressed Arrow IPC files with a SQLite catalog. Stream and record identities derive from their schemas; saved execution evidence retains its definitions across plugin changes. Only unreadable Dokime-owned persistent state requires a fresh storage root. Dokime reports what cannot be decoded and preserves the existing data. Scoped evidence reads isolate other cycles; see the storage read policies for corruption reporting and whole-root failures.

The Backends table and CLI backend commands share backends.json. Import a .dokime-remote file with an Identifier and Label, connect to it, or remove it from the registry without connecting first. Revoke individual clients from the host’s Paired Clients table. Credentials remain in protected credential stores. Plugin settings and secret catalog metadata persist in SQLite; credential values are not stored there. Settings → Plugins keeps ordinary settings editable after startup fails and shows required secret identifiers. A missing-secret failure offers Set Secret, which opens Secret Storage's Add Secret dialog with its identifier prefilled; then retry the plugin. Installing, updating, disabling and removing plugins apply without restarting Dokime. See Shared Plugin Secrets and Plugin Start Failures.

Implementation limits use domain and subsystem constants. See the application settings model and storage defaults. Plugin metadata preparation uses the shared schema budget configuration for packaging, inspection and installation.

Timed live plots combine saved telemetry batches with the bounded, unflushed admission tail, independently of the save interval. Finite queries, All refreshes and frozen reports use saved data. The time-range slider filters storage queries: selecting a wider range retrieves older saved samples, and selecting a narrower range changes only what is displayed. It does not change storage retention.

Client sample following watches saved storage progress and resumes from delivered stream cursors after reconnecting. Execution-scoped follows drain the closed evidence frontier before ending; they do not poll a second live-sample history.

The viewer defaults to 5 min and offers 1 min, 2 min, 5 min, 10 min, 30 min, 1 h and All for every plot in the view. Timed windows refresh automatically; All loads once and refreshes only when Refresh is pressed. Reports always cover all captured samples. All delivers each plot independently from bounded report previews, so one plot's failure leaves the others available. Markers follow the display point budget.

Live summary tiles fold finite saved-evidence queries with bounded memory. Document capture no longer rejects estimated work based on retained source-row count. The page shows its structure first, then each data card loads and refreshes independently. A failed card leaves the others available. Repeated sections use indexed pages; page navigation keeps one saved evidence cut.

Plot groups show numeric labels in ascending order, then text labels alphabetically. Different labels with equal numeric values remain separate and sort alphabetically.

The live log, diagnostics bundle and remote sessions remain available; remote sessions refresh when opened or focused; remote sessions also provide Refresh. Cycle history shows absolute update times. Busy document reads continue retrying, while other document failures retry once.

Contributing

Bug reports, focused fixes, clearer examples and equipment integrations are welcome. Read Contributing for setup and the review workflow. Frozen documents share the live card query path, retain complete authored tables and include every repeated-section page at the sealed evidence cut.

The storage benchmarks mirror Harmos's storage suite using Dokime's default settings and SQLite backend, including writes, reads, queries, filesystem operations and concurrent workloads.

About

Dokime is developed by Stokker Technologies for engineering test workflows that need traceable measurements and evidence. It is available under Apache-2.0.