Skip to content

Tutorial: The first weeks with a new tenant

The 15-minute onboarding tutorial walks you through jin init, your first extract, and your first build. This one is its sibling — what happens in the four weeks after init lands. It’s the honest version, written for when the customer asks “when do we see results?” and you need a defensible answer.

Read Setup is the analysis first if you haven’t. It’s the why behind this how.

Time scales here are illustrative — they depend on pack maturity, source-system quirks, customer data hygiene, and your familiarity with the analytical domain. Take them as orders of magnitude.

Goal: the first jin make succeeds end-to-end on real source data.

What you do:

  • Receive a representative source data drop from the customer — real, not synthetic
  • Write or adapt pipeline.yml — SHA-256-pin every file, declare expected sheets and columns, log to extract_log.jsonl
  • Adapt the source-system dispatch macros where the customer’s column names diverge from the pack default
  • Run jin make --extract-only until extraction is clean
  • Run jin make end-to-end; expect failures in the Bronze → Silver → Gold layer when assumptions don’t match
  • Validate the Gold counts are within an order of magnitude of what the customer expects (case count, billing event count, person count — whatever the pack’s headline entity is)

What you don’t do this week: tune signals, write new theses, capture Subject Matter. Those come later. This week is about getting bytes into Gold.

End-of-week test: jin make produces a KLS, jin explore opens it, the Gold counts look approximately right to the customer.

Goal: the Gold contract reflects what this tenant actually cares about.

What you do:

  • Walk the Gold tables with a domain expert from the customer. Confirm what each row means, what each column means, what’s missing.
  • Add tenant-specific Gold columns where the pack default doesn’t capture something material to this tenant. (Tenant overrides Gold via the AFS; the pack isn’t touched.)
  • Adjust the Silver-layer validation rules — what counts as is_valid = true in this customer’s context?
  • Capture the first batch of Subject Matter — every “oh, that’s weird” the domain expert says is a Subject Matter entry waiting to happen. Start with Level 0 (Statement); add Level 1 Checks later
  • Build, explore, present the Gold tables to the customer for sign-off

End-of-week test: the customer signs off on Gold as “yes, this is what we have.” That’s the analytical foundation.

Goal: signal findings actually mean “look at this.”

What you do:

  • Run the pack’s signals against the real Gold. Note which produce 0 findings (the data doesn’t match the pattern), which produce 200K findings (the threshold is wrong for this tenant), and which are meaningful
  • Adjust thresholds, weights, and severity bands per signal
  • Disable signals that don’t apply to this tenant’s source system or business model
  • Write 1–3 tenant-specific signals where the pack doesn’t have one that fits
  • Capture the second batch of Subject Matter — by now the domain expert has explained things you couldn’t anticipate

End-of-week test: finding counts per signal are honest. A “high severity” finding is something a person should actually look at. The signal registry no longer carries dormant noise.

Goal: one confirmed thesis the customer acts on.

What you do:

  • Sit with the executive or sponsor. Ask: “what question are you actually losing sleep over?” That question is your thesis.
  • Compose evidence from the calibrated signals
  • Write the verdict — the root cause and recommendation
  • Build, explore, present to the customer
  • Iterate based on their pushback. (There will be pushback. That’s the analysis happening — it isn’t done yet.)

End-of-week test: one confirmed thesis, one verdict, one recommendation the customer agrees with. That’s the first real analytical output.

After the first thesis lands, the cost curve flattens. New analytical questions cost 2–5 days each, not four weeks, because the Gold + signals + Subject Matter infrastructure is now in place.

The pattern repeats per question:

  1. Identify the question (with the customer)
  2. Compose evidence from existing signals — or write one new signal if needed
  3. Write the thesis + interpretations
  4. Build, explore, present
  5. Capture any new Subject Matter that surfaces

A mature tenant carries 5–10 confirmed theses, 30+ signals fine-tuned, 20+ Subject Matter entries documenting the institutional reality, and an ongoing rebuild cadence (weekly or monthly).

  • The customer trusts the system. They’ve seen it answer a question they care about. The next question is easier to scope.
  • The Subject Matter catalogue is load-bearing. Every weird thing the expert explained is now durable; the next analyst on the tenant doesn’t need to re-discover it.
  • The Gold contract is signed. Any new signal or thesis you write reads from a known shape; you’re not re-validating Gold every time.
  • The build is fast and boring. Weekly rebuild becomes routine.

If you’re onboarding multiple tenants of the same pack in parallel (typical for partners), week 1 of tenant N becomes much faster because:

  • The source-system dispatch macros are often reusable across tenants on the same ERP
  • The Subject Matter catalogue grows pack-wide knowledge that helps every tenant
  • The pack itself evolves — improvements found in one tenant ripple back to the pack and forward to others (the Steward — Sense 24 mechanism)
  • Setup is the analysis. The 15-minute init is the doorway, not the room.
  • Each layer (sources, Bronze, Silver, Gold, signals, theses, Subject Matter) gets its week. Skip a layer and the next one will tell you, loudly.
  • The first month is the expensive month. The work compounds.
  • A confirmed thesis the customer acts on is the goal of week 4 — not the start.
jazzisnow jinflow is a jazzisnow product
v0.64.7 · built 2026-09-20 19:48 UTC