Sense 30: The Wire — The Outward Contract

Sense 30 · Forming · Last touched 2026-08-27

• last_verified: 2026-08-27

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

Whether the consumer on the other end is another jinflow, a regulator’s notebook, an auditor’s spreadsheet, or a benchmarking service — the wire doesn’t care.

Given identity, access control, and a contracted protocol, there is no jinflow ↔ jinflow surface. There is only a jinflow ↔ everything surface, and a sub-rule for what happens when both ends speak the same vocabulary natively.

Status: proposed Date: 2026-05-08 Author: the owner + Claude (Friday-evening conversation about interconnectivity, after the from-evolution generalisation landed)

Addendum 2026-08-27 (Mig × sister-9). Two things settled and folded in: a Catalog read-facet (discovery — “what is here?”, a Pass-gated projection of the baked registries; the surface the first draft missed), and MCP as one transport of the Wire (not a parallel protocol) — tools/list/resources/list map to the Catalog + Read/Write, and jinflow already speaks the tool shape internally via Vera. The Wire’s serving process is named: a JinServer (headless single-tenant JinDesk, its own doc forthcoming).

---

What pulled us in

A jinflow tenant today has exactly one consumer: its own JinDesk. Other consumers exist in principle — auditors who want a citation-stable view of a Verdict, regulators who want to verify a finding’s lineage, benchmarking services that want to compare aggregates across institutions, scientific papers that want to reproduce a result years later, and another jinflow tenant that wants to use a Verdict from elsewhere as a Contributing Factor in its own Strategy — but they have no contract to code against.

The temptation is to name a Sense for “jinflow ↔ jinflow”: federation, peer-to-peer between instances, a private protocol for two systems that share a vocabulary. That framing is wrong. It is wrong in the same way “C++ should have a special calling convention for talking to other C++ programs” was wrong in the 1990s — it confuses an affordance available when both ends agree with the shape of the boundary itself.

The boundary is between a jinflow tenant and anyone who wants to read or write across it. The other end’s identity is an implementation detail of theirs, not of ours.

The Wire

The Wire is the typed, contracted, signed surface a jinflow tenant exposes outward. It has four invariants — a single contract that holds whether the caller is a familiar peer or a stranger:

Contracted. Every endpoint has a versioned schema. The read surface speaks findings.v1, verdicts.v1, observations.v1, subject_matter.v1 — the same contracts that already govern the analytical artifacts internally. The write surface speaks the same shapes in reverse. Breaking changes are ledgered (Sense 18); minor versions are negotiable; major versions are explicit.

Identified. Every read and every write carries an attributable identity — a Pass (the Identity & Passes model). Anonymous reads are a capability the tenant can choose to grant for specific endpoints (e.g. published verdicts of a public report); they are not the default. Writes are never anonymous; a Subject Matter contribution or a Suggestion that arrives without a signature is rejected at the boundary.

Reasoned. Every call carries a stated intent: “I am auditing finding fnd_xxx for regulatory case Y” or “I am citing verdict_dual_appointment_governance_gap as a Contributing Factor in observation obs_zzz at institution B”. The intent is not enforced — it is recorded. The ledger of who asked what and why is itself a primary output of the Wire, queryable like any other data.

Rate-aware. No call is free; no consumer is unlimited. The tenant declares a budget per Pass, per endpoint, per unit time. Back-pressure is part of the contract. This matters in particular for jinflow-to-jinflow exchanges where citation chains can in principle recurse: institution B cites institution A’s Verdict; A’s Verdict re-derives when B’s data updates; the back-pressure cap stops the loop.

The Shape

Three surfaces, all over the same Wire:

Read. The shape every analytical artifact already has, exposed:

• Findings, Verdicts, Observations, Subject Matter as queryable rows.
• Lineage — for any row, the upstream chain that produced it, walking back through Bronze → Silver → Gold → Signal → Thesis → Verdict, citation-stable per Sense 18.
• Schemas — the contracts themselves, served as JSON, so a third party can validate against them before sending or receiving.

Write. The shapes a third party can contribute to a tenant:

• Subject Matter Statements and Checks, signed by an expert with a Pass authorising that lane (typically Author or Steward — Sense 24).
• Suggestions — proposals for change, the entry point of the Sense 19 evolution chain. A Suggestion arriving from the Wire enters the same lane as one drafted in the Atelier (Sense 29); the difference is who signed it.
• Citations — typed pointers from one tenant’s Contributing Factor (Sense 15) to another tenant’s Verdict or Observation. The cited tenant sees an inbound citation log.

