Creative Surface Architecture
The sporeGarden organizational model — how products relate to infrastructure through the 'powered by' consumption pattern.
Three Organizations
The ecosystem is organized into three organizations, each answering a different question:
| Organization | Question | Audience |
|---|---|---|
| ecoPrimals | Does the infrastructure work? | Developers |
| syntheticChemistry | Does the science reproduce? | Scientists |
| sporeGarden | Does someone use it? | Creators, scientists, collaborators |
This separation is not organizational convenience — it reflects the biological distinction between mycelium (infrastructure), fruiting conditions (springs), and the cultivation surface (products).
The “Powered By” Model
sporeGarden products consume primals but do not import them:
- JSON-RPC TCP — all primal communication via standard IPC
- Songbird discovery — products discover primals at runtime via mesh
- Graceful degradation — products work with reduced capability when primals are unavailable
- sweetGrass attribution — products carry provenance for every primal they consumed
- rhizoCrypt tracing — every computation has a hash chain
No shared crates. No source-level coupling. No platform rent. Different organization, binary-only interface, independent release cycles.
The Spore Metaphor
ecoPrimals = mycelium (underground network, substrate decomposition, nutrient transport)
springs = fruiting conditions (temperature, humidity, substrate chemistry)
sporeGarden = cultivation surface (where fruiting bodies emerge for the world to see)
Users interact with the cultivation surface. They see helixVision, initioChem, esotericWebb — products with user interfaces, workflows, and deliverables. They do not see the mycelium.
Four Product Layers
Every sporeGarden product has four layers:
- Primal binaries — sovereign compute primitives (ecoPrimals provides)
- PrimalBridge — IPC adapter connecting product to primals (deploy graph)
- Product engine — domain logic (the product itself)
- Creative content — user-facing configuration, data, or media (YAML/TOML)
The layers compose vertically. A user’s YAML configuration feeds the product engine, which dispatches through the PrimalBridge to primal binaries. The user never touches layers 1-2. The product developer works in layers 2-3. The primal developer works in layer 1.
Trust Model
| Boundary | Trust Mechanism |
|---|---|
| Creator to engine | Deterministic validation — the engine rejects invalid content |
| Product to primals | ecoBin compliance — binaries satisfy structural requirements |
| Collaborator to product | Provenance DAG — every result traces to its computation |
Lean Consumption
gen3 springs consumed primals via crate imports — tight coupling, shared dependency trees, synchronized versions. gen4 products consume primals via TCP capabilities — loose coupling, independent evolution, graceful degradation.
This is the difference between a cell importing a gene (gen3) and a cell secreting a signal molecule (gen4). The signal (JSON-RPC capability) crosses the membrane. The gene (source code) stays inside.
Projected Catalog
| Product | Domain | Status |
|---|---|---|
| esotericWebb | Creative gaming with primal composition | Active |
| helixVision | Self-hosted protein structure prediction | Implemented |
| initioChem | Conformational dynamics and FEL | Implemented |
| blueFish | PFAS analytical chemistry ETL | Specification |
| lithoSpore | Bootable sovereign USB environment | Designed |
| tideGlass | Sovereign field pallet | Architectural |
The creative surface is where the ecosystem meets the world. Users see products, not primals. Scientists see results, not infrastructure. The mycelium does the work. The fruiting body gets the credit. That is the design.