Skip to content

Latest commit

 

History

History
121 lines (75 loc) · 6.53 KB

File metadata and controls

121 lines (75 loc) · 6.53 KB
Stream44 Studio
Open Development Project
Preview release for community feedback.
Get in touch on discord.

⚠️ Disclaimer: Under active development. Code has not been audited, APIs and interfaces are subject to change!

Framespace Genesis Tests

An experimental implementation of an encapsulate based visual modeling engine. Models are constructed and events are generated by following an actual execution path through annotated code components.

Overview

Framespace Genesis is not an abstract modeling tool. It is a modeling engine where the model is real TypeScript code that actually executes.

You author components — encapsulated TypeScript objects with properties and methods — and wire them together through action invocations that form a promise chain. When the model runs, method calls between components produce an event log of every boundary crossing: every payload that leaves one component and enters another.

This event log, combined with a schema that maps components to visual elements, drives an interactive visualization. The visualization is not hand-drawn. It is generated from the execution trace. Change the code, re-run, and the visualization updates.

The engine is built on encapsulate which wraps TypeScript objects and intercepts boundary crossings transparently. You write normal TypeScript. The runtime kernel observes it.

What this enables:

  • Go from concrete execution → abstract model → visual representation in one system
  • Model real-world flows (like credential exchanges, service interactions) as executable component graphs
  • Observe data movement across component and space boundaries to identify exposure, correlation, and risk
  • Transpose models directly onto actual system implementations — the components may map to real classes and services

This project thrives on your collaboration!

Try creating a model for something you are interested in and share it!

Implementation Approach

A model is authored as TypeScript source files in two directories: Model Components and Model Schema.

Each component is an encapsulated TypeScript object with properties, methods, and mappings. Component aspects (properties, methods) are mapped to schema components. Schema components may in turn map to higher-order schema components.

The model executes by following the actual codepath — object method calls create a promise chain. The encapsulate abstraction emits boundary crossing events whenever payloads exit or enter components and when components act internally.

These events are collected into a boundary event log. The schema and event log together drive a schema-based, event-hydrated interactive visualization.

Implementation Approach

Visualizations

Quadrant Visual Model

The visualization is organized into quadrants with column and row trees that define the spatial layout. Nested spaces act as logical domains — the same identified space is the same space across quadrants, not just a visual container.

Inside spaces, components are the core unit. A component has properties (state) and actions (executable methods). Components can have multiple actions and attributes that define their visual and functional identity.

Action invocations connect components. An action payload moves from action to action — internal or external, one-to-one or fan-out to multiple invocations. Payloads crossing component and space boundaries emit boundary crossing events which makes execution observation possible.

The primary rule: construct a promise graph through all action invocations that touches every attribute and ends up in a resolved state when the model has finished executing.

Quadrant Visual Model

Contributing

All contributions must comply with the repository’s Developer Certificate of Origin (DCO) and verified commit signature requirements.

Before opening a Pull Request:

  1. Sign the DCO agreement once:

    bun run sign-dco
  2. Ensure every commit:

    • Contains a Signed-off-by: trailer
    • Is cryptographically signed (SSH or GPG)
    • Has a clean working tree before using repository scripts
  3. Push your branch using the provided helper:

    bun run push

    This will squash unsigned commits into a signed commit where possible.

⚠️ Important:

  • The DCO check validates all commits in the PR range, not only the latest commit
  • Verified signatures are enforced by repository rules
  • Force-push may be restricted by branch protection; if you need to rewrite commits, create a new branch and open a new PR
  • See the full contribution guide: docs/CONTRIBUTING.md

Provenance

Gordian Open Integrity DCO Signatures

Repository DID: did:repo:e7b46f0978c2cc02461b480b99a6589a2b6fa888

Inception Mark Current Mark Trust established using
Stream44/t44-BlockchainCommons.com

(c) 2026 Christoph.diy • Code: LGPL & MIT • Text: CC BY-SA 4.0 • Created with Stream44.Studio