It’s the weekend.
Instead of writing another 2,000-word manifesto on what The Singularity Workshop might become someday, I’m just going to open the toy box.
I’ve been building.
Some of it is foundational. Some of it is highly experimental. Some of it is definitely still alpha software. But enough of it has crossed the line from “whiteboard diagram” to running code that it’s time to put it out in public.
You can download it, read the source, compile it, and—most importantly—break it.
Where to Start: NuGet
The easiest way to see what is actually breathing right now is NuGet.
Search for TheSingularityWorkshop and make sure Include prerelease is enabled.
Search The Singularity Workshop packages on NuGet
Most of what I'm pushing right now is deliberately prerelease.
These aren't polished commercial products with a marketing department hiding the machinery behind a landing page. They are architectural experiments that have finally become real enough for someone else to get their hands dirty with.
That is exactly the point.
The Toy Box
Here is what is currently sitting on the workbench.
FSM_API
NuGet | GitHub
This is the bedrock.
The core premise is that behavior can be represented explicitly as state, allowing state-driven behavior to remain separate from the data objects it operates on.
FSM_API is a framework-agnostic C# finite-state-machine system with explicit state definitions, transitions, contexts, processing groups, lifecycle handling, and runtime behavior.
If you want to start at the absolute beginning of the Workshop, start here.
This is where the behavior machinery begins.
FSM_COS
NuGet | GitHub
This is where the pieces start becoming a system.
FSM_COS is the composition kernel.
A runtime manifest says what is requested. FSM_COS resolves the MicroBundle dependency closure, propagates configuration, loads the required capabilities, arbitrates them toward convergence, and produces a RuntimeAssembly.
Conceptually:
Runtime Manifest
|
v
FSM_COS
|
+-- resolve MicroBundles
+-- resolve dependencies
+-- propagate configuration
+-- load/install
+-- arbitrate
+-- converge
|
v
RuntimeAssembly
|
v
host / manifestation
The important part is what FSM_COS doesn't do.
It doesn't become the application.
It doesn't become the GUI.
It doesn't become the storage system.
It doesn't become the Experience.
It assembles the machine and hands the resulting composition to something else.
The crane doesn't become the machine.
MicroBundleDomain
NuGet | GitHub
This one is particularly important to the architecture.
MicroBundleDomain is a neutral contract for independently authored capabilities.
A MicroBundle is a focused unit of capability that can identify itself, declare dependencies and providers, accept configuration, enter a runtime, and participate in composition without requiring the host to understand its private domain.
The important architectural separation is:
What is this capability?
|
v
MicroBundleDomain
Where do I get it?
|
v
MicroBundleRepository
How do I compose it?
|
v
FSM_COS
That means MicroBundleDomain does not belong underneath FSM_COS as an implementation dependency.
It is the neutral seam.
That matters because someone should be able to author a capability without permanently welding their package to my composition engine.
MicroBundleRepository
GitHub
If MicroBundleDomain answers what, the Repository answers where.
The repository explores durable delivery of versioned MicroBundle artifacts, currently using Azure Blob Storage as the storage substrate.
The distinction is deliberately sharp:
Blob Storage
= substrate
Repository
= artifact delivery boundary
FSM_COS
= composition boundary
Artifacts have deterministic identity based on the MicroBundle ID, explicit version, and SHA-256 content identity.
The repository doesn't become a database.
It doesn't arbitrate.
It doesn't compose Experiences.
It doesn't become a GUI.
It answers a much smaller question:
Given this artifact address, where are the bytes and can I verify them?
I am having entirely too much fun ruthlessly separating these concerns.
GUI
GitHub
There is a platform-neutral GUI core in here, alongside manifestations for Blazor and WPF.
But the real experiment isn't drawing buttons.
It's asking:
Can an object describe itself structurally well enough that a generic GUI can just render it?
That led to a reflection-driven GUI architecture where the domain model doesn't need to know about the editor that happens to display it.
The basic idea is:
Domain model
|
| describes itself
v
Reflection / semantic projection
|
v
GUI.Core
|
+--------+--------+
v v
Blazor WPF
So if you're interested in semantic interface construction, reflection, recursive GUI structures, and separating what something means from how it looks, poke around in this one.
There is considerably more going on here than “make a button.”
FSM_Serialization
NuGet | GitHub
This isn't an experiment in shouting “my serializer is the fastest.”
It's an experiment in strict ownership.
The domain owns what its data means.
The serialization layer owns how that data crosses a byte boundary.
The host decides where those bytes ultimately go.
The package deliberately stays out of databases, filesystems, HTTP, application configuration, object-graph magic, and other concerns that belong somewhere else.
It's small, tight, and opinionated.
I wrote a deeper dive on this one:
I Built a Serializer That Refuses to Own Your Data
FSM_REST
GitHub
This isn't another web framework.
FSM_REST provides a reusable boundary for describing and composing REST capabilities.
The interesting part is that a REST capability can be represented as a capability recipe rather than dragging an entire web application into the runtime.
Conceptually:
REST capability
|
v
FSM_REST
|
+-- capability description
+-- request construction
+-- transport boundary
|
v
remote API
|
v
current data
The MicroBundle can describe what is needed to obtain the capability without pretending that the remote API's current response data belongs inside the bundle.
That distinction becomes increasingly useful when capabilities are composed dynamically.
ProtocolAI & GrammarAI
ProtocolAI: GitHub
GrammarAI: GitHub
These sound like AI wrappers.
They aren't.
They explore the boundary where deterministic application-owned meaning meets probabilistic language models.
ProtocolAI is the WHAT.
It gives application-owned meaning a deterministic semantic address space.
GrammarAI is the HOW.
It gives those identities a structural language for describing how they can be connected.
LLM
|
| probability
v
ProtocolAI
WHAT
|
v
GrammarAI
HOW
|
v
host / adapter
|
v
application
There is deliberately no LLM hidden inside either package.
No provider SDK.
No inference engine.
No chatbot.
No API-key management.
The application owns the meaning.
The model supplies probability.
The deterministic boundary sits in between.
I wrote more about the idea here:
ProtocolAI and GrammarAI: Giving AI a Language Software Can Actually Own
The Hosts
Architecture diagrams are great.
Eventually, though, somebody has to push a button.
AnyApp
GitHub
AnyApp is the desktop proof of the composition architecture.
It is the Windows desktop counterpart to the browser-facing WebPage/WebForge host.
The important part is that AnyApp is trying very hard to remain a host, rather than becoming an application-specific framework.
Startup is now manifest-driven:
AnyApp
|
v
startup / last Experience
|
v
Forge fallback when necessary
|
v
FSM_COS
|
v
RuntimeAssembly
|
v
host manifestation
The host doesn't need to know every Experience it might eventually run.
It hosts the composition.
That's the experiment.
And yes, the current window is tiny.
That's part of the fun.
WebPage
GitHub
This is the public proving ground.
WebPage is the ephemeral web manifestation of the larger Workshop: public-facing surface, demonstration environment, and experimental place where the architecture gets to meet an actual visitor.
The guiding idea is simple:
Make the mundane magical. Then show the machinery that made it possible.
Instead of merely putting diagrams on a webpage explaining that the GUI is dynamic, the page itself should eventually behave dynamically.
A button can breathe.
A GUI can reproduce.
The reproduction can become a swarm.
The swarm can overwhelm the screen.
The system can freeze.
Gravity can take over.
And suddenly the visitor isn't just reading about the architecture anymore.
They're watching the architecture become the experience.
That's what the WebPage repository is for.
You Don't Need to Understand All of This
Seriously.
You don't need to read every README.
You don't need to understand FSM_COS before touching FSM_API.
You don't need to understand MicroBundle arbitration before playing with the GUI.
You certainly don't need to agree with my architecture.
You don't need to know what a “semantic address space” is.
You don't need to know what “arbitration” means.
You don't even need to know why I keep naming things with increasingly suspicious acronyms.
Just pick one piece that looks interesting.
Install it.
Read the source.
Build a tiny experiment.
Benchmark it.
Break it.
Tell me why it's broken.
That is the entire point of publishing early.
Software has to meet reality.
And reality includes other developers.
Some APIs will change.
Some experiments will become load-bearing infrastructure.
Some ideas that seem perfectly reasonable right now will probably turn out to be terrible.
Some will get thrown away.
That's normal.
Actually, that's part of the process.
The important thing is that these aren't only diagrams anymore.
They're code.
They're packages.
They're repositories.
They're things you can actually touch.
The Workshop Is Open
So, that's the current toy box.
Not everything is finished.
Not everything is stable.
Not everything is even guaranteed to survive.
That's why I'm putting it out now.
If something catches your eye, go play with it.
And if you find something interesting, confusing, inefficient, backwards, brilliant, terrible, or just plain weird—
tell me.
That's how experiments turn into software.
And how software turns into infrastructure.
The toy box is open.
It's the weekend. Come play.
Support Our Work:
Patreon Page:
[https://www.patreon.com/c/TheSingularityWorkshop][1]
Support Us (PayPal Donation):
[https://www.paypal.com/donate/?hosted_button_id=3Z7263LCQMV9J][2]
We'd love to hear your thoughts! Please Like this post, Love the code, and Share your feedback in the comments.
