About Digital Substrate

Building tools for data-intensive applications

Our Mission

We believe that building data-intensive applications shouldn't require choosing between type safety and developer productivity. Viper was created to provide both: a runtime that enforces strong typing while eliminating boilerplate through metadata-driven design.

The Stack

DevKit is built on two orthogonal axes: a build-time toolchain that turns your data model into a typed code facade, and a runtime stack of hand-written libraries on which every application runs.

Build-time
DSM

Your data model — the source of truth

Kibo + templates

Reads DSM, generates a typed C++/Python Bridge that facades the dynamic Viper runtime for IDE autocompletion and compile-time checks.

Generated Bridge per application

Lives inside each app or tool — one bridge per DSM model.

loaded by
Runtime (hand-written)
Demo Applications what you see

Graph Editor (ge-py, ge-qml) — each ships with its own Kibo-generated bridge.

Tools what you use

dbe, cdbe (dsviper-tools, dsviper-tools-qml) — each ships with its own Kibo-generated bridge.

Components what you reuse

Shared GUI library common to every dsviper application (dsviper-components, dsviper-components-qml). Hand-written, not generated.

dsviper what you import

Python runtime over Viper, distributed on PyPI. Hand-written, not generated.

Viper what runs underneath

Dynamic C++ engine — currently internal, not yet distributed standalone.

Kibo's output is not a layer of the runtime stack. It is a per-application typed facade that each tool or demo app loads at runtime to talk to dsviper and Viper through a static, IDE-friendly API instead of the dynamic introspection one. Components, dsviper, and Viper are hand-written; only the Bridge is generated.

The Viper Engine

Viper has been in development since 2020. The engine ships with comprehensive documentation for both users and maintainers, and is the foundation on which every higher tier of the stack rests.

Engine Principles

The Viper C++ engine is built on five core principles:

  1. Metadata Everywhere - Runtime introspection drives all subsystems
  2. Reference Semantics - Containers behave like Python references
  3. Shared Ownership - Safe memory sharing via shared_ptr
  4. Immutable Commits - Data versioning with content-addressed storage
  5. Namespace Awareness - First-class support for modular organization