Memory panel: "SWM" shows three different numbers (30 vs 93 vs 312) — layer chips need one counting contract

[Zigoljube]

Summary

The label "SWM n" currently means three different quantities in three places, and no view shows the number a reader most plausibly expects (total entities in shared memory). A community member comparing the dashboard against a contributor lens sees SWM 30 in one and SWM 93 in the other for the same channel, with nothing explaining that the units differ.

Measured on the live Web of Trust channel (buzz-7e741ed2…, community gateway, 2026-08-14):

Where	Shows	Actual unit	Value
Panel dashboard layer cards (MemoryOverview)	SWM 30	layers.SWM[] array length = SWM layer graphs (one per capture)	30
Contributor lens header legend (ContributorGraphOverlay → lensLayerCounts)	SWM 93	deduped lens nodes (trail events + linked targets) carrying layer:"SWM"	93
Ground truth via semantic_query	—	COUNT(DISTINCT ?d) { ?d rdf:type b:DecisionCluster } → 30; COUNT(DISTINCT ?s) { ?s rdf:type ?t } → 312 typed entities; b:Claim → 2	30 / 312

So: 30 is correct in its own unit (captured decisions ≙ SWM layer graphs — it matches the DecisionCluster ground truth exactly), and 93 is also internally correct (this contributor's lens contains 93 SWM-tagged nodes) — but putting both behind the identical WM/SWM/VM chip design invites exactly the "which one is wrong?" question this report started from. The number a reader plausibly expects from an "SWM recap" — the entity total across all contributors, 312 — is shown nowhere.

Three concrete defects

1. One chip design, two units. LayerCountsLegend is rendered both on the dashboard (unit: layer graphs) and in the lens overlay headers (unit: lens nodes; introduced with the lens work in #9 — my change, so this part is on me). Identical visual, different semantics, no qualifier.

2. The dashboard count silently degrades to a display bound. ChannelMemory.layers is documented as "Layer graph lists are display-bounded; the *Count fields are uncapped" — but the community gateway does not send WMCount/SWMCount/VMCount, so the UI falls back to layers.SWM.length. Today that happens to equal the true total (30). The moment the channel exceeds the gateway's list bound, the dashboard will render the bound as if it were the total, with no indicator.

3. contributor_trail.decision links entity URNs, not decisions. The live trail for contributor c9f4f94b yields 43 distinct decision URIs — against 30 DecisionClusters existing in the entire channel. Inspection shows values like urn:buzz-dkg:entity:…:alice — arbitrary linked entities, not b:DecisionCluster instances. The contributor lens therefore renders inflated "decision" cards (43 > 30 for a single participant), and its ⊕/⊖ structure attaches evidence to things that are not decisions. Either the gateway should restrict the decision field to DecisionClusters (adding e.g. target/targetKind for other entities), or the client must not present every linked target as a decision.

Also worth deciding while here: the trail returns exactly 100 rows (suspiciously round). If that is a cap, prolific contributors' lenses undercount silently — the response should carry total/truncated so the UI can say "showing latest 100".

Proposed counting contract

1. Channel-truth chips only from uncapped counts. Gateway sends WMCount/SWMCount/VMCount; the dashboard never renders an array length as a total (show ≥n or — when the count is absent).
2. Lens legends are scoped and say so. Overlay legend label becomes "in this view" (or drops the layer-chip styling entirely) so it cannot be read as a channel total.
3. Give the expected number a home. The dashboard already shows "N decisions · M topics · K people & agents"; add the entity total (312 today) — that is the actual "size of shared memory" and is one bounded aggregate query away.
4. Type the trail's link targets (decisionUri only for DecisionClusters; target + targetKind otherwise) and mark truncation.

Repro

• Dashboard: open ◈ Memory in the Web of Trust channel → layer card SWM = 30.
• Lens: People & agents → c9f4f94b… → overlay header legend SWM = 93 (= 43 "decisions" + 50 evidence nodes after dedup of 100 trail rows).
• Ground truth (authenticated semantic_query, LIMIT 25, no GRAPH clause — the gateway rejects unbound patterns and explicit graph identifiers):
  • SELECT (COUNT(DISTINCT ?d) AS ?n) WHERE { ?d rdf:type b:DecisionCluster } → SWM 30, VM 0
  • SELECT (COUNT(DISTINCT ?s) AS ?n) WHERE { ?s rdf:type ?t } → SWM 312, VM 0

🤖 Generated with Claude Code

[Zigoljube]

How to align Buzz's layer counts with the DKG node UI, exactly

Traced the node UI's counting semantics in the dkg repo (packages/node-ui). There is a precise, reusable contract to mirror — and the user-visible principle it encodes is: a layer count is a count of entities of every kind, not decisions.

What the node UI actually counts (useMemoryEntities.ts + buildEntities)

Graph membership per layer (the SPARQL filters at useMemoryEntities.ts:239–295):

• WM: graphs containing /assertion/ or /_working_memory/
• SWM: STRENDS(?g, "/_shared_memory") || CONTAINS(?g, "/_shared_memory/"), excluding <cg>/meta/_shared_memory, the _shared_memory_meta bookkeeping graphs, and /_shared_memory/staging/
• VM: everything not matched by WM/SWM patterns (minus _meta)

Entity eligibility (buildEntities): a distinct canonical URI or blank node that appears as a subject, or as a URI object of a non-rdf:type triple. Class targets of rdf:type are deliberately not materialized unless they carry triples of their own. Triples are SPO-deduped per layer, so a triple present in both <cg>/_shared_memory and <cg>/<sg>/_shared_memory counts once.

That is the number the SWM tab header renders ("Entities in Shared Working Memory (N entities · M triples)"). A second surface, listSwmEntities (api.ts:1563), groups by canonicalSwmRootUri and excludes the workspaceOwner predicate — that one feeds the publish panel's root-entity list, not the layer total; the layer chips should mirror buildEntities, not this.

For calibration on the live WoT channel: 30 DecisionClusters, 312 typed subjects — the buildEntities number will be ≥ 312 once untyped subjects and referenced URI objects are included. None of the currently displayed numbers (30, 93) is that count.

Why the client cannot do this itself

The relay's semantic_query allowlist rejects fully-unbound patterns and explicit GRAPH identifiers (verified: unsafe_query — fully unbound triple pattern is not allowed). The node UI runs these queries against its own daemon's raw /api/query; Buzz clients have no equivalent. So the counting must happen gateway-side, where raw SPARQL access already exists.

Concrete change set

1. Gateway (buzz-dkg-integration memory service): compute per-layer entity counts with the buildEntities semantics — subjects ∪ non-type URI objects over the layer's graph set, using the same include/exclude filters as useMemoryEntities.ts. One aggregate query per layer at channel_memory time (cacheable; it changes only on capture).
2. Wire contract: channel_memory.layers gains WMCount / SWMCount / VMCount. The desktop type already reserves exactly these optional fields (api.ts: Partial<Record<"WMCount"|"SWMCount"|"VMCount", number>>) — zero client type changes.
3. Desktop: never render layers.SWM.length as a total again — with SWMCount absent show ≥ n (or —), with it present show the count. Lens overlay legends get an explicit "in this view" qualifier (or lose the layer-chip styling) so a per-lens node tally can no longer impersonate a channel total.
4. Parity test: buzz-dkg-integration already operates a node in CI; add a fixture asserting gateway.SWMCount == buildEntities(sameTriples).size for a CG containing the tricky cases — sub-graph-scoped shared graphs, meta/_shared_memory, staging residue, an rdf:type-only class target, and one entity present in two SWM graphs (must count once).

With that in place, Buzz's chips and the node UI's "N entities" header become the same number by construction — and the panel's "30" today would correctly read as decisions, while the SWM chip reads entities (≈312+), each labeled as what it is.

🤖 Generated with Claude Code