Introduce Metadata-Driven AI Deployment Features and Parameters

[MikeAlhayek]

Today, AI Deployments allow one or more Purposes to be assigned, enabling the system to select the appropriate deployment for different scenarios. However, deployments currently provide no metadata describing the capabilities and configurable parameters supported by the underlying model.

As AI providers continue to evolve, models within the same provider can expose different features, supported parameters, valid ranges, default values, and constraints. The application should not rely on hardcoded logic or model-name detection to determine what options are available.

Instead, AI Deployments should expose a metadata-driven definition describing what the selected model supports. This metadata should drive both the user experience and runtime behavior throughout the application.

Problem

Modern AI models are no longer interchangeable.

Examples include:

• GPT-5 models support Reasoning Effort, while GPT-4 models do not.
• Different models may expose different reasoning levels.
• Some models support configurable Verbosity, while others do not.
• Temperature ranges may differ between models.
• Some models may not support Temperature at all.
• Future providers will introduce provider-specific capabilities and parameters.

Today, supporting these differences would require hardcoded checks throughout the application, making the system increasingly difficult to maintain as providers evolve.

Proposed Solution

Replace the concept of simple deployment capabilities with a richer metadata-driven feature system.

An AI Deployment should describe the capabilities and configurable parameters supported by its underlying model. This metadata becomes the contract between the deployment and the rest of the application.

Rather than asking:

Does this deployment support Reasoning?

The application should ask:

What features and configurable parameters does this deployment expose?

The UI, validation, and runtime request generation should all be driven from this metadata.

Model Features

Model Features describe functionality the model can perform.

Examples include:

• Chat
• Vision
• Image Generation
• Audio Input
• Audio Output
• Tool Calling
• Structured Outputs
• Streaming
• Embeddings
• Computer Use

These are generally binary (supported or not supported), although future features may include additional metadata.

Model Parameters

Model Parameters describe configurable options that influence model behavior.

Examples include:

• Reasoning Effort
• Temperature
• Top P
• Max Output Tokens
• Verbosity
• Seed
• Presence Penalty
• Frequency Penalty

Unlike simple capability flags, parameters contain metadata describing how they should behave.

Example metadata may include:

• Supported
• Default Value
• Minimum Value
• Maximum Value
• Allowed Values
• Step Size
• Validation Rules

For example:

Reasoning Effort

• Supported: Yes

• Allowed Values:

  • Minimal
  • Low
  • Medium
  • High

• Default: Medium

Temperature

• Supported: Yes
• Minimum: 0
• Maximum: 2
• Step: 0.1
• Default: 1.0

This allows each deployment to accurately describe the behavior of its underlying model.

Metadata-Driven UI

Application editors should no longer contain hardcoded logic for specific models.

Instead, they should:

1. Read the selected deployment's metadata.
2. Discover the supported features and parameters.
3. Dynamically render the appropriate controls.
4. Validate user input using the supplied metadata.

For example:

• A parameter with allowed values renders as a dropdown.
• A numeric range renders as a slider or numeric input.
• A boolean renders as a checkbox.
• Unsupported parameters are not displayed.

The UI becomes entirely driven by deployment metadata rather than provider-specific logic.

Orchard Core Extensibility

This implementation should align with Orchard Core's extensibility model.

Rather than introducing a large monolithic settings class, parameter and feature definitions should be extensible so that modules can contribute new definitions without modifying the core framework.

For example:

• OpenAI module registers:

  • Reasoning Effort
  • Verbosity

• Anthropic module registers provider-specific parameters.

• Future providers register additional features as they become available.

AI Deployments then describe which registered features and parameters they support and provide any required metadata.

This allows providers to evolve independently while keeping the core framework provider-agnostic.

Initial Implementation

The first parameter implemented should be Reasoning Effort.

When a deployment exposes this parameter:

• AI Profile editor displays a Reasoning Effort dropdown.
• AI Profile Templates display the same configuration.
• Chat Interaction UI displays the same configuration.
• Runtime requests include the selected reasoning effort.

When the deployment does not expose the parameter:

• The Reasoning Effort editor is hidden.
• No reasoning effort value is sent to the provider.

This serves as the first implementation of the metadata-driven parameter system.

Benefits

• Eliminates hardcoded model-specific UI logic.
• Allows deployments to accurately describe supported functionality.
• Enables automatic UI generation from deployment metadata.
• Supports provider-specific capabilities without changing the core framework.
• Makes future AI model features significantly easier to add.
• Keeps the framework provider-agnostic.
• Aligns with Orchard Core's extensibility philosophy.

Acceptance Criteria

• Introduce a metadata-driven feature system for AI Deployments.
• Distinguish between Model Features (capabilities) and Model Parameters (configurable options).
• Allow parameter definitions to expose metadata such as supported values, ranges, defaults, and validation rules.
• Render AI Profile, AI Profile Template, and Chat Interaction editors dynamically based on deployment metadata.
• Implement Reasoning Effort as the first model parameter using the new framework.
• Ensure unsupported parameters are never displayed or sent to providers.
• Design the system so new providers and modules can contribute additional features and parameters without modifying existing UI or runtime logic.