Sense 19.1: The Simulation Prerequisites

Sense 19.1 · Steady · Last touched 2026-08-20

• last_verified: 2026-07-27

Synced from docs/design/sense_19_1_simulation_prerequisites.md in the engine repo — that’s the source; this page is a build-time mirror.

A model is not yet a feature. Sense 19 designed the what. Three things must exist before the how lands cleanly — otherwise the Simulation arrives as a button on a page where nothing else has changed, and what was supposed to feel like a thinking partnership feels like a static toggle.

Status: proposed Date: 2026-05-05 Depends on: Sense 19 — The Simulation Author: the owner + Claude (conversation, 2026-05-05)

---

What pulled us in

Sense 19 introduced four well-formed artifacts — Suggestion, Intervention, Scenario, Simulation — and a clean conceptual chain from a Verdict to a modelled Decision. The noun topology gave them a place. The inspire training tenant’s nb_what_if note teaches them as a thought experiment.

The artifacts are designed. The implementation isn’t ready, and shipping it now would land it as a feature on a page where nothing else has changed. The result would be something that looks like a button labelled “What if?”, that opens a wizard nobody knows how to use, that produces a diff with no surrounding intelligence, that asks an operator to make a strategic decision based on a UI they encountered for the first time five seconds ago.

That isn’t the Sense 19 we want. The Sense 19 we want is a thinking partnership: the operator reads a Verdict, the AI proposes a candidate Suggestion, the operator refines it, together they author the Intervention, the AI critiques the Scenario before they simulate it, and after the Simulation runs the AI explains the delta in human terms. That experience cannot exist without three things that don’t exist yet.

This Sense names them.

The three prerequisites

1. The operator experience itself, sketched

Sense 19 describes the artifacts. It does not describe what the operator clicks. The questions accumulate quickly:

• Where do Suggestions appear in JinDesk? On the Verdict detail page? In a dedicated /suggestions list? In a sidebar that follows the user across pages?
• How does an operator author a Suggestion vs. accept a system-proposed one? Is authoring a button, a form, a conversation with evolve?
• What does “build a scenario” look like in the UI? A wizard with steps? A YAML diff editor? A natural-language prompt?
• How does the Diff Loupe behave when comparing scenarios vs. snapshots? Same surface, different mode? New surface entirely?
• Where does the Decision happen? Is “Adopt” a button? Does adoption merge a branch silently or open a confirmation dialog? Who’s authorised to adopt?
• What happens when a Scenario takes 10 minutes to build (which it will, on real-tenant data)? How does the operator know when it’s ready, what they can do in the meantime, where the result lands?

None of these have settled answers. Sense 19 is silent on each. Until they’re answered — even at sketch fidelity — implementation will produce a feature whose UX was decided by whoever happened to write the first PR, not by considered design.

What “sketched” means: half a day of paper or Excalidraw-level mockups, walking through each of the operator surfaces (Verdict detail, Suggestion list, Scenario builder, Diff Loupe in scenario mode, Decision flow). Not pixel-perfect — the goal is to surface every UX decision the design currently dodges, and to produce something the design doc can reference.

Outcome: an updated Sense 19 doc with a UX section, a list of decisions made, and an explicit list of decisions deferred.

2. jin evolve in the web application

Currently jin evolve is a CLI REPL — an AI-assisted exploration tool scoped to one tenant, running in a terminal next to the analyst. It’s useful, but it’s a separate context: the operator reading findings in JinDesk browser tab can’t easily ask the AI about this verdict on this page. They have to copy-paste, context-switch, re-establish what they’re looking at.

Sense 19 makes this gap acute. The chain — Suggestion through Simulation — is conversational by nature. “I think we should diversify suppliers” is a sentence; the AI’s contribution is to sharpen it, anchor it, propose the precise Intervention, critique the resulting Scenario, explain the post-Simulation delta. That conversation cannot live in a terminal next to JinDesk. It has to live in JinDesk, where the artifacts the AI is discussing are visible at the same time.

Open questions:

• Where does evolve live? A panel that slides in from the side? A modal? A dedicated tab in the same browser window? A separate browser window (which connects to the multi-window question below)?
• What context does it carry? The current page only? The current selection? A user-curated context (pinning specific findings, theses, verdicts)? Something else?
• How does it differ from generic AI chat? Generic Claude doesn’t know your tenant data. Evolve does. Generic Claude can’t author YAML in your AFS. Evolve can. These are real differences worth surfacing in the UI.
• Does it write to the AFS directly? Or always propose-then-human-applies? The Suggestion → Intervention pattern from Sense 19 suggests propose-then-apply, but at what granularity? Per Suggestion? Per cell of YAML?
• Tenant isolation. evolve is scoped to one tenant per session today. Does the web version enforce that the same way? What happens when the user has two tenants open in two browser windows?
• Authentication and authorisation. Who’s allowed to use evolve in a hosted JinDesk? Anonymous read-only visitors? Signed-in users with capabilities (Sense 18 / Identity)? Tied to an evolve-specific role?
• Cost. AI tokens add up. Is evolve a per-user feature, a per-tenant feature, a per-organisation budget? Self-hosted vs. hosted matters here.

