Crate Map & Feature-Flag Reference

This page is the consumer/dependency view of the Paladin workspace: which crates exist, what each one is published as, how they depend on one another, every Cargo feature flag, and copy-paste Cargo.toml profiles for common setups.

For the architecture-layer view (module-by-module breakdown, hexagonal boundaries, "adding a new crate"), see Architecture → Crate Map. For the canonical per-flag default table, see Feature Flags.

All versions on this page target the current published workspace, v0.5.0.

Workspace Crate Table

The workspace is a single umbrella crate (paladin-ai, published lib name paladin) plus nine member crates under crates/. Note that paladin-core's published package name is paladin-ai-core (the directory is crates/paladin-core and the lib name is paladin_core).

The root umbrella crate paladin-ai (lib name paladin) re-exports the most common types and gates every infrastructure crate behind feature flags — most applications depend on paladin-ai rather than wiring the member crates by hand.

Crate Dependency Graph

Every member crate depends only inward — on paladin-ai-core (domain) and/or paladin-ports (contracts). No infrastructure crate depends on another infrastructure crate, with one optional exception: paladin-content can pull in paladin-llm (behind its llm feature) for AI content analysis.

graph TD
    root["paladin-ai (umbrella, lib: paladin)"]
    core["paladin-ai-core"]
    ports["paladin-ports"]
    batt["paladin-battalion"]
    llm["paladin-llm"]
    mem["paladin-memory"]
    stor["paladin-storage"]
    cont["paladin-content"]
    notif["paladin-notifications"]
    web["paladin-web"]

    ports --> core
    batt --> core
    batt --> ports
    llm --> core
    llm --> ports
    mem --> core
    mem --> ports
    stor --> core
    stor --> ports
    cont --> core
    cont --> ports
    cont -.->|feature: llm| llm
    notif --> core
    notif --> ports
    web --> core
    web --> ports

    root --> core
    root --> ports
    root --> batt
    root --> llm
    root --> mem
    root -.->|feature| stor
    root -.->|feature| cont
    root -.->|feature| notif
    root -.->|feature| web

Solid edges are unconditional dependencies; dashed edges are feature-gated. From the umbrella crate, paladin-storage, paladin-content, paladin-notifications, and paladin-web are optional dependencies enabled by feature flags (storage*, content-processing, notifications, web-server).

Feature-Flag Reference

Root umbrella crate — paladin-ai

default = ["llm-openai"].

paladin-llm

default = ["openai", "mock"].

paladin-memory

default = [].

paladin-storage

paladin-content

paladin-notifications

paladin-ai-core, paladin-ports, paladin-battalion, and paladin-web expose no feature flags — they are always compiled in full.

Consumer Profiles

Three ready-to-use dependency profiles for the umbrella crate, plus a granular "member crates" option for fine-grained control.

Minimal — single agent, in-memory + SQLite garrison, OpenAI

The defaults already include the OpenAI provider, the orchestration runtime, and the in-memory/SQLite garrison — enough to build and run a single Paladin.

[dependencies]
paladin-ai = "0.5.0"   # default features: ["llm-openai"]
tokio = { version = "1", features = ["full"] }

Standard — orchestration, multiple LLMs, SQLite storage, vector memory

[dependencies]
paladin-ai = { version = "0.5.0", features = [
    "llm-anthropic",   # add Anthropic alongside the default OpenAI
    "llm-deepseek",    # add DeepSeek
    "storage-sqlite",  # SQLite SQL repositories
    "qdrant",          # Qdrant-backed Sanctum vector memory
    "notifications",   # email / push / system notifications
] }
tokio = { version = "1", features = ["full"] }

Full — everything enabled

[dependencies]
paladin-ai = { version = "0.5.0", features = ["full"] }
tokio = { version = "1", features = ["full"] }

The full feature pulls in all LLM providers, the content-processing pipeline, the web server, notifications, both SQL backends, vision, Redis queue, S3 storage, OpenAI embeddings, Qdrant, and the CLI.

Granular — depend on member crates directly

For consumers who want to avoid the umbrella crate and wire only what they need (note the package = "paladin-ai-core" rename for the core crate):

[dependencies]
paladin-core = { package = "paladin-ai-core", version = "0.5.0" }
paladin-ports = "0.5.0"
paladin-battalion = "0.5.0"
paladin-llm = { version = "0.5.0", features = ["openai", "anthropic"] }
paladin-memory = { version = "0.5.0", features = ["sqlite"] }
tokio = { version = "1", features = ["full"] }

See Also

• Architecture → Crate Map — module-level layout and hexagonal boundaries.
• Feature Flags — per-flag defaults and rationale.
• Orchestration Patterns — using paladin-battalion.
• Content Processing — using paladin-content.