Stream. A subscribable feed of Heartbeat events (Sense 21):

• Tick events when a make completes, with the resulting KLS digest.
• Capture / Publish / Pulse / Reconcile events as they fire in the Heartbeat.
• The stream is read-only, identified, and rate-limited like everything else.

Catalog. “What is here?” — the discovery surface, and the one the first draft missed. Read exposes the shape of an artifact (Schemas) but not the enumeration: which signals run in this tenant, which entities exist, which verdict types are live, which endpoints a given Pass may reach. The Catalog is that manifest — a Pass-gated projection of the baked registries (signal_registry, entity_registry, thesis_registry, verdict_registry, smebit_registry), so it costs almost nothing: the data is already in the KLS. It is not a second source of truth (§3.2’s discipline applied here) — it is a view. A consumer lists before it reads; an agent lists before it calls.

• Scoped by the caller’s Pass: you can only enumerate what you may reach. An anonymous Pass on a public report sees that report’s published verdicts and nothing more.
• Intra-tenant only. “What tenants / domains exist” is not a Wire question — the Wire is a property of one tenant. Cross-tenant discovery is a Fleet concern (Sense 62 / the Fleet Registry), operator-scoped and gated by isolation: a stranger cannot enumerate the fleet.

The Bonus — When Both Ends Speak jinflow

When the consumer on the other end of the Wire is also a jinflow, no separate protocol is invoked; the same Wire is used. What’s different is what’s possible over it:

• No semantic translation in transit. Institution A’s Verdict arrives at institution B as a Verdict, not as a generic {type, score, money_at_risk} payload that B’s loader has to mentally retype. B’s Contributing Factor cites it directly with the typed reference machinery already in place.
• Lineage stitches across the boundary. When B’s observation grounds itself in A’s verdict, B’s ledger records the citation; A’s ledger records that a citation was emitted. The ledger is one continuous walk, with the organisational boundary marked as a known seam.
• Signed Statements compose. A Statement curated at institution A — “In our medical faculty federation, the Chefarzt is always recorded at 100% regardless of academic FTE” — can be imported into B’s Expertise as a referenced Statement, with attribution travelling. B doesn’t claim authorship; A’s name follows.

These are richer affordances over the same Wire, not a different Wire. The sub-rule that captures them: when both ends speak jinflow, no semantic loss in transit. It is a property the contract preserves, not a feature only some callers get.

Transports — one contract, many wires (and MCP is one)

The Wire is content (the contract); how it travels is transport, and the two are independent — HTTP, a Cloudflare tunnel (P2P2P, Sense 16), an R2-backed read, a local file are all wires the same contract rides. MCP (the Model Context Protocol) is one more transport, not a parallel “AI protocol”:

• tools/list ← the Catalog + the write verbs. An MCP client discovers a server’s tools by listing them — which is the Catalog surface above plus the Write verbs (contribute a Statement, file a Suggestion). jinflow already speaks this shape internally: Vera hands the model a context-scoped list of {name, description, input_schema} tools (evolve/tools.ts). The MCP binding externalises those — the same tool shape, now Pass-gated for an outside agent rather than trusted in-process.
• resources/list ← the Catalog + Read. MCP resources are browsable, listable data — the Wire’s Read + Catalog facets, served as resources an agent enumerates and fetches.
• Identity is a Pass. An MCP client authenticates as a Pass like any consumer; Reasoned + Rate-aware apply unchanged.

The Wire is served by any face of the server — JinDesk’s own /api surface is the Wire, beside its HTML — so no host is privileged. The tidiest MCP host is a JinServer (JinDesk with the browser taken off: same binary, no/limited HTML, one tenant, many per machine — its own doc), because it serves nothing but the Wire. So “jinflow as an MCP server” is precise: a server-face — typically a JinServer — speaking MCP over the Wire, one host among many, not a new privileged one.

What this is not

• Not federation in the multi-master-database sense. No single shared truth across institutions. Each tenant remains the source of its own data; the Wire only carries artifacts (Findings, Verdicts, Observations, Subject Matter), never raw rows from Bronze or Silver.
• Not a public API in the SaaS sense. The Wire is a property of a tenant, exposed at the tenant’s discretion, governed by the tenant’s Identity & Passes. There is no centrally-hosted gateway.
• Not P2P2P (Sense 16) extended. P2P2P is about one tenant serving multiple browsers via a Cloudflare tunnel. The Wire is the contracted content of what flows; P2P2P is one transport it can run over. Local files, HTTP, R2-backed reads, and tunnel-routed proxy reads are all valid transports — the Wire is what they all carry.