This is a substantial design problem on its own. None of it should be improvised under the pressure of shipping Sense 19.

Outcome: a Sense doc on evolve-in-the-web (number TBD — likely Sense 19.2 or its own number), with answers to the questions above and a phased implementation plan.

3. Multi-window synchronisation

This isn’t a Sense 19 prerequisite — it’s a general pattern that Sense 19 makes sharply visible. The same need applies to:

• Comparing snapshots (today’s tenant vs. last quarter)
• Comparing tenants (rmc vs. inspire)
• Comparing scenarios (production vs. proposed) — the Sense 19 case
• Cross-referencing while writing notes

The user-side picture: two browser windows side by side, one showing the production KLS, the other showing the scenario KLS. Both display the same dimension (say, Artikelpreis-Streuung). You filter the production window to “supply_org = PHA”; the scenario window filters too. You sort by value_delta descending in production; the scenario window sorts the same way. You click a specific article in production; the scenario window scrolls to the same article. You open a chart of price-over-time in production; the scenario window opens the same chart, and zooming in on one zooms in the other.

That is a distinctive interaction pattern. Most BI tools are single-page-app linear; “synced parallel windows” is a real differentiator and a serious aid to comparison work. It also turns the Diff Loupe from a single side-by-side surface into a pattern: any view in JinDesk becomes diff-able by opening it in a second synced window pointing at a different KLS.

Technical building blocks (already supported in modern browsers):

• BroadcastChannel API for cross-window state messages within the same origin
• URL search params as the canonical state representation (we already use ?note=... for note deep-linking; extending to filter/sort/selection state is a natural step)
• A sync protocol that decides:
  • what state is shared (filters, sort order, viewport, selected row)
  • what stays per-window (which KLS, which tenant, which scenario)
  • how conflicts resolve (last-write-wins; explicit lock; user-controlled “follow / don’t follow”)

Open questions:

• Sync model. All-or-nothing across windows, or user-controlled (a “sync this window with that one” button)? My instinct: user-controlled, with a default that makes sense for the Diff Loupe case (sync filters and selection, don’t sync data source).
• State persistence. When the user closes one window, does the other survive? Does the sync resume if they reopen?
• Cross-origin. Two windows on numetrix.jinflow.io and hrcentral.jinflow.io can’t BroadcastChannel. Is that a problem (probably not — same-host comparison is the common case) or a future requirement?
• Mobile / single-window environments. The pattern degrades to single-window, but does the UI offer an alternative for comparison work in those contexts?

Outcome: a Sense doc on multi-window sync (number TBD), and implementation that lands the Diff Loupe as the first beneficiary — two synced windows showing two snapshots of the same data, filters and selection synced, viewport synced, data source independent.

Why these three together

Each prerequisite is independently valuable. Each one ships something useful even if Sense 19 never lands. The reason to treat them as Sense 19 prerequisites isn’t that they’re exclusively for Sense 19 — it’s that without all three, the Sense 19 implementation won’t deliver the experience the design promises.

• Without (1) operator-experience sketches, the implementation makes UX decisions invisibly, and the result is a feature nobody knows how to use.
• Without (2) evolve in the web, the Sense 19 chain is static — buttons and dialogs instead of a thinking partnership, and the conversational quality that makes the chain trustable is missing.
• Without (3) multi-window sync, the Simulation result is presented in a single Diff Loupe surface that has to compress too much into one view — and the comparison work the operator is doing is fundamentally a multi-screen activity.

Building Sense 19 without these three would be technically possible and operationally regrettable.

Proposed phasing

Smallest-first, each piece self-contained:

Phase	Scope	Effort estimate
A	Operator-experience sketches	half a day to a day, no code
B	Multi-window sync (Diff Loupe as first beneficiary)	3–5 days, generic infrastructure
C	evolve in the web (panel mode, page-context, propose-only)	1–2 weeks, new UI + integration
D	Sense 19 implementation	2–3 weeks once A/B/C land

Total: roughly a month of focused work to land the chain properly. Compare against shipping Sense 19 in isolation (estimate: 1–2 weeks for the minimum-viable button-and-wizard version) and then retrofitting A, B, C afterwards (estimate: significantly more than a month, plus user confusion in the interim).

