What I'm Trying to ValidateINTENT · IMPLEMENTATION · TESTS
My project through-line

I want ideas to survive contact with implementation.

My recurring method is to move an idea out of prose and into forms that can be inspected: executable equations, deterministic audiovisual output, numeric social tags, native language/runtime work, operating-system images, music and visual artifacts. I use translation as a test.

1 · Written proposition → executable behavior

Scientific Theories and Inventions is one written source layer. EQR, Groovebox, GOAVA and related code turn parts of my mathematical vocabulary into machine operations. What I'm trying to validate here is whether the relationships are coherent enough to become parameters, transforms and repeatable outputs rather than staying only as notation.

My boundary: an executable model lets me test its behavior and internal consistency. I don't treat the fact that code runs as automatic independent proof that every physical interpretation is established.

2 · Seed → reproducible world

I built Groovebox around deterministic generation because I want a mathematical seed to survive through notes, rhythm, synthesis, visuals, procedural game output and export. When the same seed and settings are used, the result should be reproducible to the precision of the engine.

Inputseed / equation / settingsTransformationcanonical engines + scriptsObservablesound / image / game / export

3 · Tag → social relationship

In Tabletime I use numeric and non-numeric tags as balanced groups, with signed values, comparisons and arithmetic expressions affecting relevance. I'm testing whether a user can express relationships such as attraction, repulsion, timing and magnitude without reducing everything to plain hashtags.

If I write something like food=0.5; fork<=7500; -late; dinner=2;, I want those meanings to survive parsing, indexing, search and host-to-host exchange.

4 · Application → language → operating system

I built sCode and sOS to see how far I can push the same ecosystem downward. Instead of leaving Groovebox and the mathematical tooling entirely on a conventional stack, sCode gives me a language/runtime direction and sOS gives me boot, profile, package, recovery and installer machinery around it.

I keep platform validation explicit. A script existing for a platform is not the same thing as that target having been runtime-tested.

5 · Concept → audible / visible artifact

I use music and art as perceptual manifestations of the same vocabulary. My track Meum carries a name from the mathematical/software work directly into music, and the recursive geometry across the site does the same visually. That isn't a substitute for measurement; it's another way I make the structures tangible.

6 · Central host → independent network

With Tabletime federation I'm testing whether one social system can stay recognizable while independent hosts keep their own databases and exchange public/global content. I want decentralization to extend the system without requiring private credentials or private posts to leave their home node.

What I want visitors to test

Repeat a Groovebox seed

Run the same seed/settings twice and compare the result.

Exercise numeric tags

Create and search posts with signed/arithmetic tags and inspect how the meanings survive.

Build sCode

Run the supported native build path and compare the result against the included validation notes.

Boot sOS safely

Build the ISO, test it under QEMU, then use live media before doing a destructive installation.

Read the book beside the code

Compare my written formulations with the executable projects instead of treating either in isolation.

Follow the public trail

Use my GitHub, music, visual work and releases as separate views of the same project history.

My public source map