Glossary

Minimal cross-cutting vocabulary. Terms appear here when several sections of the documentation use them and a single canonical definition avoids drift. Component-specific vocabulary stays in its component section.

For distribution names (DevKit, dsviper, Viper C++), see naming.

Distribution & toolchain

DSM

The Digital Substrate Model — the declarative modeling language used to describe data structures: types, structures, attachments, function pools. Pure specification; runtime-independent. See DSM.

Kibo

The code generator. Reads a DSM model plus a Kibo template and emits source code. Template-agnostic — the target language and runtime are determined by the template. See Command-line usage.

Kibo template

A parameterized recipe consumed by Kibo. Defines what code is emitted and for which target. kibo-template-viper is the official template pack that targets dsviper and Viper C++.

dsviper

The Python runtime — strongly typed Python API over the Viper C++ engine. Distributed exclusively on PyPI (pip install dsviper).

Viper

Umbrella term covering both Viper C++ and dsviper. Use it when a concept applies across the C++ and Python surfaces indifferently — RPC, Services, Metadata Everywhere, the runtime as an ecosystem.

Viper C++

The C++ runtime that carries the type system, commit DAG, and database tier. Currently not distributed standalone; See Naming.

DevKit

The Digital Substrate Python toolkit, distributed as a single ZIP. Carries the toolchain (Kibo, kibo-template-viper, dsviper-tools) — not the dsviper runtime itself, which is fetched from PyPI. See Naming.

dsviper-tools

Tooling for the Database / CommitDatabase workflow of the dsviper ecosystem — cdbe, dbe, dsm_util, commit_admin, and the commit_database_server. Available as a Qt Widgets variant (dsviper-tools) and a QML variant (dsviper-tools-qml).

dsviper-components

Shared component library on top of dsviper — dialogs, views, helpers reusable by applications. Available as a Qt Widgets variant (dsviper-components) and a QML variant (dsviper-components-qml).

DSM constructs

concept

An abstract entity declared in DSM. A concept has no implementation of its own — it exists only through its keys and the attachments bound to those keys. See Concepts and Hierarchies.

key

An instance identifier for a concept. Created at runtime, backed by a UUID, typed by the concept it instantiates. Anywhere typed data references a particular instance, it does so through a key.

attachment

A DSM construct binding a typed payload to a key. The primary unit of data organization in a DSM model. See Attachments.

function pool

A DSM construct grouping function prototypes associated with a concept or attachment — the callable side of the data model. See Function Pools. Two flavours : function_pool (stateless) and attachment_function_pool (stateful, over an AttachmentMutating). When promoted across the wire, function pools form a Service.

Runtime metadata

definitions

The runtime model — the metadata that mirrors a DSM definitions at runtime. What dsviper exposes through introspection (Definitions, DefinitionsInspector, …) and what every typed operation consults.

type / value

The dual primitives of the metadata system. A type describes shape; a value is an instance carrying that type. Every value knows its type at runtime — that is what enables strong typing without boilerplate.

blob

Large opaque binary data stored alongside DSM-typed values. Indexed by a BlobId; stored through blob layouts and packs. Used for images, files, serialized assets, or any payload that does not benefit from typed structure. See Binary Data (Blobs).

codec

A serialization strategy — how typed values are encoded to and from bytes. Different codecs trade readability against size and speed.

Perspectives

static API / dynamic API

The practical names of the Dual Reality split. Static API — a typed API generated by Kibo from your DSM model ; gives you IDE autocompletion and compile-time type checking. Dynamic API — direct use of the runtime’s metadata-driven API ; value and type metadata are loaded at runtime and enforced at every call. Same type safety as the static API, expressed dynamically.

Dual Reality

Two coexisting “realities” of the same data and function calls — a Developer Reality (statically typed, IDE-friendly) and a Runtime Reality (dynamically typed via the metadata catalog). Both are strongly typed ; the static surface is generated on top of the dynamic runtime for the comfort of developers and IDEs. It does not add type safety — it adds editor ergonomics on top of safety that already lives in the runtime. Both describe the same objects ; switching is a change of view, not of data. In the dsviper/Viper C++ ecosystem the static surface is generated by kibo-template-viper as an adapter over the dynamic runtime. Visible in Anatomy of a Service and Commit Application Model.

Commit vocabulary

commit

A node in the mutation DAG. Captures a set of mutations against a parent commit. See Commit.

mutation DAG

The directed acyclic graph formed by commits and their parent links. Storage and history of typed commits; supports divergence, merging of heads, and synchronization across clients. The label mutation rather than commit is deliberate: a Viper commit captures the typed mutations applied since its parent, not a Git-style snapshot of the resulting state — so the Git analogy a reader is likely to reach for breaks down on the actual mechanics.

mutation

An opcode-level change applied to a value (set, update, insert, remove, …). Mutations are grouped atomically into a commit.

CommitStore

The in-memory wrapper over a CommitDatabase that holds the current state, dispatches typed mutations as commits, maintains an undo / redo stack, and notifies observers through the CommitStoreNotifying protocol. The runtime surface a Commit Application actually uses. See CommitStore.

Commit Application

An application built on the Commit Application Model — Application Context composing the CommitStore, the domain state, the dispatch surface, and a platform-agnostic notifier. See commit-apps/index for instances.

Services

Service

A Viper C++ server that exposes one or more function pools over a network socket. Services communicates through the AttachmentMutating. See Anatomy of a Service.

Remote-Local protocol

The pattern used by Service for stateful pool calls. Business logic runs on the server; state reads and mutations land in the client’s local AttachmentMutating via RPC callbacks — the roles invert during execution. Safe by isolation: nothing reaches a persistent store unless the client explicitly persists. See Remote-Local Protocol.

AttachmentMutating

The Viper C++ interface through which stateful operations read and mutate typed data. Implemented by CommitMutableState — but the interface itself is backend-agnostic. The Service protocol communicates exclusively through this interface for stateful pools.