Product proof

The control layer builders stop rebuilding

Every serious AI app eventually needs the same things: who may call which model, what happens when it fails, where keys live, and how ops changes behavior without shipping new branching logic.

Restormel Keys is that layer—library-first, embedded in your app, not a separate traffic hop or model store. Below, two real products show the same primitives under different pressure—evidence of a reusable product, not two anecdotes.

What Keys actually is

A library-first control layer you embed in your app: routing, policy, fallbacks, BYOK boundaries, entitlements, and optional UI—without running Keys as your traffic proxy or model marketplace.

What this page proves

Two shipped products stress different constraints. The overlap is not coincidence: the same primitives (resolve, policy, allowlists, server-side keys) keep showing up because that is the product.

What Keys is for

Keys is not a generic AI gateway, observability suite, or marketplace. It is the builder-side slice: routing, policy, entitlements, cost awareness, embeddable key UX, and lightweight adoption paths—no Docker, Redis, or Postgres required to start.

Three valid ways to run it; most mature products end up in combined mode.

Builder-side routing

You choose providers, fallbacks, and guard rails from your backend using dashboard-owned configuration.

Used when You still call OpenAI, OpenRouter, or your stack directly—but “which model and path” is not hardcoded per handler.

End-user BYOK

End users bring provider keys; your app stores and validates them server-side while Keys enforces what they may run.

Used when Your SaaS must offer model choice without becoming a key vault product from scratch.

Combined mode

Platform defaults and user keys coexist: shared policy, shared allowlists, one resolve path.

Used when Operators need control while power users or tenants supply their own credentials.

Shared primitives

When you read PLOT and Sophia, watch for these names. They are the abstraction Keys sells: the same handles appear whether the workload is a single sensitive extraction or a multi-surface research engine.

  • Resolve One call path from model intent to executable provider context.
  • Policy Allow, deny, and scope before expensive or sensitive work runs.
  • Allowlists Live project rules that can drive both API behavior and picker UX.
  • Fallback chains Ordered backups when a provider or model fails—defined once, not per feature.
  • Key boundaries Raw keys never in client surfaces; prefixes and hashes for support.
  • Dashboard config Routes and policies change without redeploying handler branching.
  • Server-side credentials Gateway and control-plane tokens stay in your server environment.
  • Operator controls Admin paths reuse the same primitives as runtime—no shadow config.

How Keys sits inside your app

Keys runs in your process and talks to your database and env the way your code already does. The dashboard is configuration and visibility—not a mandatory proxy in front of user traffic.

  1. Your app UI Model pickers, settings, flows your users see.
  2. Your product logic Features, jobs, ingestion—your code owns the domain.
  3. Restormel Keys Embedded library + dashboard: routing, policy, BYOK contracts, entitlements.
  4. Provider access Direct APIs, gateways, or user-held keys—Keys does not replace these; it governs them.

Case · practical adoption

PLOT — Household Operating System

Privacy-first household finance: Vault document extraction where traceability and consent matter.

Environment
Next.js server routes; hosted policy evaluate + gateway auth.
Constraints
Household data, strict server-only credentials, minimal operational fuss.
Why Keys fit
Policy-driven extraction routing and fallbacks without nested provider branching in app code.

Extraction asks Keys which model path to use via policy (plot.vault.extraction). Primary and fallback routes are configured centrally; results carry routing metadata for audit without exposing secrets to the client.

Simplified flow: household UI and Vault surfaces call Next.js server routes, which use Keys for resolve, fallbacks, and server-side credentials before model providers.

What Keys handles here

  • Policy evaluate → chosen extraction route.
  • Automatic fallback when the primary model call fails.
  • Server-only gateway and control-plane credentials.

Reusable lesson

High-trust workflows benefit when routing and recovery are product configuration, not a growing pile of if statements next to business logic.

“We use Restormel Keys to keep model routing and fallback logic out of brittle app code. It gives us safer, policy-driven control for sensitive household document workflows.”

— Plotbudget team

Adoption note: docs + Restormel MCP in Cursor yielded a working routing/policy loop in one focused session (~30 minutes; your environment may differ).

Case · complexity & combined mode

Sophia — structured analysis & multi-pass reasoning

SvelteKit app: interactive analysis, ingestion pipelines, user BYOK, and operator surfaces—one control plane.

Environment
Multiple server routes (analyse, allowed-models, ingestion admin, beta AAIF).
Constraints
Multi-stage workloads, operator tuning, picker truth vs policy, combined builder + user keys.
Why Keys fit
One resolve and policy story across product and admin paths; allowlists that match real permissions.

Sophia is a deeper architecture, so the overall product took longer to build. Keys removed the worst part: bespoke routing and BYOK glue. Analysis, model availability, ingestion routing, and constrained beta APIs share the same Dashboard API and resolve patterns validated in smoke tests—so “how we configured it” and “what ran” stay aligned.

Simplified flow: multiple SvelteKit server routes share one Keys layer for resolve and policy, then reach platform keys, user BYOK, and providers—without duplicating routing logic per path.

What Keys handles here

  • Resolve across analysis and ingestion workloads.
  • Policy evaluation before expensive work; operator-clear errors when blocked.
  • Allowed-models merges BYOK availability with live project allowlists.

Reusable lesson

When the product has many surfaces, shared primitives beat parallel integrations—otherwise ops and runtime diverge and every new feature reimplements the same guard rails.

Patterns to take back to your codebase

These are the decisions teams usually reimplement badly. Keys encodes them as product behavior—so you ship features instead of another internal “model router v3.”

Dashboard-owned routing

Routes and steps live in configuration, not copy-pasted conditionals across handlers.

Prevents Silent drift between “what we intended” and what production branches actually do.

Fallback chains

Declare ordered backups when a call fails instead of bespoke retry blocks per endpoint.

Prevents Inconsistent recovery and opaque failures when a provider degrades.

Server-side key custody

Secrets stay on the server; the UI never displays full keys.

Prevents Accidental exposure and un-auditable key handling in client bundles.

Allowlists → policy + picker

One source of truth feeds enforcement and what users can select.

Prevents Users picking models your policy would reject after work already started.

Shared resolve primitives

Product APIs and operator tooling call the same resolve and policy surfaces.

Prevents “Staging said yes, prod did something else” configuration schizophrenia.

Policy before spend

Check limits and blocks before you burn tokens on long jobs.

Prevents Surprise cost and blocked work deep in a pipeline with no clear operator signal.

Take away the layer, not the story

You should leave this page understanding what to stop hand-rolling: routing tables in handlers, one-off retries, picker drift, and BYOK edge cases. Keys installs as a library, configures in the dashboard, and scales with your app—without making Restormel a mandatory traffic proxy.