Experimental framework for formalizing, modeling, and executing transformations. HEX is an experimental environment for developing a formal system in which distinctions, relations, transformations, and their observable traces can be represented, manipulated, tested, and eventually executed.
HEX is currently in an exploratory stage. Conceptual clarity takes precedence over implementation volume.
HEX is an attempt to build a system capable of moving between:
Concepts ➜ Representation ➜ Operation ➜ Traceability ➜ Model ➜ Evidence
The objective is not merely to create another programming language or simulation framework. HEX explores whether a minimal formal vocabulary can describe how configurations become different configurations while remaining:
➜ representable
➜ composable
➜ executable
➜ observable
➜ testable
➜ comparable
HEX is organized into multiple branches, each representing a distinct experimental channel:
HEX 𖣂 Reference nucleus / consolidated work.
RUN ➜ Laboratory of performative execution.
LIVE ➜ Laboratory of real-time interaction.
FLUX ➜ Laboratory of dynamic change.
Workflow:
𖣂 HEX
ᛝ ➜ 000-LIVE
ᛝ ➜ 03-Runtime Binder
ᛝ ➜ arena.ipynb
Branch: HEX
Runtime path: 000-LIVE/03-Runtime Binder/arena.ipynb
This modular branching structure allows experimentation without compromising stability. Each branch embodies a conceptual role, while HEX remains the reference point for consolidated work.
000-LIVE currently contains a Binder-based experimental runtime.
Notebook:
000-LIVE/03-Runtime Binder/arena.ipynb
Runtime: Binder / Jupyter
Purpose: to execute, observe, and document experimental transformations in a reproducible environment.
First functional checkpoint:binder-v0.1
Each branch is associated with a language or tool that reinforces its conceptual role.
HEX ➜ TypeScript + Markdown
RUN ➜ Rust
LIVE ➜ p5.js / Processing | Binder / Jupyter Notebook
FLUX ➜ Go
Note: These associations are conceptual guidelines rather than strict requirements.
Branches may use different languages or tools depending on the experiment.
Commits must be descriptive and traceable.
Merges into HEX require prior validation through testing.
Experimental branches should be periodically synchronized to avoid divergence.
Documentation accompanies code to preserve conceptual clarity.
𒄆 HEX 𒄆
ꫂ᭪
┌───────────────────┐
│ │
ꫂ᭪݁ ꫂ᭪݁
Λ FLUX
foundations concepts / patterns
│
ꫂ᭪
Sequences
│
ꫂ᭪
RUN
execution
│
ꫂ᭪
Src
│
ꫂ᭪
LIVE
perception
│
│
ᡕᠵデᡁ᠊╾━ EXPERIMENTAL LAYER ━╾━ᡕᠵデᡁ᠊
│
ꫂ᭪
Experimental Runtime
│
╰┈➤
Binder
│
╰┈➤
arena.ipynb
The minimum criterion of the system is its capacity for simplification.
A useful formalism should allow a phenomenon to be represented with fewer arbitrary assumptions while preserving the distinctions necessary for its transformation.
Phase I — Conceptualization
Phase II — Formalization
Phase III — Minimal Runtime
Phase IV — Composition
Phase V — Simulation
Phase VI — Validation
Phase VII — Expansion
The immediate priority is not to maximize functionality, but to determine whether the conceptual core can be reduced to a sufficiently small set of coherent operations.
License and contribution guidelines will be established as the project reaches a stable public-development stage.
Experimental. Conceptual architecture and runtime in development.
ᛝ HEX begins. ᡕᠵデᡁ᠊╾━ WELKUM 𒄆
12 commits
Jupyter Notebook
100.0%
Experimental framework for formalizing, modeling, and executing transformations. HEX is an experimental environment for developing a formal system in which distinctions, relations, transformations, and their observable traces can be represented, manipulated, tested, and eventually executed.
HEX is currently in an exploratory stage. Conceptual clarity takes precedence over implementation volume.
HEX is an attempt to build a system capable of moving between:
Concepts ➜ Representation ➜ Operation ➜ Traceability ➜ Model ➜ Evidence
The objective is not merely to create another programming language or simulation framework. HEX explores whether a minimal formal vocabulary can describe how configurations become different configurations while remaining:
➜ representable
➜ composable
➜ executable
➜ observable
➜ testable
➜ comparable
HEX is organized into multiple branches, each representing a distinct experimental channel:
HEX 𖣂 Reference nucleus / consolidated work.
RUN ➜ Laboratory of performative execution.
LIVE ➜ Laboratory of real-time interaction.
FLUX ➜ Laboratory of dynamic change.
Workflow:
𖣂 HEX
ᛝ ➜ 000-LIVE
ᛝ ➜ 03-Runtime Binder
ᛝ ➜ arena.ipynb
Branch: HEX
Runtime path: 000-LIVE/03-Runtime Binder/arena.ipynb
This modular branching structure allows experimentation without compromising stability. Each branch embodies a conceptual role, while HEX remains the reference point for consolidated work.
000-LIVE currently contains a Binder-based experimental runtime.
Notebook:
000-LIVE/03-Runtime Binder/arena.ipynb
Runtime: Binder / Jupyter
Purpose: to execute, observe, and document experimental transformations in a reproducible environment.
First functional checkpoint:binder-v0.1
Each branch is associated with a language or tool that reinforces its conceptual role.
HEX ➜ TypeScript + Markdown
RUN ➜ Rust
LIVE ➜ p5.js / Processing | Binder / Jupyter Notebook
FLUX ➜ Go
Note: These associations are conceptual guidelines rather than strict requirements.
Branches may use different languages or tools depending on the experiment.
Commits must be descriptive and traceable.
Merges into HEX require prior validation through testing.
Experimental branches should be periodically synchronized to avoid divergence.
Documentation accompanies code to preserve conceptual clarity.
𒄆 HEX 𒄆
ꫂ᭪
┌───────────────────┐
│ │
ꫂ᭪݁ ꫂ᭪݁
Λ FLUX
foundations concepts / patterns
│
ꫂ᭪
Sequences
│
ꫂ᭪
RUN
execution
│
ꫂ᭪
Src
│
ꫂ᭪
LIVE
perception
│
│
ᡕᠵデᡁ᠊╾━ EXPERIMENTAL LAYER ━╾━ᡕᠵデᡁ᠊
│
ꫂ᭪
Experimental Runtime
│
╰┈➤
Binder
│
╰┈➤
arena.ipynb
The minimum criterion of the system is its capacity for simplification.
A useful formalism should allow a phenomenon to be represented with fewer arbitrary assumptions while preserving the distinctions necessary for its transformation.
Phase I — Conceptualization
Phase II — Formalization
Phase III — Minimal Runtime
Phase IV — Composition
Phase V — Simulation
Phase VI — Validation
Phase VII — Expansion
The immediate priority is not to maximize functionality, but to determine whether the conceptual core can be reduced to a sufficiently small set of coherent operations.
License and contribution guidelines will be established as the project reaches a stable public-development stage.
Experimental. Conceptual architecture and runtime in development.
ᛝ HEX begins. ᡕᠵデᡁ᠊╾━ WELKUM 𒄆
12 commits
Jupyter Notebook
100.0%