A Practical Taxonomy for Your LoRA Library

A flat folder of 50 LoRAs with names like aesthetic_v3_final_FINAL.safetensors isn’t a library—it’s an archaeological dig site. This tutorial gives you a layered taxonomy that stays coherent whether you’re managing 30 LoRAs or 3,000, pairing manual naming conventions with automated metadata capture so the context behind every fine-tune is never lost.

Why LoRA Libraries Collapse—and When

Most LoRA collections start the same way: a single folder, a few downloads from CivitAI, maybe a couple of custom trains. It works fine at 10 files. By 50, you’re scrolling. By 200, you’re guessing.

The breakdown follows a predictable pattern. First, you lose base model compatibility—you forget which LoRAs were trained on SDXL versus SD 1.5 versus Pony Diffusion, and get garbled outputs. Then you lose training context—what dataset was used, what learning rate, what epoch this checkpoint represents. Finally, you lose aesthetic intent—you can’t remember whether painterly_02.safetensors was the one that nailed watercolor textures or the one that produced muddy skin tones.

Creative teams already spend roughly 25% of their time on what researchers call “digital archaeology”—hunting for files, reconstructing context, re-testing assets they’ve already evaluated. With AI content production growing 54–57% year over year, LoRA libraries are growing at a pace that makes casual organization untenable.

I think about this problem in two parts: structure (how you arrange and name things) and memory (how you capture the context that makes structure meaningful). You need both. A perfect folder hierarchy with no metadata is brittle. Rich metadata dumped into a single directory is unsearchable. The taxonomy below addresses both.

Layer 1: Base Model Compatibility

The first axis of your taxonomy is non-negotiable: which base model was this LoRA trained against?

A LoRA trained on SD 1.5 will produce artifacts or outright fail when loaded against an SDXL checkpoint. This isn’t a soft preference—it’s a hard technical constraint. Your top-level directory structure should make incompatible pairings impossible to accidentally create.

/loras
  /sd15
  /sdxl
  /pony-diffusion
  /flux-dev
  /flux-schnell
  /custom-finetunes

A few principles here:

• Separate model architectures, not just model names. SDXL and SDXL-Turbo share an architecture; SD 1.5 and SD 2.1 do not. Group by compatibility, not branding.
• Include a /custom-finetunes catch-all for LoRAs trained against your own merged or fine-tuned checkpoints. These need extra documentation because their base isn’t a publicly known model.
• Don’t nest deeper than necessary at this level. One folder per base. That’s it.

This layer answers one question: Can I use this file with the model I have loaded right now?

Layer 2: Training Purpose

Inside each base model folder, the second layer categorizes LoRAs by what they were trained to do. Four purpose categories cover the vast majority of use cases:

/sdxl
  /style       — Aesthetic and visual style transfers
  /concept     — Specific objects, characters, or scenes
  /technique   — Composition, lighting, or rendering methods
  /correction  — Fixes for known model weaknesses

Why these four? Because they map to distinct selection moments in a creative workflow:

• Style: “I want this to look like a 1970s movie poster.”
• Concept: “I need my specific character/product/mascot in this scene.”
• Technique: “I want dramatic rim lighting regardless of subject.”
• Correction: “SDXL renders hands poorly; this LoRA compensates.”

You’ll sometimes encounter a LoRA that spans categories—a style LoRA that also corrects anatomy, for instance. In those cases, file it by primary intent and use metadata (Layer 4) to tag secondary functions. Don’t duplicate files across folders. Duplication is where taxonomies go to die.

Layer 3: Naming Conventions That Carry Context

Filenames are metadata you can see without opening anything. A good naming convention encodes the most critical retrieval information directly into the filename itself.

Here’s a convention that balances density with readability:

[purpose]_[descriptor]_[base]_[version]_[strength-hint].safetensors

Examples:

style_watercolor-soft_sdxl_v2_mid.safetensors
concept_brand-mascot-revi_sdxl_v4_high.safetensors
technique_rim-lighting_sd15_v1_low.safetensors
correction_hand-anatomy_sdxl_v3_mid.safetensors

The components:

• Purpose prefix (style_, concept_, technique_, correction_) — Matches your Layer 2 folder. Redundant on purpose. If someone extracts the file from its folder, context travels with it.
• Descriptor — Hyphenated, human-readable. Keep it under 30 characters. Be specific: watercolor-soft beats art-style-01.
• Base — Abbreviated base model. Redundant with Layer 1, intentionally.
• Version — Sequential. v1, v2, etc. If you’re tracking training epochs, append: v2-ep8.
• Strength hint — low, mid, high. This captures the LoRA weight range where you’ve found the best results (e.g., mid = 0.4–0.6). It’s approximate and opinionated—that’s fine. It saves you from re-testing every time.