The same axis at the client edge — tab-to-tab

The Wire’s conceptual axis — independent component instances talking to each other across a boundary, with a named channel and a structured message contract — applies not only at the server seam (tenant ↔ tenant) but also at the client edge (tab ↔ tab on the same JinDesk instance).

The first concrete instance is Our House driving other JinDesk windows (now formalised as Sense 34: The Breeze). The presenter opens Our House on one screen and the analytical content on another. Clicking “Open this room” in Our House broadcasts a navigation intent on the Breeze channel (today still named BroadcastChannel('jinflow-cathedral') for back-compat); any other tab on the same JinDesk subscribes and SvelteKit-navigates to the requested route. Our House’s “Drive other windows” toggle controls whether Our House also navigates itself or stays put (presenter mode).

The shape rhymes with the Wire:

Wire (server)	Tab-to-tab (client)
HTTP + signed JSON	BroadcastChannel
Named relationship	Named channel string
signal.v1 etc.	{type, route, tenant, ts}
Identity & Passes	Same-origin only
Both speak jinflow → ✓	Both pages speak the schema → ✓

Same primitives — named channel, structured message, no shared state — at a different altitude. Same discipline keeps the message contract small and explicit: the navigate message is one of a possible family (navigate, highlight, scroll-to, play-tour-step, …) that future cross-tab features can extend without changing the channel architecture.

What this enables beyond the Cathedral demo (the Cathedral was the 3D walk-through originally minted as Sense 17 and folded into Sense 42 “The Landscape” — see the Sense 42 doc for current framing):

• Presenter ↔ audience splits. Any “map” surface (the now- retired Cathedral, a future Concept Map, a lineage browser) can drive a “content” surface in a separate window.
• Multi-monitor analyst workflows. A user with two monitors can pin the dossier on one and drill into signals on the other, with cross-window cursor sync.
• Demo recording. A scripted drive-loop can broadcast a tour; a recording tab captures the visited pages as PDFs or screenshots.

The contract is intentionally permissive: any tab on the JinDesk can publish OR subscribe. There’s no publisher/subscriber asymmetry. Future surfaces that want two-way coordination can add their own message types ({type: 'cursor-position', ...}, {type: 'selection', ...}) on the same channel or open dedicated channels.

How this manifests in jinflow

Not yet manifest in the engine. Status: proposed. See the implementation phases / open questions above for the path from this paper to running code.

---

Open questions (for later)

1. Authentication. Which Pass classes apply? Likely the same identity model as Sense 18 / Identity & Passes, but there’s a question about anonymous reads — should public Observations be readable without a Pass at all, or always Pass-gated even if every Pass is anonymous?
2. Citation back-pressure. When citation chains recurse (B cites A; A re-derives; B re-derives), what’s the cap? Per-cycle? Per-pair? Per-Pass?
3. Schema evolution across the wire. When tenant A bumps its verdict.v1 to v2, what happens to B’s stored citation that pointed at v1? A version pin? An automatic upgrade? A breakage event?
4. Provenance display. When B’s JinDesk shows an observation with a Contributing Factor citing A’s Verdict, how does the lineage panel render the organisational seam? Distinct visual? A click-through to A’s public page?

Cross-links

• Sense 15 — Observation, Validation, Explanation, Contributing Factor — the strategic artifacts that travel as citations over the Wire.
• Sense 16 — P2P2P — one of the transports the Wire can run over.
• Sense 18 — The Ledger — the provenance machinery the Wire extends across organisational boundaries.
• Sense 20 — The Seam — pack ↔ tenant boundary; the Wire is conceptually the same shape, one altitude further out.
• Sense 21 — The Heartbeat — the events the Wire’s stream surface emits.
• Sense 23 — The Engine’s Seam — engine ↔ pack/tenant; another seam at a different altitude.
• Sense 27 — The Funnel — narrow at the source. The Wire’s read surface is itself an application of the Funnel discipline: ship the picture, not the dataset.
• Identity & Passes — the identity model the Wire’s “Identified” invariant inherits from.

---

Numerical neighbors: ← Sense 29 — The Atelier · Sense 31: The Inlet — Where Bytes Come From Is the Channel’s Business →