The Inbox Guide

Ce contenu n’est pas encore disponible dans votre langue.

The Inbox is where jinflow surfaces things the system noticed that may want your attention — a wisdom that just turned confirmed, a data gap an audit caught, a Silver-validity cluster that crossed a threshold, a make-time diagnostic, an open action cell waiting on a human.

One page. Many sources. One substrate.

Where to find it

/{tenant}/inbox — singleton per tenant, reachable from every audience including read-mode viewers. Three tabs:

Active — rings that need a look. Default tab. Group-by-source rendering with collapsible sections.
Snoozed — rings you’ve parked. Sorted soonest-out-of-snooze first so you see what’s returning soon.
History — resolved rings, sorted resolved-most-recently first.

JinDesk header also carries a small bell icon with a count of active concern + alarm rings. Click it to open the Inbox.

Anatomy of a ring

Each card carries:

Severity badge — alarm (red), concern (amber), heads_up (yellow), info (gray). The colour is the system saying how loud it thinks the noticing is.
Polarity glyph — + (positive), − (negative), · (neutral). Most rings are negative; a data_gap “this is empty because…” is neutral (work-pending, not bad news).
Message — what the ring is about, in the tenant’s locale.
source_ref — the slug the source plugin uses to identify this ring. Useful when you’re cross-referencing a YAML.
Anchor link — what the ring is about. Click to jump to the smebit / signal / note / org-unit / silver table the ring is anchored at. This is the breadcrumb; it doesn’t change anything.
Suggested-action button — when present, the primary “Open …” CTA. Routes to the surface that owns the resolution: the Atelier for open_wisdom, the notebook for open_note, …
Resolution buttons — Dismiss / Snooze / Restore. Visible only if your role has act:bell.
Comment thread — collapsible at the bottom of every card. Open-by-default when there’s already a comment.

What you can do

Dismiss

When a ring is real but isn’t worth flagging anymore — you’ve looked, you’ve decided it stands. Click Dismiss. A dismissal:

Removes the ring from Active (it shows in History).
Persists across builds — even on a fresh clone or a cloud-built tenant (the dismissal travels via git as afs/bell/<ring_id>.yaml).
Is reversible — open the History tab and click Restore.

You can add a reason — it shows in History next to the resolution.

Snooze

When a ring is real, you want to revisit it later, but not now. Pick a target date. The ring disappears from Active and shows in Snoozed. When the deadline passes, the ring returns to Active automatically.

Snoozes are operational only — they live in your tenant’s OPS file and don’t travel through git. A snooze you set today is yours, not the team’s. (If you want a team-visible “park it until X”, a comment on the ring is the right tool.)

Default is +7 days. Some sources have their own per-source default (e.g. validity clusters default to +30 days — they don’t usually resolve faster than that).

Acted via

When you actually fixed the thing the ring was about — by authoring a note, raising a data request, editing a wisdom, anything concrete — click Acted via and reference the artifact (note id, commit hash, action cell, …). The ring moves to History tagged with what you did. Like dismissals, this persists across builds.

Comment

Every ring has a lightweight markdown thread. Open the Comment section under any ring, type, Post. The thread:

Is visible to anyone with view:bell (not just resolvers).
Persists across builds — comments are part of the durable side and travel via git.
Is the right place for “the viewer says the SAP export is incomplete, blocked on the November delivery” — context the next person needs.

The act/view split applies to resolutions, not to the conversation about them. A read-mode user can leave a comment for the act-mode user who’ll eventually resolve.

Restore

In Snoozed or History, every ring has a Restore (or Un-snooze) button. Click it; the ring returns to Active as if you never touched it. Works on dismissals, acted_via marks, and snoozes alike.

(System-issued auto_cleared resolutions don’t have a Restore button — if the source plugin re-emits the ring, it will return to Active on its own.)

Filters

Three filter strips above the ring list:

Severity — alarm, concern, heads_up, info. Multi-select.
Polarity — + positive, · neutral, − negative. Multi-select.
Lifecycle — persistent (stays until resolved), ephemeral (auto-clears on next build if the source stops emitting).

All filters land in URL params (?sev=alarm,concern, ?pol=negative, ?life=persistent) so you can bookmark a filtered Inbox view or share a URL with a colleague. Refreshing the page reproduces the exact view.

Reading severity, polarity, lifecycle

The system tags every ring with three orthogonal axes:

Severity — loudness. The system’s claim about how much attention it thinks this deserves.
Polarity — direction. + is good news (rare), − is bad news, · is work-pending.
Lifecycle — persistent means the ring stays until you resolve it; ephemeral means the system will auto-clear it on the next build if the source stops emitting.

