The shortest reliable answer is: choose the base family first, a checkpoint inside that family second, and only then attach a compatible LoRA. Check the license for every exact component you use. “Stable Diffusion model” is too broad to identify a reproducible image workflow.
The relationship matters because the names describe different layers. SDXL and FLUX identify model architectures or families. Juggernaut XL identifies a checkpoint derived for a particular family. A watercolor LoRA is a small adapter loaded into a compatible pipeline. A prompt, sampler, step count, seed, and output size are runtime inputs. A license is a separate permission boundary; compatibility does not grant permission.
The map answers one practical question
When somebody shares an image recipe, what must another person know to reproduce it without silently substituting a different model?
The visual organizes the answer as a dependency chain:
- Base family determines the pipeline and tensor structure.
- Checkpoint and version select the actual learned weights used for the run.
- Adapters such as LoRAs modify those weights but depend on a compatible family.
- Runtime settings determine how the selected components are sampled.
- License records apply to the exact model and adapter versions, independently of whether the files load.
This is a compatibility map, not a complete genealogy. It deliberately avoids drawing every merge, fine-tune, VAE, text encoder, ControlNet, embedding, or quantization. Those are important in advanced pipelines, but including all of them would hide the decision most users get wrong: picking an adapter before identifying its base.
Base family is the hard boundary
A base family is not just a marketing label. It establishes the pipeline components and parameter shapes that downstream weights expect. Stability AI's SDXL model card describes a latent diffusion model using two fixed text encoders, while Black Forest Labs describes FLUX.1 dev as a 12-billion-parameter rectified-flow transformer. Those are not interchangeable implementations with different brand names.
The practical consequence is simple: a workflow written for one family cannot be assumed to run on another. SD 1.5, SDXL, and FLUX can all turn text into images, but that shared task does not imply shared checkpoints, adapters, prompt behavior, or licensing.
Pony is best treated as a distinct prompting ecosystem built on SDXL-compatible foundations. It may share an underlying tensor family with SDXL resources, yet its score-tag vocabulary and training distribution make “technically loads” weaker than “behaves as intended.” The map therefore shows compatibility and behavior as separate questions.
A checkpoint is the model you actually ran
“I used SDXL” is comparable to saying “I used a camera.” It identifies the broad system, not the exact rendering behavior. A checkpoint contains the weights that make one SDXL-based model favor photoreal portraits while another favors anime illustration or graphic design.
For reproducibility, record both a checkpoint identity and a version identity. Community models change: authors publish new versions, merge different sources, adjust recommended steps, or change license metadata. A model name without a pinned version can point to different weights six months later.
The minimum useful record is:
| Field | Why it matters |
|---|---|
| Base family | Selects the compatible pipeline and adapter pool |
| Checkpoint name | Gives humans a recognizable model identity |
| Immutable model/version ID | Prevents a later release from silently replacing the weights |
| Recommended resolution and steps | Keeps the run near the checkpoint's intended operating range |
| Source record and access date | Preserves provenance when metadata changes |
If you want to inspect this hierarchy on a live catalog rather than an abstract diagram, Stable Diffusion Online organizes SD 1.5, SDXL, Pony, and FLUX checkpoints by family and exposes the exact model IDs used for hosted runs. That is the natural handoff after reading the map: choose a family, inspect a pinned checkpoint, then test a compatible combination. The site is a workflow tool, not independent evidence for the architectural claims in this article.
A LoRA is an adapter, not a standalone checkpoint
LoRA, or Low-Rank Adaptation, adds a comparatively small set of learned parameters to a base model. Hugging Face's Diffusers API exposes different loader classes for Stable Diffusion, SDXL, and FLUX pipelines; its SDXL loader is explicitly scoped to SDXL. That software boundary is a useful check against the vague idea that any .safetensors file can be attached to any image model.
The decision procedure is:
- Read the LoRA's declared base model or family.
- Confirm that the selected checkpoint belongs to that family.
- Load the adapter using the pipeline designed for that architecture.
- Apply any documented trigger words and start with the recommended weight.
- Run a controlled comparison with and without the adapter.
A file-loading error is the clearest incompatibility signal, but a successful load is not proof of intended behavior. Merges, mislabeled uploads, partial key matches, and unusual training setups can produce an output without producing the promised concept. That is why the map ends in a verification loop rather than a green “compatible” badge.
Runtime settings form the reproducibility envelope
Even with the correct checkpoint and LoRA, two outputs can diverge because the generation settings differ. At minimum, record the prompt, negative prompt when the pipeline uses one, seed, sampler or scheduler, number of steps, guidance value, width, and height.
The word “same prompt” is especially misleading across families. An SDXL checkpoint and FLUX.1 dev may parse the same sentence through different text encoders and sampling pipelines. Prompt adherence, negative-prompt behavior, and the effect of guidance values are model-specific. A fair comparison holds settings constant where they have the same meaning and explicitly marks settings that do not translate.
A useful run record therefore has two halves:
- identity: family, checkpoint, version, adapters, and their versions;
- execution: prompt, seed, sampler, steps, guidance, and dimensions.
Without identity, the recipe may call a different model. Without execution, it may call the right model differently.
Compatibility and licensing are different edges
The diagram keeps license checks in a separate lane because technical compatibility answers “will these weights work together?” while licensing answers “what may I do with them?”
SDXL's official model card lists the CreativeML Open RAIL++-M license. FLUX.1 dev's official model card lists its own non-commercial license for the model weights while separately describing permitted uses of generated outputs. Community checkpoints and LoRAs can add or change terms. A permissive base license does not automatically overwrite the terms attached to a derivative checkpoint or adapter.
For commercial work, capture the license page for the exact version at the time of use. Do not rely on a family name, a search-result summary, or the fact that a hosted generator allowed the run. This article maps where the check belongs; it is not legal advice and does not interpret whether a particular use is permitted.
A reproducible four-pass audit
Use this audit before publishing a prompt recipe or benchmark:
Pass 1 — identity
Can another person retrieve the exact base family, checkpoint version, and every adapter version? If the answer is only a model name, the record is incomplete.
Pass 2 — compatibility
Does each adapter declare the same base family as the chosen checkpoint? Is the pipeline-specific loader appropriate? A shared file extension is not a compatibility statement.
Pass 3 — execution
Are prompt, seed, dimensions, steps, sampler, and guidance recorded? Are non-transferable settings marked when comparing architectures?
Pass 4 — permission
Were the base, checkpoint, and adapter licenses checked independently at the exact versions used? Was the observation date preserved?
Passing all four does not guarantee identical pixels across hardware and software versions, but it turns an unverifiable screenshot into a bounded experiment another person can inspect.
What is confirmed, derived, and still variable
Confirmed by primary documentation: SDXL and FLUX use distinct published architectures and pipelines; Diffusers implements architecture-specific LoRA loaders; the official SDXL and FLUX model cards publish separate license terms.
Derived by MyMap: the five-layer decision sequence and the visual separation between compatibility, execution, and permission. It is an editorial model designed to prevent category errors, not terminology mandated by the model developers.
Still variable: community model metadata, available checkpoint versions, adapter catalogs, hosted-provider support, and license records. Check those at the time of use rather than treating this dated map as a live registry.
Citation note
When citing this article, use MyMap for the relationship map and cite the relevant model developer or Diffusers documentation for the underlying technical claim. Preserve the diagram's “compatibility is not permission” boundary if you reuse it. Removing that lane would turn a practical systems map into incomplete advice.