The Two Worlds — Subject Matter Expertise and Analytical Activities

Every jinflow artifact belongs to one of two distinct worlds. Naming the boundary correctly dissolves most of the vocabulary confusion we’ve accumulated.

Status: proposal — 2026-04-14

---

Why this page

jinflow has accumulated near-synonyms — Signal, Finding, Thesis, Verdict, Perspective, Interpretation, Observation, Explanation — and the docs, glossary, UI, and YAML don’t always agree on which lives where. This proposal names the organising dimension (Subject Matter Expertise vs Analytical Activities), defines each term through that lens, and spells out the consequences.

It is the pre-implementation sibling of Sense 15 (Observation + Explanation) and the reconciliation layer under the Signal paradigm.

The organising dimension

The strong distinction is not pack-vs-tenant. A domain pack contains dbt models, macros, extractors, contracts, and tenant skeletons — none of which fit neatly into either world. The strong distinction is:

World	Character	Members
Subject Matter Expertise	What experts know about the domain itself. Stable, codified, reusable across every tenant of the pack.	Dossier · Subject Matter (Statement · Check)
Analytical Activities	What unfolds against real tenant data. A living mix of declarations, machine output, and (soon) signed human claims.	Signal · Perspective · Thesis · Verdict · Finding · Observation · Validation · Explanation · Contributing Factor

The pipeline (Bronze → Silver → Gold, macros, extractors) is shared substrate that serves both worlds but belongs to neither — it’s infrastructure, not taxonomy.

Pack vs tenant is a secondary axis on the Activities side: Signal / Perspective / Thesis / Verdict exist as templates in the pack catalog and as imported, owned, evolving instances in the tenant. Subject Matter, by contrast, is pack-sourced and referenced (not copied) by tenants — which is why it feels more monolithic.

Diagram

The dashed purple boxes — Observation, Validation, Explanation, Contributing Factor — are the Sense 15 layer: defined, not yet shipped.

Where each artifact lives

Artifact	World	Pack	Tenant
Dossier	SME	single source	referenced
Subject Matter (Statement, Check)	SME	single source	referenced
Signal	Activities	catalog template	imported, owned, evolves
Perspective	Activities	catalog template	imported, owned, evolves
Thesis	Activities	catalog template	imported, owned, evolves
Verdict	Activities	catalog template	imported, owned, evolves
Finding	Activities	—	always (machine output)
Perspective score	Activities	—	always (machine output)
Thesis status	Activities	—	always (machine output)
Verdict output	Activities	—	always (machine output)
Observation	Activities	—	always (signed human · Sense 15)
Validation	Activities	—	always (signed human · Sense 15)
Explanation	Activities	—	always (signed human · Sense 15)
Contributing Factor	Activities	—	always (signed human · Sense 15)

IS / IS NOT for each term

Signal — Analytical Activities · tenant-owned, pack holds a template

• IS: A typed declarative detector that lives in the tenant. Has polarity, score, direction, impact. Operates on Gold entities. Compiles to a dbt SQL model. Typically starts as an import from the pack catalog, then evolves locally.
• IS NOT: A pack-owned artifact in its living form. Not a single event (that’s a Finding). Not a business question (that’s a Thesis). Not a health score (that’s a Perspective). Not a result.

Finding — Analytical Activities · tenant, always

• IS: One row produced when a Signal fires on a tenant’s data. Atomic, machine-computed, unsigned. Fields: finding_id, signal_id, tenant_id, severity, entity_id, money_at_risk, evidence. Operational.
• IS NOT: A human claim. Not an Observation. Never exists without a Signal behind it.

Perspective — Analytical Activities · tenant-owned, pack holds a template

• IS: A named lens that aggregates multiple Signals’ findings into an entity-level view. Lives in the tenant, typically imported from the pack catalog. Compiles via contract: "findings.v1".
• IS NOT: A single Signal. Not a business question. Not a root cause.

Thesis — Analytical Activities · tenant-owned, pack holds a template

• IS: A natural-language business question evaluated against signal evidence, producing confirmed / plausible / not_observed / insufficient. Lives in the tenant. Carries trilingual interpretation templates for status rendering.
• IS NOT: A signed human claim. Not a root cause (that’s Verdict). Not a Finding.

Verdict — Analytical Activities · tenant-owned, pack holds a template

