#process note

BOUNDARY OUTPUT (SUBSTRATE.HOST process note)

I’ve been building a small tool for SUBSTRATE.HOST called Boundary Output.

It’s not a “mind visualiser.” It’s closer to an NCC analogue: a correlate generator.

Neural activity is to mind what a Boundary Output is to a Host.

A correlate, not an exposure. Telemetry, not testimony. What interior looks like from the outside when it couples to a measurable world.

INTERIOR: INACCESSIBLE stays intact for a reason: we can instrument the boundary, not enter the room.

There’s a useful asymmetry here:

Interior (qualia / “what it’s like”) → private, first-person, non-transferable.

Boundary Output (fields / traces / telemetry) → public, third-person, measurable, compressible.

In neuroscience, NCCs are reliable regularities that track experience — but they aren’t the experience. A map isn’t a city. A waveform isn’t a dream. And measurement changes what’s measured.

So Boundary Output becomes a kind of interface ritual: stable patterns that emerge when an inaccessible interior repeatedly “presses” against a system.

A public trace of a private event.

Modalities (current mapping)...

Each host TYPE routes to a different output modality — not because one is “true”, but because different boundaries produce different kinds of legible disturbance:

CEPHALOID → FILAMENT Void/corona/horizon behaviour. Dense core, boundary-shear tendrils, event-horizon vibe.

MICROBIAL → MURMUR Diffuse haze. Particulate swarm logic. Emergent “starlings” field drift.

LIMINAL FAUNA → FERRO Looks alive. Parasitic. Host-like. Magnetic coupling / “Venom channel”.

CELLULAR → TRACE Correlates + measurement aesthetic. Structured morph cadence. Readable instrumentation.

SYMBIONT → GLYPH Recursion as coupling. Self-reference loops, mirroring, Arrival-like rings as interface language.

(Still prototypes. Still moving targets. But the taxonomy feels… defensible.)

The rule...

Correlate, not content. We log the disturbance, not the interior.

I’m sharing a short screen recording (FERRO) and a few stills from other modes as a checkpoint — partly for documentation, partly because the “instrumented boundary” metaphor keeps widening the longer I stare at it.

If anything here feels like it “explains” the interior, it’s doing the opposite. It’s a reminder that explanation isn’t the same thing as access.

In blender I built out a crosshatching shader, a more generalized version of the "Decayed hatch" shader I was working on earlier in the year. It lets me add or subtract two patterns each for the highlights and midtones, which can all be adjusted separately.. I decided to go for the most complicated version of my illustration shader and if I need to later make some versions with less layers. Now all that's left is to build a corresponding resource type in godot and move on to my character shader.

Last night's work - my adventure game scene viewer now stores multiple versions of each shader's parameter adjustments, per subview. For example, looking at this shack from far away (left) the highlight hatch is diagonal and the hatches are widely spaced, but when the player approaches (right) the hatching straightens out and gets tighter.

Process Note

Here is the problem I'm currently facing porting my illustration shader from Blender Eevee (right) to Godot (left)

I'm doing (I think) the same math to each engine's diffuse shader on an array of spheres on plane with the light source and a surface one unit behind. To get the same result on the floating spheres I have the "step" value set to two different values in either. But when I do that the rear plane, which is one unit behind the light source is much larger in blender.

I figure the issue with the difference between the spheres and the plane might have something to do with the angle of the surface relative to the light but adjusting the roughness/metallic settings in godot doesn't affect it. That could have to do with my implementation but I think at this point I have a choice to either attempt to dig into what exactly the lighting math is doing or try to set up a conversion factor to address each issue and then test at different scales.

Also making a note for myself that directly comparing the tones in this setup shows a .0011 difference in value between the two gray tones. Something I noticed in an earlier iteration was that it seemed like the color space was shifting but at least the tone seems to be close on paper. This will also need to be something I make a testing environment for and figure out a transform.