JIT-Atlas: what it is and how it works

What a quest is

An interactive, single-file HTML document that models one software system as a navigable flow.

A quest shows what runs where, what crosses each boundary, what happens at each stage, and where the common failures come from. You land on the whole-system flow and drill into stages and terms without losing your place.

The gap it addresses is not missing information; official documentation is thorough. The gap is usability under load. Developers meet problems just-in-time: mid-build, attached to a concrete failure. Reference documentation is organised by feature, not by the shape of that failure.

Today: 81 published quests, each a self-contained HTML file. They share one scaffold, but as a convention re-implemented in every file, not as shared code.
Target: One engine, many content payloads, one catalogue and one validated build pipeline.

Where it sits on Diátaxis

Diátaxis sorts documentation by two questions: does it help you do or know, and are you studying or working?

Tutorialslearn by doing

How-to guidesget a task done

Explanationunderstand why

Referencelook it up

JIT-Atlas

JIT-Atlas sits on the knowing side, between explanation and reference.

Its substance is explanation: Each quest builds a model of how a system works and why it fails the way it does.
Its shape borrows from reference: Each quest has a flat glossary for lookup, a permanent address and deep links straight to a stage. That shape is what lets explanation be used at work.

Alongside what you already use

JIT-Atlas sits between the resources developers already reach for, and each of them stays the right tool for its own job. A quest is the one you open when you need the mechanism behind one failure, right now.

Official documentation: Complete and authoritative, organised by feature. Keep it for exact APIs, options and edge cases. A quest shows which part of the system your failure lives in, and why, then sends you back to the docs knowing what to look up.
Tutorials and courses: Build skill from the beginning, in order. A quest assumes you are already building, and drops you at the stage you are stuck on.
Books and long explainers: Depth, read from start to finish. A quest carries the same kind of model in a form you can land in the middle of.
Q&A threads: A fix for one symptom, often without its cause. A quest shows the mechanism, so the next symptom makes sense too.
An LLM: An answer made on demand, unchecked, and gone when the task ends. A quest was checked before you opened it, and it is still there next time.

What a quest adds is reach at the moment of need: a small, checked piece of the whole model, deep-linked to the exact stage, ready when you hit the wall.

Inside a quest

Every quest has the same parts, at three scales. On the platform they become the content model the engine renders and the validator checks.

Flowmacro

Region

Boundary

Region

Stagesmeso

Stage
Stage
Stage

Termmicro

Term

GlossaryA–Zsearch

Open a region and its stages appear in place; open a stage and its term appears beside it. The dashed line is a boundary marker, where execution context changes.

Flow: The whole system as an ordered sequence of regions and stages. You land here.
Regions: Stages clustered into a few named regions.
Stages: Each region opens into ordered steps, or a tree of nodes.
Taglines: A one-line summary on every stage and node, so the flow reads before anything is opened.
Terms: A focused explanation of one concept, opened without leaving the flow.
Glossary: A flat, searchable list of every term in the quest.
Boundary markers: Explicit "runs on" and "crosses" notes wherever execution context changes: server and client, build and runtime, process and process, JS and native, device and network.

How you move through one

Land on the flow: You arrive at the whole system and drill down, never the reverse.
Expand in place: Opening a stage or a term keeps your position and context.
Three ways in: Skim the flow, drill into a stage, or jump straight to a term through the glossary. Each is supported equally.
Non-linear by default: There is no enforced "next". You follow the path your problem sets. Missions in a campaign add an order on top.
One concept per term: Each term covers exactly one idea.
Progress stays in your browser: The stages and terms you have visited are remembered locally, with no backend, so a quest keeps your bearings between sessions.

How one is written

Flow first: The flow and its boundaries are written before any term.
Boundary discipline: Every change of execution context is marked.
Framed by failure: Terms start from the confusion or failure they cause in practice, not from an abstract definition.
Taglines everywhere: No stage or node ships without one.
Plain, precise language: Technical accuracy without ceremony.

Principles

Every quest is held to these.

Flow first: Detail hangs off the flow. A concept that cannot be placed on the flow does not belong in the quest.
Boundaries are first-class: Every move between execution contexts is marked explicitly. This is the spine of the method.
Just-in-time delivery: Quests are built to be opened mid-task, at the point you hit a wall.
Navigability is the interface: You move through the system: open a stage, open a term, follow a path. The interaction carries the understanding.
Surface the invisible: Anything a system does silently, such as a marshalling step, a graph split, a render wave or a deduplication pass, is drawn as something you can see and inspect.