One rule I’d emphasize: never use “final” in a filename. Version numbers are final enough. Every file named final eventually gets a sibling named final2.

Layer 4: Metadata Tagging for What Filenames Can’t Carry

Filenames hold maybe 80 characters of useful information. The remaining context—training parameters, source datasets, aesthetic evaluations, licensing terms—needs to live in structured metadata.

At minimum, every LoRA in your library should have these fields documented:

Where does this metadata live? You have a few options:

• Sidecar files: A .json or .yaml file with the same name as the LoRA, in the same directory. Simple, portable, works with any tooling.
• A central registry: A spreadsheet, Notion database, or lightweight SQLite database indexing your full library. Better for search, worse for portability.
• Embedded in workflow tools: ComfyUI and A1111 both support metadata annotations in workflow files. Useful but siloed—the context lives in the workflow, not with the LoRA itself.

I’d recommend sidecar files as your foundation and a central registry as your search layer. That gives you both portability and discoverability.

Layer 5: Provenance and Lineage Tracking

This is the layer most people skip—and the one that matters most as regulations tighten.

The EU AI Act imposes penalties up to 3% of global revenue for AI transparency failures. California’s SB 942 carries fines of $5,000 per day for non-compliance with AI disclosure requirements. Even if you’re not directly subject to these regulations today, your clients or publishers may be. Knowing where a LoRA came from, what data it was trained on, and what outputs it influenced isn’t just good hygiene—it’s becoming a legal requirement.

Provenance tracking means recording:

• Upstream lineage: What data went into training this LoRA? Was it scraped, licensed, generated, or original?
• Downstream lineage: Which of your projects, outputs, or published images used this LoRA?
• Modification history: Was this LoRA merged with another? Re-trained on additional data? Modified from a community version?

Manual provenance tracking is possible at small scale but collapses fast. If you’re generating outputs across 3+ AI tools—which is the norm for most creative teams—the capture problem multiplies with every tool boundary. This is the gap where manual taxonomy meets infrastructure. Your naming conventions and folder structure handle the files you can see. Provenance tracking handles the invisible relationships between files, datasets, and outputs that accumulate after creation. For a deeper look at how provenance capture works in practice, see our complete provenance capture guide.

Putting It All Together: A Reference Library

Here’s what the full structure looks like in practice:

/loras
  /sdxl
    /style
      style_watercolor-soft_sdxl_v2_mid.safetensors
      style_watercolor-soft_sdxl_v2_mid.meta.yaml
      style_cyberpunk-neon_sdxl_v1_high.safetensors
      style_cyberpunk-neon_sdxl_v1_high.meta.yaml
    /concept
      concept_brand-mascot-revi_sdxl_v4_high.safetensors
      concept_brand-mascot-revi_sdxl_v4_high.meta.yaml
    /technique
      technique_rim-lighting_sdxl_v1_low.safetensors
      technique_rim-lighting_sdxl_v1_low.meta.yaml
    /correction
      correction_hand-anatomy_sdxl_v3_mid.safetensors
      correction_hand-anatomy_sdxl_v3_mid.meta.yaml
  /sd15
    /style  /concept  /technique  /correction
  /flux-dev
    /style  /concept  /technique  /correction

The system is two levels of folders (base model → purpose), one naming convention (purpose, descriptor, base, version, strength), and one sidecar metadata file per LoRA. That’s it. It handles growth because each layer is independent—adding a new base model means adding one folder, not restructuring everything.

Scaling Beyond Manual: When Taxonomy Needs Infrastructure

This taxonomy works well when you’re disciplined and your library is in the low hundreds. Three forces converge to make it insufficient:

1. Volume: At 34 million AI images generated daily across the industry, the LoRAs feeding those outputs multiply in kind. Your library will grow faster than your willingness to manually tag it.
2. Tool fragmentation: If you’re using ComfyUI, A1111, and a training pipeline, metadata lives in three places with three formats. Manual reconciliation doesn’t scale.
3. Team collaboration: The moment a second person touches your library, implicit knowledge (“I just know which watercolor LoRA is the good one”) becomes a findability crisis.

At that inflection point, the taxonomy described here becomes the schema for automated systems to populate—not something you maintain by hand. The folder structure, naming conventions, and metadata fields remain the same. What changes is how the information gets captured: automatically, at the moment of creation or import, with lineage recorded by default.

That’s the transition from organization to infrastructure. And that matters because a taxonomy without capture is a promise you’ll eventually break. If you’re already feeling that strain, our guide to managing LoRA files in ComfyUI covers the tooling side of the equation.