Vocabulary

These terms are used consistently across the GUI, runtime, native gRPC API, and installed artifact declarations.

Term	Meaning in Dokime
Suite	A grouping of test templates and their execution contract.
Template	A definition that generates one or more concrete test cases from parameters.
Case	A concrete unit of work inside a cycle.
Cycle	The durable aggregate for a planned or running set of cases.
Execution	A run attempt within a cycle, including lifecycle state and output.
Step	A named phase of case execution with a result.
Criterion	A declared validation rule used to decide a result.
Evidence	Structured or file-shaped material attached to product records.
Artifact	Durable bytes stored outside the journal and addressed by metadata.
Record	A durable product occurrence with a declared contract.
Telemetry sample	A payload published to a declared channel and stored as a tracked series row.
Prompt	A runtime request that pauses for an operator-supplied response.
Traceability	The relationship between tests and requirement-like items or snapshots.
Document	One ordered list of sections, holding cards, plots and tables, all of it visible at once.
Installed artifact	One source-owned set of independently registered Dokime domains.
Sidecar	A supervised external process declared directly in code through Harmos.
Effective settings	The resolved configuration and redacted credential bindings for a registered installed artifact.

“Registered” is not synonymous with “active external integration.” In particular, the Fabric and Zephyr artifacts currently prove contracts and configuration without contacting their named services.

Record Storage And Authority

dokime::records::Record is the product payload recorded directly by Harmos. A transaction prepares its records from the admitted pre-state and commits them as one group. State retains counters and visibility/resource projections, not a second payload history. IDs retain their historical progression; timestamp means the occurrence time, while Harmos metadata records commit time.

Builtins and explicitly host-registered custom declarations use typed records. Supervised plugin records use Harmos SystemFact with native sidecar ownership; the host derives the owner from the admitted execution target. Native service requests cannot claim another plugin’s origin through a caller-supplied source. Explicit Python suite registration establishes host authority for its declared records. Historical unclassified catalogs remain readable, but must be explicitly registered again before they authorize new custom publication.

Record queries use one captured committed frontier and its visibility projection. If storage cannot supply a missing tail range, the request fails; an unavailable range is never reported as an empty history. Native watch streams close on a read failure without acknowledging a complete replay. Commit acceptance does not promise synchronous disk durability; the Harmos stored frontier remains authoritative.

Private journal decoders preserve old transaction IDs, original version-specific folds, and the old dokime.event record wire identity. They do not expose an Event API or regenerate records during replay. The built-in section identifiers execution.events and cycle.events are retained as opaque IDs for the same reason: historical ownership cannot be inferred safely from a section id. Their display label is Records; other authored IDs and source strings are preserved without normalization.