Sense 61 — The Private OPS (bring your own operational store)

Sense 61 · Forming · Last touched 2026-08-20

• last_verified: 2026-07-27

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

Status: sketch / position paper — Mig’s idea (2026-07-25), on the drawing board. Companion to: sense_61_the_reservoir.md (the tenant OPS), sense_61_the_strata.md, bucket_sync.md. Name / Sense-number: Mig’s to set. “Private OPS” is a placeholder for the per-user store.

---

The seed (Mig)

JinDesk can open a KLS or an OPS. When there is no OPS in scope, a KLS is either (a) read-only, or (b) the user can open a private OPS.

That fork is small to state and large in consequence. It says the OPS isn’t only the tenant’s store — it can also be yours, brought to a KLS you don’t own.

The reframe: the OPS is scope-attachable

Today the OPS is per-tenant, born with the tenant. Mig’s fork generalizes it: an OPS attaches to a KLS at a scope, and there are (at least) two scopes:

Scope	Holds	Owned by	Syncs to
Tenant OPS (shared)	roster, the identity tree, tenant-visible notes	the tenant owner	the tenant’s R2 space
Private OPS (personal)	your private notes, selectors, desks, last-position	you	your R2 space (or nowhere — local only)

The scope-aware R2 prefix sister-1 already built (<scope-store>/reservoir/<citizen>/, tenant today / org tomorrow) anticipates this: user is just another scope.

Three modes when JinDesk opens a KLS

1. No OPS → read-only. Pure viewer. Browse the data; no operational capability. (Today’s sealed island — P12 — but now framed as a choice, not only a degradation.)
2. Private OPS → personal workspace. You attach your OPS. read = KLS data ∪ your private overlay; writes (notes / selectors / desks / last-position) land in your OPS only. The shared KLS is never touched — your annotations are yours, invisible to the KLS’s owner.
3. Tenant OPS → full / shared. You own the tenant; the tenant OPS carries shared operational state, and your private OPS can still ride alongside for your personal layer.

The mental model: the KLS is the shared truth; the private OPS is your personal lens over it. (Git analogy: a read-only upstream + your own working copy. Annotations over a shared document.)

The fork is the auth boundary (Mig, 2026-07-25). Because everything binds to a Clerk identity (open question 1), the three modes fall out of who you are: no Clerk identity → mode 1 (read-only); a Clerk identity → mode 2 (your private workspace); the tenant owner → mode 3 (the shared tenant OPS). Anonymous is never a writer — it has no identity to attribute writes to. This gives a clean commercial gradient too: read is anonymous/free; operate (your workspace, your notes, sync) requires an account.

Why it’s of value

• Viewers gain agency without compromising shared truth. A consultant receives a client’s KLS and takes private notes on it; a team shares one dataset and each member keeps private annotations; a packaged demo lets the recipient explore and note, privately.
• “Your workspace, everywhere.” Your private OPS follows you, attaches to any KLS you open, and (if synced) resumes across machines. The OPS stops being tenant plumbing and becomes a user-facing product concept.
• It reframes the sealed island. “No OPS” was a degradation; now it’s a fork — view-only, or bring your own operational layer.

The first private-OPS citizen — open last position

Concrete, self-contained, and the reason the OPS gets read at entry (the access-flip):

• Row: (user, kls/tenant) → last_route + desk + selection + recorded_at.
• Mutable → lww by recorded_at (the policy tag from bucket_sync.md) — rides Phase 2, no new merge design.
• Read on entry → restore your view (your desk, your selection, your scroll). Builds on the Desk citizen (Sense 63 L4), already in the OPS — “open last position” ≈ auto-restore the last-active desk.
• If synced (bucket-sync, user scope): close the laptop mid-investigation, open the cloud JinDesk elsewhere, resume exactly where you were. That is the Reservoir’s cross-machine payoff in one gesture.

Open questions (the drawing board)

1. Binding — RESOLVED (Mig, 2026-07-25): Clerk identity, always. Every private OPS — and all operational data — binds to a Clerk-authenticated identity; there is no machine-local anonymous store. Two reasons: (a) provenance — we never hold operational data whose origin is unknown; every note / selection / workspace has a known author; (b) commercial — Clerk is the account/billing relationship (P2: Clerk is the sole online authority), so operational capability is tied to a real, known identity. Consequence, load-bearing: the read-only-vs-private fork is the anonymous-vs-authenticated boundary — no Clerk identity → read-only; a Clerk identity → a private workspace bound to you. (This also keeps operational MAU tied to real users, not phantom device stores — cf. sister-1’s canary-MAU finding.)
2. Where it lives. Not in the tenant’s ops/ (that’s the tenant OPS). A per-user location — ~/.jinflow/private/<user>/…_ops.sqlite? — and, when synced, the user’s R2 scope.
3. Visibility across two stores. A note is private (private OPS) or tenant (tenant OPS). One visibility model must span both stores coherently — the read overlay merges them by scope.
4. Reference stability across ownership. A private note cites a KLS finding_id; that KLS is someone else’s build and may change under you. The dangling-but-honest rule (Reservoir) applies, but across an ownership boundary now, not just a rebuild.
5. Attach UX. On opening a no-OPS KLS: “View only” vs “Create your workspace” (attach/creates a private OPS). One deliberate gesture.

Build order (proposed)

These are feature build-steps, not an axis — the private OPS is Operational-stratum, orthogonal to the Courses (which structure the Built stratum, KLS→KLS). Where they meet: a private OPS attaches to a specific KLS, and a KLS is identified by (generation, course, variation) — so the private OPS’s scope records which KLS-coordinate it overlays. Steps:

• Local first — the private OPS + read overlay. Attach a machine-local private OPS over a read-only KLS; notes / selectors / desks / last-position land in it; no sync. Proves the read-only-vs-private fork and the “bring your workspace” UX. Independent of bucket-sync — buildable now.
• Then — last-position. The session-resume citizen (restore-on-entry), local first.
• Then — synced. The private OPS rides bucket-sync at user scope, so your workspace follows you across machines. Depends on the runs road (sister-1’s) landing.

Honest assessment (for Mig, who is “not 100% sure”)

The concept is strong and worth committing to: it’s the piece that makes the OPS user-facing and gives viewers agency without touching shared truth — a genuine product story, not just plumbing. The near-term value is real and cheap: Slice 0 (local private OPS) is buildable now, independent of bucket-sync, and it makes “no OPS” a rich fork instead of a dead end. The full value (synced, follows-you-everywhere) rides bucket-sync and the visibility/scope model, so it’s deliberate, doc-first, not a rush. Net: yes — capture it, prototype Slice 0 when we pick the lane back up, let the synced half ride Phase 2.

---

Numerical neighbors: ← Sense 60: The Doctor · Sense 61, Part 2 realized: The Reservoir — the spec →