Singleton scope-decomposition — findings

Triggered by: user observation that singletons are likely corpus-coverage artifacts, not genuine structural attractors.

Analytical tool: compute/scripts/analyze_singletons.py. For each of 12 singletons, per-scope (technical / ecosystem / software): top-3 anchor scores + top-3 instance neighbors. Classification by where the singleton is structurally weak.

Result (sig=pair): 12/12 singletons classify as pseudo-singletons — every one has at least one instance Mn at cos_n ≥ 0.85 somewhere in the corpus. None is a genuine structural attractor with novel substrate. The "singleton" status was an anchor-coverage artifact: the missing partner Mns required to form a 3-Mn anchor weren't present in the corpus at time of authoring.

Per-singleton: hypothesized partners + cluster home

Sorted by strength of the structural inference.

Clear-cut: would join existing or near-anchor clusters with 1-2 corpus additions

Singleton	Tech-neighbor (cos_n)	Hypothesized cluster home	Partners to add
mongodb	couchdb (0.987), mysql (0.967), postgres (0.966)	DBMS — would join expanded relational-server-dbms OR form new document-DBMS cluster	cassandra, rethinkdb, dynamodb
sqlite	mysql (0.924), postgres (0.918), datomic (0.897)	Relational-DBMS embedded variant — could join relational-server-dbms anchor with member-type tag	(already has partners in corpus)
redis	mongodb (0.948), couchdb (0.933), zookeeper (0.922)	NoSQL + coordination — NOT pure KV cache; redis has outgrown memcached structurally	valkey, keydb (redis forks)
grpc + http-rest	grpc↔http-rest 0.934/0.963 across scopes	Wire-protocol-RPC pair anchor — currently both are singletons but they're each other's neighbors	(these two ARE the partners; could add thrift, capnproto)
smtp-email	slack (0.971), figma (0.964), discord (0.964) ← but these are SaaS; weaker structural ties to messaging-substrate	Federated-messaging-protocol cluster	xmpp, irc, matrix-protocol-only (vs matrix-current-Mn)
spreadsheets	vscode (0.984), notion (0.983), wikipedia (0.979)	Interactive-content-creation cluster	word-processors, presentations (user-suggested)
smalltalk	obsidian (0.963), spreadsheets (0.954), vscode (0.953)	Interactive computing environment → expanded editor-tools anchor	lisp-machines, hypercard, emacs
memcached	mongodb (0.881), redis (0.880), linux-posix (0.878) — all under 0.9	Pure-KV-cache; redis is no longer a structural twin (per redis's drift)	hazelcast, varnish, pure-cache deployment patterns

Less clear-cut

Singleton	Notes
kafka	Tech-neighbor kubernetes (0.976), entity-system (0.961). Event-stream substrate + orchestration. Could form "stream-processing" cluster with newer additions (flink, pulsar). Already partial fit with content-infrastructure (0.880).
datomic	Tech-neighbor kafka (0.954), kubernetes (0.947). Event-sourced DB with immutable history. Distinct from relational DBMSes. Closer to "immutable-history-system" pattern (could join expanded vcs-system with looser bounds, since both git and datomic are immutable-append-log systems).
urbit	Tech-neighbors entity-system (0.932), holochain (0.929). Already known peer-federation-adjacent (Paper 6 covers urbit extensively). Singleton status reflects unique Nock/Hoon technical commitments; partners (entity-system, holochain) are also distinctive.

Methodological finding: scope tells you what kind of singleton

Ecosystem-scope scores are MUCH higher than technical-scope scores for almost every singleton (kafka: 0.998 eco vs 0.880 tech; smtp-email: 0.995 vs 0.803; http-rest: 0.997 vs 0.716). The implication: singleton-ness lives at the technical layer, not the ecosystem layer. At ecosystem-tier most Mns find easy partners because adoption-tier categories (mass-adoption / moderate / specialized) form gross clusters that span technical structures.

This means:

Technical-scope singleton-ness is informative — it says "this Mn's technical substrate is distinct in the corpus." Resolution requires finding technical partners.
Ecosystem-scope singleton-ness is rare — most Mns find ecosystem neighbors easily. When it occurs (e.g., urbit's unique p2p-OS-substrate combination), it's a real cultural-position outlier.

Validation of the methodological reframe

User's hypothesis ("singletons are corpus-coverage artifacts") is confirmed by the data. Every singleton has structural neighbors — they're "just different" in the sense that their specific combination of primitives isn't shared by enough other Mns in the current corpus to form a 3-Mn anchor.

This has practical consequence for Paper 6:

The "incomplete reduction" framing remains valid: each singleton is still evidence of independent partial-primitive discovery
BUT the analytical claim about each singleton SHIFTS from "this is a structural attractor at primitive composition X" to "this realizes a structural region whose other corpus occupants we haven't yet sampled"
The PAPER's claim should be epistemically humble: "singletons are sparse-sampling artifacts pending corpus expansion; the structural region exists but its other occupants aren't in our corpus"

Implications for corpus strategy

Two corpus-expansion paths the analysis surfaces:

Path A: Resolve database singletons (3-4 additions)

Add: cassandra, rethinkdb, valkey/keydb. Predicts:

cassandra+mongodb+couchdb form "document/wide-column NoSQL" cluster
redis+valkey+keydb form "feature-rich-KV" cluster
sqlite joins expanded relational-server-dbms with member-type tag (embedded vs server)
memcached remains a singleton OR finds partners with explicit cache-only Mns

Path B: Resolve protocol/interactive singletons (4-5 additions)

Add: xmpp, irc, word-processor, presentation-software, emacs/lisp-machine. Predicts:

smtp-email+xmpp+irc form "federated-messaging-protocol" cluster
spreadsheets+word-processor+presentation-software form "office-app" cluster
smalltalk+emacs+lisp-machine+hypercard form "interactive-computing-environment" cluster

Path A is more decision-impactful (resolves more analytical ambiguity); Path B opens a new cluster region the corpus doesn't currently have at all.

Note on corpus bias: the current corpus is heavily back-end / infrastructure / developer-tools. Path B would address user-observed bias toward backend systems by adding office/end-user applications. This would also test whether the anchor framework generalizes to "end-user productivity" structural regions.

Implications for Paper 6

Update the singleton narrative. Instead of presenting each singleton as a discovered attractor, present them as sparse-sampling artifacts with named candidate partners. Strengthens "incomplete reduction" thesis by making it concrete: "even our 12 'singletons' have identifiable structural neighbors at cos_n ≥ 0.85."
Add the singleton-decomposition figure (output/figures/singleton-decomposition-entity-sigpair.png) as supporting evidence.
Acknowledge corpus bias — back-end software is over-represented. The framework's claims should be appropriately scoped.
Future-proof the methodology section by stating: as the corpus grows, additional anchors will emerge; singletons will progressively resolve into clusters. The framework is corpus-incremental, not corpus-final.

Status

Singleton scope-decomposition: complete for entity arrangement (signature=pair)
12/12 singletons reclassified as pseudo-singletons
Per-singleton candidate-partner inventory: catalogued
Two corpus-expansion paths identified (A: database, B: protocol/interactive)
Paper 6 narrative refinement recommendations: written

Next: either pursue Wave 4 corpus expansion along Path A or Path B, or fold these findings into Paper 6 drafting.

Referenced by the model

Cited as a source by 1 model record (browse the model census):

word-processor — manifestation entity/sc3/word-processor