Phase A blocks nothing — it’s a designer-driven activity that informs B, C, D but doesn’t depend on them. Phase B is independent infrastructure. Phase C is the largest piece and benefits from B (multi-window means evolve can live in a dedicated synced window if the panel mode doesn’t fit). Phase D inherits from all three.

What success looks like

When Sense 19 lands properly, an operator’s experience is:

1. They click into a Verdict in JinDesk.
2. They see a Suggestions section on the Verdict page — AI-proposed by default, human-authored when desired.
3. They click “What if?” on a Suggestion. A second window opens, synced to the production view, but labelled Scenario: draft.
4. The Scenario window shows the proposed Intervention as a YAML diff, editable, with evolve in a panel ready to discuss.
5. The operator refines the Intervention with evolve’s help — “will this break the supplier-concentration thesis?” “would tightening the threshold help here?”. evolve answers using the production data and the proposed scenario data side by side.
6. The operator clicks Build. jin make runs in the background on the scenario branch. The Scenario window shows progress.
7. When the build finishes, the Scenario window shows the Simulation results — finding deltas, exposure deltas, thesis verdict flips, entity health changes. The production window stays open beside it for reference.
8. evolve summarises the delta in plain language. The operator reads it, asks a follow-up, gets context.
9. The operator decides: Adopt (merges the branch), Archive (keeps the scenario for reference), or Iterate (returns to step 5).

That’s the experience the design promises. Each step depends on at least one of the three prerequisites: the sketches answer where buttons are, the synced windows answer how comparison happens, evolve-in-the-web answers how reasoning happens alongside. Without all three, the experience falls apart.

How this manifests in jinflow

The substrate the Simulation (Sense 19) depends on: AFS branching for what-if scenarios, scenario-aware make, isolated KLS per scenario. All three landed before the first scenario could run. The user-facing manifestation lives in Sense 19 — The Simulation; this paper is the infrastructure it stands on.

• Used by: jin scenario create (branches AFS via this infrastructure) · jin scenario build (the scenario-aware make path)

Status: shipped — substrate live. See Sense 19 for the user-facing manifestation that this substrate enables.

---

Open questions

1. Sense numbering. Should evolve-in-the-web be Sense 19.2, or its own Sense (Sense 29)? Same for multi-window sync. The .X suffix has been used for refinements of an existing Sense (14.2 typed signals refines Sense 14); these prerequisites are more independent. Probably their own Sense numbers, with cross-references.

2. What about jin evolve itself getting harder questions? Today’s evolve REPL is functional but limited. The web version probably needs a richer foundation — context management, conversation history persistence, capability scoping. Is the web version a port or a redesign?

3. Multi-window sync and Sense 16 (P2P2P). P2P2P routes queries through Cloudflare tunnels for sensitive-data tenants. Multi-window sync needs a coordination channel. Do these conflict? Probably not — sync is client-side, tunnel is data-side — but worth checking.

4. Operator experience sketches and the existing JinDesk. JinDesk has its own design language already (the four-convictions register, the Lab/Salon/Studio rooms, the config-engine-driven display rules). Sense 19’s UI must feel like part of JinDesk, not a new application bolted on. Sketches should respect that.

5. What if we land just one prerequisite? Phase A by itself produces a clearer design and zero new product. Phase B by itself produces a synced Diff Loupe — useful, but doesn’t advance Sense 19 visibly. Phase C alone produces evolve in the web — useful, but evolve without scenarios doesn’t demonstrate Sense 19 either. The honest answer: no prerequisite alone closes the loop. They have to land together for the experience to deliver.

6. What if Sense 19 is built without these prerequisites? A minimum-viable version is technically possible — a button on the Verdict page that opens a wizard, a YAML editor, a Build button, a Diff Loupe with a Scenario tab. It would work mechanically. It would not feel like jinflow.

Summary

Sense 19 designed the artifacts. Sense 19.1 names what has to exist around them for the design to land as the experience it describes — operator-experience sketches, evolve in the web, multi-window sync. Each is independently valuable. None alone closes the loop. Together they make the Simulation chain feel like a thinking partnership rather than a button on a page.

The recommendation is to land all three as their own Sense docs, implement in dependency order, and treat Sense 19 as the synthesis they enable — not the pressure that forces them to be rushed.

---

The one sentence summary: The Simulation chain is a thinking partnership; three things have to exist around it — sketched operator surfaces, AI conversation in the browser, and synced parallel windows — for the partnership to feel like one.

---

Numerical neighbors: ← Sense 19: The Simulation · Sense 19.2: The Incremental Scenario →