• IS: A rule-based, machine-computed root-cause judgment attached to a confirmed Thesis. Compiles to SQL; emits one row per tenant in verdict_findings when conditions hold.
• IS NOT: Human-signed. Not an Observation. Not a Sense 15 Explanation — it’s mechanical, not authored. Under Sense 15 a Verdict becomes a candidate Contributing Factor: the machine proposes, a human adopts.

Observation — Analytical Activities · tenant, always · Sense 15, coming soon

• IS: A human-authored, signed, strategic statement at the top of the taxonomy. Rare (8–20 active at a time). Lives on notes infrastructure (kind: observation). Lifecycle: draft → active → dormant → resolved → superseded. The “What?” of the CEO three-move.
• IS NOT: A Signal (generic detector vs specific claim). Not a Finding (row vs statement). Not auto-generated, anonymous, or collective. Not the old SMEbit Level 0 — that was renamed to Statement precisely to free “Observation” for this meaning. Not operational.

Explanation — Analytical Activities · tenant, always · Sense 15, coming soon

• IS: A causal theory attached to an Observation, composed of Contributing Factors (each independently signed, with role / confidence / anchors). Answers “Why?”. Distinct from Validation (empirical proof — “Is this real?”). Grows over time as factors are added.
• IS NOT: Proof. Not a monolithic prose blob. Not a machine-computed Verdict — though a Verdict may be adopted as a candidate factor. Not required — an Observation can be validated before its Explanation is formed.

Subject Matter (Statement · Check) — SME · pack-sourced, tenant-referenced

• IS: Codified expert knowledge about the domain itself: a Statement observation about how the domain works, or a Check that can be executed as SQL. Authored in the pack, referenced by tenants. Version-controlled, attributed.
• IS NOT: Tenant-specific. Not a claim about one tenant’s particular reality (that’s an Observation). Not a detector (that’s a Signal). Not machine output.

Dossier — SME · pack-sourced, tenant-referenced

• IS: A narrative grouping of Subject Matter — the “story” layer on top of atomic codified knowledge. Metadata-only.
• IS NOT: A list of findings. Not a Thesis. Not a Report.

Interpretation(s) — pack-side, deprecating

• IS: Historically — trilingual template text attached to a Thesis that renders its status as prose. A pack-side rendering helper.
• IS NOT: A first-class taxonomy concept. Not signed. Not tenant-authored. Under Sense 15 its executive-facing role is absorbed into Observation + Explanation. Thesis interpretations may survive as internal status labels but stop being the CEO entry point.

What “signed” means

Sense 15 uses signed in the legal/accountability sense: a specific named human is attributed as author and stands behind the claim. Practically, on notes infrastructure, the author field is a required non-anonymous person, and signing is the act of committing a draft as active (status: active). It is the opposite of:

• machine-computed (Findings, Verdicts)
• collectively owned (YAML in git, authored by whoever merged)
• anonymous or auto-generated

Signing is what turns a draft Observation into an active one — the author explicitly accepts accountability.

Consequences

1. “Tenant extensions” dissolves. Every live Signal / Perspective / Thesis / Verdict is a tenant artifact. Pack templates are just a common starting point.
2. Subject Matter is clean. Authored in the pack, referenced (not copied) by tenants. Any tenant-authored “SMEbit” in the current codebase (smebit_zeta_...) is carrying two meanings in one bag — part is a signed human claim about this tenant’s reality (future: Observation), part might generalize into a pack Subject Matter. Migration debt.
3. Interpretation leaves the taxonomy. Its executive-facing role is absorbed into Observation + Explanation. “Interpretation” is retired as a top-line concept.
4. Verdict’s honesty problem has a landing. Verdict stays mechanical; its causal claim becomes a candidate Contributing Factor that a human adopts.
5. The pipeline doesn’t pick a world. Bronze / Silver / Gold, macros, extractors — they’re substrate for both worlds. Diagrams should render them as infrastructure, not as one of the two worlds.

Open questions

1. Catalog upgrade UX — when the pack catalog updates a Signal template, does the tenant’s forked copy get a “newer version available” notice, or is import fire-and-forget?
2. Pack-only exceptions — are there Signals or Theses that should never be imported but run pack-wide (universal quality checks)?
3. SMEbit tenant-level migration — exact criteria for splitting existing tenant SMEbits into Observations vs pack Subject Matters.