Costs, policy, and catalogue intelligence.

Why it exists

Once hosted models enter the provider mix, a pipeline that fans out a dozen LLM calls plus image generations plus renders per video has a real, invisible bill. Cost awareness is the difference between "this feels expensive" and "this brand spent $4.20 this month, mostly on thumbnails." And budgets turn awareness into policy: a brand can never silently overrun.

What gets recorded

Every LLM call, generated image, and clip render lands in the append-only cost_events table:

Capture happens at the single LLM choke point (complete() in the provider integration), at Runware image generation (provider-reported USD), and per rendered clip (wall-clock). Recording is best-effort: a ledger failure never fails the work that incurred the cost.

Pricing — COST_RATES_JSON

Local models cost $0 (and still record token volume — you see usage, not just spend). Hosted models are priced by the COST_RATES_JSON runtime setting on /settings: a JSON array of rules where match is a case-insensitive substring of the model name and the first hit wins.

// COST_RATES_JSON — USD per million tokens, first match wins
[
  { "match": "gpt-4o-mini", "input_per_mtok": 0.15, "output_per_mtok": 0.60 },
  { "match": "sonnet",      "input_per_mtok": 3.00, "output_per_mtok": 15.00 }
]

Budgets — what's gated, what's never gated

Set "Monthly budget (USD)" on a brand. When the UTC calendar month's spend reaches the budget, new generation spend stops:

The principle: a budget pauses drafting new copy, never understanding videos or shipping approved work. Nothing you've already approved gets stuck behind a cap.

Where you see it

/performance → "Costs — month to date": per-brand spend by category, token volume, render minutes, budget status (warns at 80%), plus the top packages by spend.

Why it exists

After a few dozen packages you know which asset types you trust. If you've approved every high-confidence LinkedIn post for a brand without edits, the review click is pure friction — and at multi-brand scale it's the bottleneck. Auto-approve turns that earned trust into an explicit, per-brand policy instead of a habit.

How scoring works

Rules live on the brand form (brands.auto_approve_rules) as per-asset-type thresholds:

[ { "asset_type": "linkedin_post", "min_score": 0.8 } ]

When generate_asset produces an asset, it derives a quality score from the payload — in order of preference:

If the score clears the rule's threshold, the asset skips ready_for_review and routes through the existing auto-dispatch path.

The audit trail

Every auto-approved asset is stamped with payload.auto_approved = {score, threshold, reason, at} — so you can always answer "why did this go out without me?" after the fact. Policy without auditability would be a footgun; this is the receipt.

Hard limits

• *_plan assets are never auto-approvable — plans gate clip rendering, and approving a plan triggers renders.
• rendered_* assets are never auto-approvable — rendered rows have their own lifecycle.
• Assets without any quality signal never auto-approve — silence is not confidence.

The evaluation logic is a pure function (src/lib/auto-approve.ts) and is unit-tested.

Why it exists

One-at-a-time intake is fine for a weekly upload; it's hopeless for agency-scale onboarding or mining a years-deep back catalogue. Bulk ingest makes "take this entire channel" a single operation on /sources/new → "Bulk ingest (backlog)", with two input modes:

Per-line outcomes

Every line gets its own verdict — created (with a package link), duplicate, invalid, or error. One bad line never sinks the batch. Each created source enqueues with the standard idempotency key (ingest:{sourceId}), so re-running a batch is safe.

Why it exists

A generic pipeline writes generic copy. A podcaster never wants "as you can see on screen…" in a post; a webinar brand cares about LinkedIn and article briefs far more than vertical clips; an agency client needs conservative, brand-safe phrasing by default. Verticals encode that fit once, per brand, instead of the operator correcting it in review forever.

The six presets

What a preset actually tunes

Each preset (catalogue in src/lib/verticals.ts, stored as brands.vertical) adjusts three things — all advisory, all overridable:

• Default processing profile — seeded at brand creation (e.g. Podcaster → fast_audio_only).
• Tone guidance — appended to every generation prompt for the brand: asset generation, script drafts, remixes.
• Asset fan-out shaping — skipAssetTypes are not generated at all; emphasizeAssetTypes enqueue at higher queue priority so the most relevant derivatives are ready first.

Brands without a vertical behave exactly as before — generic is still a valid choice.

Why it exists

Each package knows what it covers; nothing knew what the channel covers. After 50 videos, "have we done this topic? when? how hard?" was a memory exercise. Atlas indexes the topics[] and entities[] the pipeline already extracts per package into atlas_entries — zero additional LLM calls — and makes the whole catalogue queryable at /atlas.

What you can query

• Topics per brand — packages covered, cumulative weight, last covered, latest package link.
• Entities (person / product / company / concept) — mentions and the packages they appear in.

Coverage signals

Promote to idea

One click writes a ranked idea onto the Plan board (evidence.source = 'atlas_coverage_gap', provenance.model = 'atlas.v1'), closing the loop from catalogue knowledge back into pre-production. The Atlas isn't a report — it feeds the Idea Board.

Sync & backfill

Sync is automatic at the tail of analyze_intelligence (delete + insert per package, idempotent — Backlog Revival refreshes it too). To index a catalogue that predates v1.7, run the one-time backfill:

pnpm tsx scripts/backfill-atlas.ts