Why quests are built ahead of time

When you are stuck mid-build, the default help is an LLM that explains on demand. JIT-Atlas differs from it on purpose.

Just-in-time means deferring something to the moment of need and treating anything held earlier as waste. For understanding, that move can be made on three separate axes, and the design choice is which of them to make it on.

AxisAn LLMA quest

ProductionWhen is the explanation made?

Just-in-timeGenerated on demand, made to order.

Ahead of timeBuilt and checked first, held in the catalogue.

DeliveryWhen does it reach you?

Just-in-timeAt the wall, mid-build.

RetentionHow long does the understanding last?

Just-in-timeGone when the task ends; nothing is banked.

KeptBuilt to persist as standing knowledge.

The decision: just-in-time on delivery only

Delivery is just-in-time: Meeting a concept at the moment you need it is what makes it stick; the same concept studied in the abstract ahead of time is forgotten. A quest opens at the wall you actually hit, deep-linked to the exact stage. It works like a JIT compiler: triggered on the hot path, then cached.
Production is not: Building ahead of time and holding stock is what buys an inspected, maintained, known-correct quest. On-demand generation has no quality buffer. Whatever comes off the line at that instant is what you get, and it can be confidently wrong.
Retention is not: Understanding that disappears when the task ends leaves you no model to debug with or build on later. The point of a quest is the opposite: understanding that stays.

You can only verify what you comprehend.
The thesis behind both refusals

What that costs

Maintenance: Quests have to be kept current with the systems they model. That burden is the price of the known-correct guarantee.
Coverage: A catalogue cannot answer a wall no quest covers; an LLM can always produce something. JIT-Atlas accepts narrower coverage in return for correctness within it, and closes the gap through the content roadmap.
Forecasting: Building ahead means deciding ahead which systems are worth modelling. That is a real planning cost that the on-demand alternative does not carry.

A quest and an LLM are both just-in-time on delivery, which is why both feel available at the moment of need. They part ways on production and retention, where JIT-Atlas trades on-demand answers for correctness and durability.

The catalogue

Four quests show the method holding from a single function call up to a whole distributed system.

Distributed system
How search works: crawl, index, serve
A URL from the open web through crawling, rendering, deduplication, indexing, retrieval, ranking and result assembly.
Framework (build)
The anatomy of a Next.js 16 build
Route discovery, the server/client graph split, chunking, asset optimisation, static rendering and the emitted output.
Framework (runtime)
The anatomy of a Next.js request
A request through routing, RSC, server rendering, streaming, client references, the network seam and hydration.
Runtime
fetch(), end to end
One fetch() call across JS, WebIDL, the C++ engine and the network stack, into a Node server (libuv, IncomingMessage, ServerResponse), and back to the promise resolving.

Read from the bottom, the last three are a deliberate thread up the same stack. First comes one fetch() call. Then comes the framework that orchestrates thousands of such crossings at request time. Last comes the build that decides, ahead of time, where those boundaries fall.

The search quest models a different kind of system entirely: a large distributed pipeline. Its parts include a URL frontier, robots.txt, two-wave rendering, duplicate clustering with SimHash and MinHash, an inverted index with posting lists, sharding, BM25, TF-IDF and PageRank, and snippet assembly. The scaffold absorbed it without changes; only the content changed.

More of what the catalogue spans

Node.js runtime fundamentals: The event loop, libuv, the microtask and macrotask queues, streams, the module system.
Databases and SQL: Query parsing, planning and execution, indexes, transactions and isolation, the write-ahead log.
Authentication and sessions: The OAuth and OIDC flow, token lifecycles, cookie and session boundaries, where trust crosses.
Deployment and delivery: CI/CD pipelines, container build and run, CDN and edge caching, DNS resolution.
APIs and networking: The request and response lifecycle, the TLS handshake, HTTP semantics, REST and GraphQL resolution.
React internals: Reconciliation, the render and commit phases, scheduling hooks and effects.

The same systems-and-boundaries method extends to security (attack surfaces, trust boundaries), data pipelines and cloud architecture.

Where JIT-Atlas is heading

From hand-written files to one engine, one checked pipeline and one catalogue, while every quest stays a single self-contained file.

Each quest today is a single self-contained HTML file: no backend, no build step and nothing to load at view time. It can be hosted as a static file or opened locally. That keeps quests portable, but it does not scale to a catalogue. Each quest re-implements the same flow rendering, navigation, glossary, boundary markers and progress saving by hand, so a fix, a design change or a new interaction has to be repeated in every file.

