Providers & prompts

How the engine picks a model and renders a prompt.

GenFashion is not tied to one AI vendor. Models sit in a registry, and a router picks one per generation.

Quality is a gate, not a weight

A model enters the routable pool only by clearing a benchmark for that operation and garment category. Within the qualified pool, routing optimises cost and latency. Quality is never traded against cost — in virtual try-on, a subtly wrong rendering of someone's own face loses the customer silently.

If no model clears the gate, the request fails closed with PROVIDER_UNAVAILABLE. It never silently downgrades.

Two provider families

The second call in the LLM family resolves the garment to a phrase like

"a red plaid flannel shirt". That phrase is cached on the product, so every later generation against the same product drops back to one billed call.

Prompt layering

SYSTEM PROMPT       per provider × model — role, refusal posture, output contract
OPERATION TEMPLATE  per operation — the task and its constraints
RUNTIME VARIABLES   garment phrase, category, merchant tone, locale

The composition prompt states three non-negotiable constraints: preserve identity (face, hair, body shape, skin tone, pose), realistic fit (drape, lighting, shadows), and keep background. Those are the three classic failure modes of naive try-on prompting.

Versioning

Prompts are versioned artefacts. Every generation records system_prompt_version,

operation_template_version and a hash of the rendered text. To change a prompt you insert a new version and promote it — never edit an active one in place. Without that discipline a one-word edit silently regresses quality with nothing to attribute it to.

Browse the live versions under Prompts in the admin platform.