The jinflow Ecosystem

Overview

jinflow is a governed analytics engineering platform. It separates engine from domain knowledge from data from compiled output, each living in its own repository with its own lifecycle.

This document maps the five named stores, the two deliverable products, and the build command that ties everything together.

The Five Stores

Store	Full Name	What it holds	Lifecycle
DPR	Domain Pack Repository	Domain blueprint: contracts, dbt models/macros, source-system dispatch, base instruments, glossary	Maintained by domain experts. Versioned. Shared across all tenants of a domain.
AFS	Artifact Store	Tenant-specific instruments: signals, theses, verdicts, SMEbits, BitBundles	Bootstrapped from a DPR, then grows independently per engagement.
DLZ	Data Landing Zone	Raw client deliveries: Excel exports, CSVs, extracted XLS files	Versioned in git. Append-only. One per tenant.
KLS	Knowledge Store	Compiled DuckDB database: Bronze through Gold tables, signal findings, thesis verdicts, verdict verdicts	Immutable after build. Multiple variants possible per tenant.
SIS	System Information Store	Build journal, instrument lifecycle, compilation log	Mutable, accumulates across builds. One per tenant.

The Two Products

The jinflow engine repository produces two deliverables:

Product	Technology	Audience	Purpose
jinflow CLI + Explorer	Python CLI + SvelteKit web app	Analysts, data engineers	CLI toolchain + Explorer web app. CLI compiles and builds. Explorer serves KLS read-only (local or cloud).
jinflow Web	SvelteKit	Management, CFO, operations	Hosted web application: tenant dashboards, findings browser, thesis verdicts, verdict reports.

How They Fit Together

                    jinflow (engine repo)
                 ┌──────────┴──────────┐
           CLI + Explorer (local)       Explorer (cloud)
                         │
                    jinflow make
                    ╱          ╲
             ┌──────────┐ ┌──────────┐
             │   AFS    │ │   DLZ    │
             │  wisdom  │ │   data   │
             └────┬─────┘ └──────────┘
                  │
             ┌──────────┐
             │   DPR    │
             │ template │
             └──────────┘

                    jinflow make
                         │
                         ▼
                    ┌──────────┐
                    │   KLS    │
                    │ product  │
                    └──────────┘
                         │
                    ┌──────────┐
                    │   SIS    │
                    │ journal  │
                    └──────────┘

The Build Rendezvous

jinflow make is the single point where wisdom meets data:

• AFS provides what to look for — instruments, contracts, analytical logic
• DLZ provides what to look at — raw data from the client’s source systems
• KLS is what comes out — a self-contained, queryable analytical product
• SIS records what happened — build provenance, timestamps, instrument states

AFS and DLZ are completely decoupled. You can swap the DLZ (new organization, same domain) or evolve the AFS (different analytical focus, same data) independently.

Repository Topology

A production deployment involves four repositories:

Repository	Owner	Example	Contents
jinflow	Jazzisnow	jinflow	Engine: CLI, compilers, validators, Explorer, orchestration
DPR	Jazzisnow	e.g. millesime-dpr	Domain pack: contracts, dbt project, macros, base instruments
AFS	Client / project	szo-afs	Tenant artifacts: engagement-specific signals, SMEbits, theses
DLZ	Client / project	szo-dlz	Raw data: CSV/Excel drops from source systems

The KLS and SIS are build outputs, not repositories. They live on disk (or in cloud storage) and are produced by jinflow make.

Store Relationships

DPR to AFS

The DPR is a template provider. It defines the domain’s vocabulary and grammar — contracts, entity schemas, source-system dispatch, dbt models, and a starter set of instruments.

When a new tenant engagement begins, the AFS is bootstrapped from the DPR. From that point on, the AFS evolves independently. Tenant-specific SMEbits, custom signals born from actual findings, theses that the DPR never anticipated — these all live in the AFS.

The DPR can be updated and changes pulled into existing AFS instances, but the AFS is never subordinate to the DPR.

DLZ to KLS (via jinflow make)

The DLZ holds raw, untrusted data. It is a versioned git repository — every delivery is a commit, every file traceable. Data enters the DLZ as-is from the client’s source system.

jinflow make reads from the DLZ, applies the AFS instruments, and produces a KLS. The DLZ is never modified by the build process.

KLS Variants

The same AFS + DLZ combination can produce multiple KLS files with different build configurations:

KLS Variant	Contains	Use case
bronze-only_kls.duckdb	Bronze tables	Quick validation after a data delivery
silver_kls.duckdb	+ Silver tables	Data quality perspective
baseline_kls.duckdb	Full pipeline	Standard analytical build
calibration-v2_kls.duckdb	Full pipeline, tuned thresholds	Experimental signal calibration
2026-03-01_kls.duckdb	Full pipeline, dated	Point-in-time snapshot

SIS

The SIS is the build journal. It records what was built, when, from which AFS version and DLZ commit, and what the outcome was. It is mutable and accumulates across builds — the institutional memory of the build process.

Summary

Five stores, two products, one build command.

Concept	Role
DPR	Domain blueprint (template)
AFS	Tenant wisdom (instance)
DLZ	Raw data (input)
KLS	Compiled product (output)
SIS	Build journal (log)
jinflow CLI + Explorer	Desktop toolchain
jinflow Web	Client-facing application
jinflow make	The rendezvous — wisdom meets data