Authorwrites the content
Contentflow, regions, stages, terms, boundaries, as data
Validatorschema, boundary coverage, taglines, currency
Buildengine plus checked content
Questone self-contained HTML file
Catalogueindexed, versioned
ReadersIDEs, workflows, deep links to a stage

Enginerenders and drives the scaffold; feeds the build

Every part is still to be built. The engine will be extracted from the existing quests, and the validator will generalise the checks each quest already has.

Writing and publishing a quest

StepTodayOn the platform WriteHand-written HTMLStructured content data CheckManual reviewAutomated checks: schema, boundary-marker coverage, taglines, technical currency BuildThe file is the questEngine plus content, compiled into one self-contained file PublishCopy the fileRegister the quest and its version in the catalogue

Rules that hold now and later

One file: Every quest ships as one self-contained HTML file.
Technical currency: Quests are kept current with the systems they model. For example, the Next.js quests reflect Next.js 16: Middleware renamed to Proxy, and Turbopack as the default builder.
Legibility: Diagrams use sufficient contrast and labelled regions, and colour never carries meaning alone.
Consistency: Navigation learned in one quest works in every other. New quests do not invent new navigation.

The roadmap

Extract the enginePull the scaffold out of the existing quests as a reusable rendering and navigation core.
Define the content modelExpress a quest as structured data: flow, regions, stages, terms and boundaries.
Build the validatorAutomated checks for the schema, boundary coverage, taglines and currency.
Build the catalogueAn index with metadata and a version for each quest.
Build the publish pipelineContent, then validation, then a single-file build, then registration.
Migrate the existing questsBring the 81 published quests onto the engine and schema, smoothing out structural differences.
Distribution and embeddingStatic hosting, deep links to a stage, and embedding in IDEs and workflows.
ContributionA path for others to write quests that conform to the schema.

Still to decide, before the engine is extracted

Content format: Markdown or MDX, JSON, or an authoring interface.
Engine technology: A framework or plain JavaScript; either way, the output must stay one self-contained file with no backend.
Distribution: Static files, an npm package or CLI, a hosted site, or a mix.
Hosting: Self-hosted only, or a managed catalogue.
Contribution and access: Open or curated authoring, and licensing.
Consistency: How uniformly existing quests follow the scaffold. This sets the migration effort and how strict the schema can be.

How people use it

The core case is mid-build. The others follow from it.

Mid-build: You hit a wall, open the quest at the exact stage, build the model and get back to work.
Before starting: Skim the flow before a feature to get its shape, and hit fewer walls later.
In review: In code review or mentoring, point to the stage that explains why a bug happened.
Before delegating to an AI agent: Use the quest to find the boundaries and edge cases worth writing into a spec or a CLAUDE.md.
Onboarding: A new team member works through the quests for the team's stack and gets the shared model without monopolising a senior engineer.
Alongside a course: In a project-based programme, quests supply the explanation used in lessons, project weeks, debugging and revision.

What it is not

JIT-Atlas does not replace official documentation. It does not walk you step by step toward one finished project, the way a tutorial does, and it does not hand out how-to recipes. It is also not an LLM wrapper or a code generator: a quest builds your own model of a system, and it does not produce output on your behalf.

JIT in three fields

The just-in-time idea began outside software and was borrowed twice.

Manufacturing post-war Japan

Just-in-time was born in the Toyota Production System under Taiichi Ohno. Capital and space were too scarce for large inventory buffers, so each part was made only when the next step signalled for it (the kanban card). Inventory became waste. The cost showed at once: without a buffer, a missed forecast stops the line.

JIT-Atlas avoids this on production. On-demand generation is a make-to-order line with no buffer, and its stockout is a wrong answer delivered on time.

Computing 1960 to the late 1990s

A JIT compiler defers translation to machine code until a path first runs, then caches the result. Waiting buys information: only at runtime is it known which paths are hot. The idea goes back to McCarthy's LISP work in 1960; the landmark implementation is Deutsch and Schiffman's Smalltalk-80 system in 1984, and Java's HotSpot took the term mainstream in the late 1990s.

JIT-Atlas keeps this one: delivery deferred to the hot path, then cached.

Security from 1975

JIT access grants a privilege only when a task needs it, scopes it to that task, and revokes it afterwards. Standing privilege is security's inventory: unused capability, and so attack surface. The idea descends from the principle of least privilege (Saltzer and Schroeder, 1975).

JIT-Atlas refuses this for understanding. Revoke-after-use is exactly what a quest is built against, because understanding is meant to stay.

JIT-Atlas: what is it? How does it work?