A model is a row in a table, not a piece of code
Models change fast. That is why the application treats them as data: adding a new model is an administrative act, not a rebuild.
The application thinks in capabilities
Internally there is no "this is model X" but "takes character references, at most N" and "can edit with a mask". The screen adapts to that: choose a model that takes three references while the cast holds four characters and a warning with a proposal appears straight away. What a model does not know is not shown — a greyed-out button that does nothing is worse than no button.
What a model profile records
- Name, provider, model id and kind (image generation, image editing, video, text, vision).
- Capabilities: the number of character, object and style references and the available resolutions.
- Default settings, cost class and rate, and what the profile is suited for.
- Status: active, trial or retired, and the reference to the stored key of that provider.
- Terms: may the output be used commercially, is our input used to train the model, and what provenance marking does the provider put in the file.
Adjustable per brief
Model variant, quality level, reasoning level, number of variants, dimensions and aspect ratio, output format, seed (free, fixed or inherited), transparent background, the role of each reference image and the strength of an edit. Only what the chosen model actually knows.
Recipes
A recipe is a saved combination of project type, model profile, format, style profile and prompt template, under a name a human understands. Recipes are what let a new colleague produce usable work on day one without knowing the canon.
Failures are caught, not papered over
If a provider is unreachable or the filter refuses the image, the application says so with the real error message attached and offers to try another model profile. It never fails over automatically: another model is another picture, and that is a creative decision.