Five topologies.
One product.

Pre-make and make. AFS, KLS, SIS.
Where things live. Where make happens.

The pipeline has two phases.

  • Pre-make — preparation. Extracts source data from the DLZ. Fetches notes and bookmarks from the SIS. Writes everything to the AFS. Commits to git. Has side effects.
  • Make — build. Reads only from AFS. Writes only to KLS. No SIS mutation. No external fetches. No network calls. A pure function.
  • The cut is the security boundary. Whoever controls make controls the analytical truth. Every build is reproducible from its AFS commit.
  • Everything that goes into make is in git. Auditable. Reversible. Reproducible.

AFS. KLS. SIS.
Each has its own role, its own access pattern.

AFS
The Analytical Framework.
A git repo. YAML instruments.
Compiled artifacts, published notes.

Read + write by pre-make and make.
KLS
The Knowledge Store.
A DuckDB file. Immutable after build.
Bronze → Silver → Gold → findings.

Written by make. Read by Explorer.
SIS
The System Information Store.
A DuckDB file. Mutable.
Notes, bookmarks, audit, preferences.

Messenger and memory. Never in make.

Pre-Make. Make. Explore.

Pre-Make
Extract from DLZ.
Fetch SIS notes.
Commit to AFS.
→
Make
AFS in, KLS out.
Pure function.
No side effects.
→
Explore
Browse findings.
Write notes.
Save bookmarks.

Notes and bookmarks written in Explore go to SIS. Pre-make publishes them to AFS.
The SIS is the bridge between users who don't have git and the build that needs git.

Same product. Different placement.

  • 1. Local — everything on one machine. Developer's laptop. No auth. Simplest and most private.
  • 2. Proxy (P2P2P) — KLS on the owner's machine. Explorer in the cloud. One SIS in the cloud. Your data. Your machine. Their browser.
  • 3. Cloud (R2) — KLS uploaded to Cloudflare R2. Explorer + SIS in the cloud. GitHub OAuth. Always on.
  • 4. Semi-Cloud — KLS stays local (via proxy). SIS in the cloud. For compliance: KLS can't leave, SIS can.
  • 5. Make-as-a-Service — make runs in the cloud. Triggered by git push. No local machine needed. The endgame.

Pick by data sensitivity and collaboration

Only you use it
Mode 1 — Local
Simplest. Everything on one machine.
Multi-viewer, sensitive data
Mode 2 — Proxy (P2P2P)
KLS stays local. Tunnel serves remote viewers. Ctrl+C unplugs.
Non-sensitive, always-on
Mode 3 — Cloud (R2)
Upload KLS. Standard cloud auth. 24/7 availability.
Compliance: data can't leave
Mode 4 — Semi-Cloud
KLS stays local via proxy. User activity (SIS) OK in cloud.
Automated CI/CD builds
Mode 5 — Make-as-a-Service
Cloud worker runs pre-make + make. Git push triggers.
Mixed fleet
All five can coexist
Explorer picker shows cloud tenants, proxy tenants, or both.

Messenger and memory.
Never split. Never merged.

Memory (long-term)
Notes, bookmarks,
acknowledgments, preferences.
Notes and bookmarks
published to AFS by pre-make.

Survives rebuilds.
Messenger (short-term)
Recents (navigation journal),
session state, scroll position.
Rotated, never published.

Ephemeral by design.
One Location
Local mode: developer's machine.
All cloud modes: in the cloud.
Pre-make always knows
where to fetch from.

No splits. No merge conflicts.

One path. All five modes.

DLZ
source data
→
pre-make
gather
→
AFS
git
→
make
pure function
→
KLS
Explorer reads

In Mode 1, this whole flow runs on the developer's laptop.
In Mode 5, it runs in the cloud on git push.

The code paths converge. Only the placement differs.

One product.
Five topologies.

Start with Local for development.
Move to Proxy (P2P2P) for sensitive data.
Cloud (R2) when you want always-on.
Make-as-a-Service when you want CI/CD.

The code paths converge. The security boundary holds.

jinflow.io