Skip to content
docs

Setup is the analysis

The pack is a head start. The analysis is the work.

When a new tenant joins jinflow, the domain pack hands you a starting kit: a Gold contract, the extractors that read a known source system, twenty-odd signals, several theses, a Subject Matter catalogue, perspectives, lineage. None of that is the analysis. The analysis is what happens when you put that kit next to this tenant’s actual data and adjust everything that doesn’t fit.

This page is about why setup is real work, why that work is the product, and how to budget for it honestly.

What you do during setup

Section titled “What you do during setup”

  1. Receive source data. CSVs, XLSX, hierarchical layouts from the tenant’s ERP / HR / clinical / FileMaker / whatever-they-have. Every byte that crosses the boundary gets pinned by SHA-256 in pipeline.yml and logged to an append-only audit. If a row count drops by 30% next month, the pin tells you.

  2. Verify and adjust the schema. Column names will mismatch the pack’s expectations, dates will arrive in formats you didn’t anticipate, identifiers will have a legacy structure nobody documented. You write the source-system dispatch macros that translate. Bronze stays close to the bytes; Silver makes them queryable.

  3. Shape the Gold contract for THIS tenant. The pack ships a starting Gold. The tenant’s Gold is shaped by what they have and they care about. Some entities you’ll drop; some you’ll add; some columns will only make sense in this tenant’s world. A tenant whose Gold matches the pack exactly hasn’t done the analysis yet.

  4. Calibrate the signals. The pack’s signal thresholds are reasonable defaults — but they aren’t your defaults. The first “everything is high severity” run is the start of calibration, not the answer. You tune until a finding actually means “look at this.”

  5. Gather tenant-specific Subject Matter. Every organisation carries institutional knowledge that no data model can derive: system limitations, workarounds, process exceptions, historical events that explain current patterns. Capturing them as Subject Matter — attributed, versioned, sometimes testable — is the most durable thing you’ll do.

  6. Write the theses that matter HERE. What question is the executive actually losing sleep over? That’s the thesis. The pack ships theses that work for many tenants. The thesis that gets confirmed for this tenant and changes a decision — that one you’ll author together.

  7. Iterate. You make, explore, discuss with the SME, adjust, make again. The first month is expensive. The second is not.

Why this is the point

Section titled “Why this is the point”

A SaaS dashboard product has to assume the customer’s data fits the dashboard. The pricing assumes the dashboard does the work; the customer slots data in. When the customer’s reality doesn’t fit, the customer adapts or walks away.

jinflow does the opposite. The engine is stable. The pack is a starting framework. Everything from the source bytes upward is adjustable on this tenant. That’s not a cost; that’s the value. The Gold contract is per-tenant by design. The Subject Matter catalogue is per-tenant by design. The thesis evidence chain is per-tenant by design.

The work compounds. Once the tenant’s Gold + signals + theses + Subject Matter settle into a shape that fits the analysis, every subsequent question gets answered against the same machinery. The infrastructure that took weeks to set up answers the next question in minutes.

What this means for time and budget

Section titled “What this means for time and budget”

Honest order-of-magnitude ranges (adjust to your domain, team, and source-system complexity):

MilestoneTypical timeframe
First jin make succeeds on real data1–3 days
First production-grade KLS2–3 weeks
First confirmed thesis the customer actually acts on4–6 weeks
Steady-state: weekly rebuild + new question turnaround2–5 days per question

The first month is the expensive month. After that, the incremental cost per analytical question drops sharply. This is the cost curve of any system that uses declarative, deterministic, layered analysis rather than ad-hoc dashboards.

If you find yourself onboarding faster than this, one of two things is true: (a) the tenant happens to be very similar to an existing one — possible but rare, or (b) you haven’t done the analysis yet, just the configuration. Both are worth knowing.

What it does not mean

Section titled “What it does not mean”
  • “Setup is the analysis” does not mean every tenant needs every layer rebuilt from scratch. The pack is a real head start. You inherit dozens of signals, several theses, a working extractor for the standard source system, Gold contract templates. What you do not inherit is the analytical posture for this tenant; that you compose.
  • It does not mean the work is unbounded. The tenant boundary is well-defined: source data in, signals + theses + verdicts + Subject Matter out. The analytical surface fits inside that boundary.
  • It does not mean the customer pays forever for “setup.” After the initial investment, ongoing analytical work — new questions, new theses — is incremental and cheap.

How to read this page

Section titled “How to read this page”

If you’re a prospect: budget the first month for analytical work, not configuration. If you’re hiring a vendor or partner to onboard your tenant, ask what their week-2 deliverable is, not their day-1 deliverable.

If you’re a new analyst onboarding a tenant: the first build tutorial is honest about the 15-minute path. The first weeks with a new tenant walks the real one. Start with whichever matches your time horizon.

If you’re a stakeholder sponsoring a jinflow rollout: this is the framing for the “why are we spending four weeks before we see a result?” conversation. The answer is because the analysis is real work that takes four weeks. The alternative is buying a dashboard that answers the questions someone else thought were interesting.

Section titled “Related”
jazzisnow jinflow is a jazzisnow product
v0.64.7 · built 2026-09-20 19:48 UTC