experiment: facilitator view from reasoning graph

This commit is contained in:
2026-08-05 15:00:42 +01:00
parent a7b7dda91f
commit 1998b84ae1
6 changed files with 794 additions and 12 deletions
+35
View File
@@ -143,3 +143,38 @@ The current adapter (`lib/map/investigation-map-adapter.js`) uses generic placeh
7. **Investigation duration tracking**: The summary panel computes elapsed time from `Date.now() - updatedAt`. If the engine emits proper timestamps, the UI can show accurate elapsed duration and investigate stalls (>5 min between turns).
8. **Layout independence (v0.7 workspace layout phase)**: Reasoning outputs must remain entirely independent of presentation layout. The UI's responsive workspace layout — which progressively reveals simultaneous context on wide screens — is a pure presentation concern. No reasoning contract field should be added, removed, or modified to accommodate layout changes. Future reasoning outputs should carry data semantically; how that data arranges itself visually is the responsibility of the presentation layer alone.
---
## Facilitator View Projection (Experiment 12)
Version C derives its content from existing graph fields without requiring new backend data. The following fields are used as inputs:
| Input | Source |
|-------|--------|
| node type / kind | `node.kind` (observation, unknown, assumption, state, metric, conclusion) |
| node label or description | `node.label`, `node.description` |
| support / status | `node.status`, `resolvedNodeIds` |
| confidence where available | `node.confidence` |
| active unknown identity | `graph.activeUnknownNodeId` |
| resolution state | `node.status === "resolved"` or `resolvedNodeIds.includes(id)` |
| evidence references where available | `node.evidenceIds` (currently empty in mocks) |
| relationship relevance where available | `edge.relevance`, `node.relationships` |
### Current limitations (observations, not requests)
The following are observed constraints of the current graph output. They are documented here because they affect the adapter's filtering and ranking logic. They should NOT be treated as backend change requests during this experiment.
- Graph text may repeat the full original scenario verbatim in node labels or descriptions.
- Labels may be verbose relative to what a user can scan quickly.
- The selected question rationale and the selected question itself may diverge slightly in wording from the underlying unknown node.
- Ranking signals (relevance, priority) may not be sufficient for ideal user-facing ordering; the adapter uses deterministic fallbacks.
- Some assumptions may be too generic to be useful without context.
- Duplicate semantic content may occur across node types (e.g., an observation and an unknown restating the same scenario fragment).
The adapter handles these limitations through:
1. Length-based filtering of overly verbose items;
2. Normalised text deduplication across node kinds;
3. Deprioritisation of items matching known boilerplate patterns;
4. Deterministic ranking with explicit fallback ordering documented in code comments.