Provider abstraction¶
Providers are selected by role and capability, not by hard-coded vendor logic.
How are model providers controlled?¶
Asset Factory selects providers by declared role and capability, then treats every model response as proposal material. Provider policy controls lanes, credentials and fallback behaviour; schemas and deterministic repository gates retain authority over durable state. This keeps vendor-specific clients replaceable without allowing a model to promote its own output.
Provider authority¶
Models may generate proposals, classify evidence, draft texture prompts or summarise stage records. Provider selection remains replaceable and repository governance retains validation authority. Credentials are configured through the environment reference, while isolated backend processes follow the external model runner contract.
Lanes¶
nvidia_nimopenaiopenai_compatiblelocallocal_fluxhf_flux_schnell
Roles¶
Role defaults in configs/provider-policy.json cover planner, vision_reasoner, material_reasoner, texture_prompt_writer, nonvisual_material_reasoner, physics_reasoner, validator_judge, embeddings, image_generation, texture_generator and external_model_runner.
Logged fields¶
- provider name
- kind
- model env name
- base URL host
- prompt checksum
- role
- request ID when available
Raw API keys, bearer tokens and signed URLs are not logged.
Proposal policy¶
Provider outputs are written as proposal artefacts in durable manifest records. Promotion requires deterministic validation or reviewer approval.
Request flow¶
- Resolve provider role from
configs/provider-policy.json. - Build the provider request from a prompt and stage context.
- Store the redacted request and response metadata.
- Write provider output as a proposal artefact.
- Let the stage validator decide whether it can be promoted.