Current Work
Synnoema has reached a point where I'm spending less time adding new parts to the framework and more time testing whether the method I've developed actually works.
Right now, much of that work centers on a deceptively simple problem:
When do we have enough information to say that an experience is distinct enough to represent, and when do several pieces of information actually belong together?
What I'm working on now
One of the basic units in Synnoema is a Node: a bounded experience that has become differentiated enough to represent explicitly.
In theory, that sounds fairly straightforward. In practice, deciding what should count as a Node can be difficult.
Someone might describe several aspects of an experience at once: their mind went blank, they couldn't speak, their body became tense, and they withdrew from the conversation. Those details could describe one experience, several related experiences, or a mixture of things that shouldn't yet be separated.
If I divide the experience too quickly, I may create distinctions that aren't really supported by what the person described. If I combine too much, I may lose meaningful differences.
I've been working on a step I currently call Candidate Formation to deal with this problem. Before deciding whether something qualifies as a Node, I first try to state clearly what experiential configuration is actually being proposed for evaluation.
That gives me something more precise to test without assuming in advance that it belongs in the map.
Testing rather than adding
I've also been changing how I develop Synnoema.
Earlier versions of the project grew largely by identifying problems and then adding or revising parts of the framework to address them. That was necessary for a while, but it also creates a risk: if I change the framework every time I encounter a difficult example, I never really find out whether the existing method works.
So I'm trying to do less of that now.
I've been creating test cases, fixing the relevant rules in advance, and then applying those rules without changing them in the middle of the test. When something doesn't work, I want to be able to distinguish between a genuine problem in the framework and the ordinary difficulty of encountering an ambiguous case.
Some of these tests are also blinded so that I don't know everything about how the case was constructed while I'm evaluating it. The goal isn't to make the testing artificially scientific. It's simply to make it harder for me to unconsciously adjust the method toward the answer I expect.
A question I'm still working through
One issue that keeps appearing is the difference between an occurrence and a more stable experiential pattern.
Suppose someone describes the same unusual blankness of mind on several occasions.
Are those three separate Nodes?
Are they three observations of one Node?
At what point does recurrence become evidence that something stable should be represented?
I don't think the current framework answers that as clearly as it needs to yet. Rather than resolving the question by definition, I'm using the current test cases to see where the existing rules begin to break down.
What comes next
The immediate work is fairly narrow.
I'm testing Candidate Formation and the existing Node eligibility rules against several cases. Once those judgments are complete, I'll be able to look across the results and see whether the method behaved consistently and where the remaining problems are.
After that, the same general approach can move farther into Synnoema: testing how Nodes become related through Threads and eventually how longer-running patterns can be represented without making stronger claims than the underlying experiences support.
For now, though, I'm intentionally staying close to the bottom of the framework.
If the basic decisions aren't reliable, there isn't much value in building more complicated ones on top of them.
Current snapshot
Main focus: Synnoema
Current phase: Testing and refinement
Working on: Candidate Formation and Node eligibility
Open question: How should Synnoema distinguish repeated occurrences from a stable Node?
Next step: Complete the current test cases before deciding whether the method needs revision
Last updated: October 2026