A wisdom_violated ring is typically concern / negative / persistent. A make-time error diagnostic is alarm / negative / ephemeral. An open action cell is concern / neutral / persistent.

The CLI — `jin bell`

For headless or scripted workflows:

jin bell list                                       # active rings
jin bell list --tab snoozed                         # or 'history'
jin bell list --source validity                     # filter by source

jin bell dismiss <ring_id> --reason "noted"
jin bell snooze   <ring_id> --until 2026-06-01
jin bell acted-via <ring_id> note:nb_followup_2026_05_13
jin bell clear    <ring_id>                         # un-resolve / un-snooze

jin bell flush                                      # OPS → afs/bell/*.yaml

Same OPS substrate as the Inbox — a CLI dismissal shows up in the JinDesk next refresh, and vice versa.

Sharing dismissals across machines — `jin bell flush`

Dismissals you make in the Inbox or via jin bell dismiss live in your local OPS file. To share them with a colleague (or to make sure they survive a fresh clone of the tenant), you need to flush them into the AFS and push.

jin bell flush                                      # writes afs/bell/*.yaml
jin afs push                                        # syncs into the `bell`
                                                    #   orphan branch + remote

jin bell flush reads bell_resolutions from your OPS and writes one YAML per resolved ring to afs/bell/<ring_id>.yaml. jin afs push then syncs those YAMLs into the bell orphan branch (which sits outside the scenario DAG so every scenario sees the same resolutions) and pushes it to the remote.

On the receiving side, the next jin make picks them up at Phase 1c (pull from bell orphan branch) and bakes them into the KLS — your colleague sees the dismissals in their Inbox without ever needing your OPS file.

Snoozes are intentionally not flushed. “Remind me Tuesday” is calendar UX with a soft contract; it stays in your OPS file and is lost on rebuild.

What rings can be about

Five sources today, each with a different signature:

Source	What it watches	Anchor
wisdom	Subject Matter Level 1 checks that flipped to `confirmed` or `violated` this build.	The smebit. Click → Atelier.
data_gap	Tenant `afs/audits/*.yaml` whose trigger query returned rows (e.g. “org_units table is empty”).	The note attached to the audit.
diagnostic	Make-time errors (always rung) and whitelisted warnings/notes.	The diagnostic code page.
action	Notebook action cells in `proposed` or `in_progress`.	The note containing the cell.
validity	Silver tables where invalid-row clusters cross the configured threshold (default 50).	The Silver table.

Adding a new source is an engine plugin, not a config change — see the Bell architecture page for the source plugin shape.

Durability — what survives, what doesn’t

State	Stored	Survives a fresh clone?	Survives OPS delete?
Ring itself	KLS	Yes — built by `jin make`	Yes
Dismissal	OPS (per store)	No — the OPS is per-store; move it with `jin ops backup` / `restore`	No
Acted-via mark	Same as dismissal	Yes	Yes
Comment thread	Same as dismissal	Yes	Yes
Snooze	OPS only	No — never flushed	No

This is intentional: a “remind me Tuesday” loses meaning across machines and time, but a “this is noted, not worth flagging” is a team decision worth committing.

Per-page banners

Some pages render an inline Bell banner above the entity itself. If you’re on a Subject Matter detail page and a wisdom ring is currently firing for that smebit, you’ll see it as a prominent strip at the top — same severity colour, same suggested-action CTA, same “Inbox →” link.

The banner is silent when there are no rings. There’s no empty-state stub; pages read identically when the entity has nothing flagged.

Common patterns

“I keep seeing the same ring.” Check History — if you previously dismissed it on another machine and that dismissal hasn’t been pulled yet, run git pull on the AFS and re-run jin make. The dismissal will land on this KLS too.

“My snooze disappeared after a OPS rebuild.” Expected. Snoozes are OPS-only by design. If you want a snooze that survives a OPS loss, use Dismiss + a comment explaining you’ll revisit, then Restore when you do.

“A diagnostic ring keeps coming back every build.” Diagnostics are ephemeral — the system will auto-clear them on the next build if the underlying issue is gone. If it keeps re-firing, the underlying issue isn’t gone. Open the diagnostic code page from the anchor to read what it’s actually complaining about.

“I want to silence a noisy source for this tenant.” Edit the tenant’s afs/config.yml:

bell:
  sources:
    validity:
      enabled: false

…and re-run jin make. The validity plugin produces nothing; its rings auto-clear on the next aggregator pass.