Expand description
Data structures used by operation inputs/outputs.
Modules§
Structs§
- Account
Enforced Guardrail Inference Input Configuration Account-level enforced guardrail input configuration.
- Account
Enforced Guardrail Output Configuration Account enforced guardrail output configuration.
- Agreement
Availability Information about the agreement availability
- Automated
Evaluation Config The configuration details of an automated evaluation job. The
EvaluationDatasetMetricConfigobject is used to specify the prompt datasets, task type, and metric names.- Automated
Evaluation Custom Metric Config Defines the configuration of custom metrics to be used in an evaluation job. To learn more about using custom metrics in Amazon Bedrock evaluation jobs, see Create a prompt for a custom metrics (LLM-as-a-judge model evaluations) and Create a prompt for a custom metrics (RAG evaluations).
- Automated
Reasoning Check Impossible Finding Indicates that no valid claims can be made due to logical contradictions in the premises or rules.
- Automated
Reasoning Check Input Text Reference References a portion of the original input text that corresponds to logical elements.
- Automated
Reasoning Check Invalid Finding Indicates that the claims are logically false and contradictory to the established rules or premises.
- Automated
Reasoning Check Logic Warning Identifies logical issues in the translated statements that exist independent of any policy rules, such as statements that are always true or always false.
- Automated
Reasoning Check NoTranslations Finding Indicates that no relevant logical information could be extracted from the input for validation.
- Automated
Reasoning Check Rule References a specific automated reasoning policy rule that was applied during evaluation.
- Automated
Reasoning Check Satisfiable Finding Indicates that the claims could be either true or false depending on additional assumptions not provided in the input.
- Automated
Reasoning Check Scenario Represents a logical scenario where claims can be evaluated as true or false, containing specific logical assignments.
- Automated
Reasoning Check TooComplex Finding Indicates that the input exceeds the processing capacity due to the volume or complexity of the logical information.
- Automated
Reasoning Check Translation Contains the logical translation of natural language input into formal logical statements, including premises, claims, and confidence scores.
- Automated
Reasoning Check Translation Ambiguous Finding Indicates that the input has multiple valid logical interpretations, requiring additional context or clarification.
- Automated
Reasoning Check Translation Option Represents one possible logical interpretation of ambiguous input content.
- Automated
Reasoning Check Valid Finding Indicates that the claims are definitively true and logically implied by the premises, with no possible alternative interpretations.
- Automated
Reasoning Logic Statement Represents a logical statement that can be expressed both in formal logic notation and natural language, providing dual representations for better understanding and validation.
- Automated
Reasoning Policy AddRule Annotation An annotation for adding a new rule to an Automated Reasoning policy using a formal logical expression.
- Automated
Reasoning Policy AddRule From Natural Language Annotation An annotation for adding a new rule to the policy by converting a natural language description into a formal logical expression.
- Automated
Reasoning Policy AddRule Mutation A mutation operation that adds a new rule to the policy definition during the build process.
- Automated
Reasoning Policy AddType Annotation An annotation for adding a new custom type to an Automated Reasoning policy, defining a set of possible values for variables.
- Automated
Reasoning Policy AddType Mutation A mutation operation that adds a new custom type to the policy definition during the build process.
- Automated
Reasoning Policy AddType Value Represents a single value that can be added to an existing custom type in the policy.
- Automated
Reasoning Policy AddVariable Annotation An annotation for adding a new variable to an Automated Reasoning policy, which can be used in rule expressions.
- Automated
Reasoning Policy AddVariable Mutation A mutation operation that adds a new variable to the policy definition during the build process.
- Automated
Reasoning Policy Build Log Contains detailed logging information about the policy build process, including steps taken, decisions made, and any issues encountered.
- Automated
Reasoning Policy Build LogEntry Represents a single entry in the policy build log, containing information about a specific step or event in the build process.
- Automated
Reasoning Policy Build Step Represents a single step in the policy build process, containing context about what was being processed and any messages or results.
- Automated
Reasoning Policy Build Step Message Represents a message generated during a build step, providing information about what happened or any issues encountered.
- Automated
Reasoning Policy Build Workflow Document Represents a source document used in the policy build workflow, containing the content and metadata needed for policy generation.
- Automated
Reasoning Policy Build Workflow Repair Content Contains content and instructions for repairing or improving an existing Automated Reasoning policy.
- Automated
Reasoning Policy Build Workflow Source Defines the source content for a policy build workflow, which can include documents, repair instructions, or other input materials.
- Automated
Reasoning Policy Build Workflow Summary Provides a summary of a policy build workflow, including its current status, timing information, and key identifiers.
- Automated
Reasoning Policy Definition Contains the formal logic rules, variables, and custom variable types that define an Automated Reasoning policy. The policy definition specifies the constraints used to validate foundation model responses for accuracy and logical consistency.
- Automated
Reasoning Policy Definition Quality Report Provides a comprehensive analysis of the quality and completeness of an Automated Reasoning policy definition, highlighting potential issues and optimization opportunities.
- Automated
Reasoning Policy Definition Rule Represents a formal logic rule in an Automated Reasoning policy. For example, rules can be expressed as if-then statements that define logical constraints.
- Automated
Reasoning Policy Definition Type Represents a custom user-defined viarble type in an Automated Reasoning policy. Types are enum-based and provide additional context beyond predefined variable types.
- Automated
Reasoning Policy Definition Type Value Represents a single value within a custom type definition, including its identifier and description.
- Automated
Reasoning Policy Definition Type Value Pair Associates a type name with a specific value name, used for referencing type values in rules and other policy elements.
- Automated
Reasoning Policy Definition Variable Represents a variable in an Automated Reasoning policy. Variables represent concepts that can have values assigned during natural language translation.
- Automated
Reasoning Policy Delete Rule Annotation An annotation for removing a rule from an Automated Reasoning policy.
- Automated
Reasoning Policy Delete Rule Mutation A mutation operation that removes a rule from the policy definition during the build process.
- Automated
Reasoning Policy Delete Type Annotation An annotation for removing a custom type from an Automated Reasoning policy.
- Automated
Reasoning Policy Delete Type Mutation A mutation operation that removes a custom type from the policy definition during the build process.
- Automated
Reasoning Policy Delete Type Value Represents a value to be removed from an existing custom type in the policy.
- Automated
Reasoning Policy Delete Variable Annotation An annotation for removing a variable from an Automated Reasoning policy.
- Automated
Reasoning Policy Delete Variable Mutation A mutation operation that removes a variable from the policy definition during the build process.
- Automated
Reasoning Policy Disjoint Rule Set Represents a set of rules that operate on completely separate variables, indicating they address different concerns or domains within the policy.
- Automated
Reasoning Policy Generated Test Case Represents a generated test case, consisting of query content, guard content, and expected results.
- Automated
Reasoning Policy Generated Test Cases Contains a comprehensive test suite generated by the build workflow, providing validation capabilities for automated reasoning policies.
- Automated
Reasoning Policy Ingest Content Annotation An annotation for processing and incorporating new content into an Automated Reasoning policy.
- Automated
Reasoning Policy Planning Represents the planning phase of policy build workflow, where the system analyzes source content and determines what operations to perform.
- Automated
Reasoning Policy Scenario Represents a test scenario used to validate an Automated Reasoning policy, including the test conditions and expected outcomes.
- Automated
Reasoning Policy Summary Contains summary information about an Automated Reasoning policy, including metadata and timestamps.
- Automated
Reasoning Policy Test Case Represents a test for validating an Automated Reasoning policy. tests contain sample inputs and expected outcomes to verify policy behavior.
- Automated
Reasoning Policy Test Result Contains the results of testing an Automated Reasoning policy against various scenarios and validation checks.
- Automated
Reasoning Policy Update From Rule Feedback Annotation An annotation for updating the policy based on feedback about how specific rules performed during testing or real-world usage.
- Automated
Reasoning Policy Update From Scenario Feedback Annotation An annotation for updating the policy based on feedback about how it performed on specific test scenarios.
- Automated
Reasoning Policy Update Rule Annotation An annotation for modifying an existing rule in an Automated Reasoning policy.
- Automated
Reasoning Policy Update Rule Mutation A mutation operation that modifies an existing rule in the policy definition during the build process.
- Automated
Reasoning Policy Update Type Annotation An annotation for modifying an existing custom type in an Automated Reasoning policy.
- Automated
Reasoning Policy Update Type Mutation A mutation operation that modifies an existing custom type in the policy definition during the build process.
- Automated
Reasoning Policy Update Type Value Represents a modification to a value within an existing custom type.
- Automated
Reasoning Policy Update Variable Annotation An annotation for modifying an existing variable in an Automated Reasoning policy.
- Automated
Reasoning Policy Update Variable Mutation A mutation operation that modifies an existing variable in the policy definition during the build process.
- Batch
Delete Evaluation JobError A JSON array that provides the status of the evaluation jobs being deleted.
- Batch
Delete Evaluation JobItem An evaluation job for deletion, and it’s current status.
- Bedrock
Evaluator Model The evaluator model used in knowledge base evaluation job or in model evaluation job that use a model as judge. This model computes all evaluation related metrics.
- Byte
Content Doc Contains the document contained in the wrapper object, along with its attributes/fields.
- Cloud
Watch Config CloudWatch logging configuration.
- Custom
Metric Bedrock Evaluator Model Defines the model you want to evaluate custom metrics in an Amazon Bedrock evaluation job.
- Custom
Metric Definition The definition of a custom metric for use in an Amazon Bedrock evaluation job. A custom metric definition includes a metric name, prompt (instructions) and optionally, a rating scale. Your prompt must include a task description and input variables. The required input variables are different for model-as-a-judge and RAG evaluations.
For more information about how to define a custom metric in Amazon Bedrock, see Create a prompt for a custom metrics (LLM-as-a-judge model evaluations) and Create a prompt for a custom metrics (RAG evaluations).
- Custom
Metric Evaluator Model Config Configuration of the evaluator model you want to use to evaluate custom metrics in an Amazon Bedrock evaluation job.
- Custom
Model Deployment Summary Contains summary information about a custom model deployment, including its ARN, name, status, and associated custom model.
- Custom
Model Deployment Update Details Details about an update to a custom model deployment, including the new custom model resource ARN and current update status.
- Custom
Model Summary Summary information for a custom model.
- Custom
Model Units A
CustomModelUnit(CMU) is an abstract view of the hardware utilization that Amazon Bedrock needs to host a single copy of your custom model. A model copy represents a single instance of your imported model that is ready to serve inference requests. Amazon Bedrock determines the number of custom model units that a model copy needs when you import the custom model.You can use
CustomModelUnitsto estimate the cost of running your custom model. For more information, see Calculate the cost of running a custom model in the Amazon Bedrock user guide.- Data
Processing Details For a Distillation job, the status details for the data processing sub-task of the job.
- Dimensional
Price Rate Dimensional price rate.
- Distillation
Config Settings for distilling a foundation model into a smaller and more efficient model.
- Evaluation
Bedrock Model Contains the ARN of the Amazon Bedrock model or inference profile specified in your evaluation job. Each Amazon Bedrock model supports different
inferenceParams. To learn more about supported inference parameters for Amazon Bedrock models, see Inference parameters for foundation models.The
inferenceParamsare specified using JSON. To successfully insert JSON as string make sure that all quotations are properly escaped. For example,"temperature":"0.25"key value pair would need to be formatted as\"temperature\":\"0.25\"to successfully accepted in the request.- Evaluation
Dataset Used to specify the name of a built-in prompt dataset and optionally, the Amazon S3 bucket where a custom prompt dataset is saved.
- Evaluation
Dataset Metric Config Defines the prompt datasets, built-in metric names and custom metric names, and the task type.
- Evaluation
Inference Config Summary Identifies the models, Knowledge Bases, or other RAG sources evaluated in a model or Knowledge Base evaluation job.
- Evaluation
Model Config Summary A summary of the models used in an Amazon Bedrock model evaluation job. These resources can be models in Amazon Bedrock or models outside of Amazon Bedrock that you use to generate your own inference response data.
- Evaluation
Output Data Config The Amazon S3 location where the results of your evaluation job are saved.
- Evaluation
Precomputed Inference Source A summary of a model used for a model evaluation job where you provide your own inference response data.
- Evaluation
Precomputed Retrieve AndGenerate Source Config A summary of a RAG source used for a retrieve-and-generate Knowledge Base evaluation job where you provide your own inference response data.
- Evaluation
Precomputed Retrieve Source Config A summary of a RAG source used for a retrieve-only Knowledge Base evaluation job where you provide your own inference response data.
- Evaluation
RagConfig Summary A summary of the RAG resources used in an Amazon Bedrock Knowledge Base evaluation job. These resources can be Knowledge Bases in Amazon Bedrock or RAG sources outside of Amazon Bedrock that you use to generate your own inference response data.
- Evaluation
Summary Summary information of an evaluation job.
- External
Source The unique external source of the content contained in the wrapper object.
- External
Sources Generation Configuration The response generation configuration of the external source wrapper object.
- External
Sources Retrieve AndGenerate Configuration The configuration of the external source wrapper object in the
retrieveAndGeneratefunction.- Field
ForReranking Specifies a field to be used during the reranking process in a Knowledge Base vector search. This structure identifies metadata fields that should be considered when reordering search results to improve relevance.
- Filter
Attribute Specifies the name of the metadata attribute/field to apply filters. You must match the name of the attribute/field in your data source/document metadata.
- Foundation
Model Details Information about a foundation model.
- Foundation
Model Lifecycle Details about whether a model version is available or deprecated.
- Foundation
Model Summary Summary information for a foundation model.
- Generation
Configuration The configuration details for response generation based on retrieved text chunks.
- Guardrail
Automated Reasoning Policy Represents the configuration of Automated Reasoning policies within a Amazon Bedrock Guardrail, including the policies to apply and confidence thresholds.
- Guardrail
Automated Reasoning Policy Config Configuration settings for integrating Automated Reasoning policies with Amazon Bedrock Guardrails.
- Guardrail
Configuration The configuration details for the guardrail.
- Guardrail
Content Filter Contains filter strengths for harmful content. Guardrails support the following content filters to detect and filter harmful user inputs and FM-generated outputs.
-
Hate – Describes language or a statement that discriminates, criticizes, insults, denounces, or dehumanizes a person or group on the basis of an identity (such as race, ethnicity, gender, religion, sexual orientation, ability, and national origin).
-
Insults – Describes language or a statement that includes demeaning, humiliating, mocking, insulting, or belittling language. This type of language is also labeled as bullying.
-
Sexual – Describes language or a statement that indicates sexual interest, activity, or arousal using direct or indirect references to body parts, physical traits, or sex.
-
Violence – Describes language or a statement that includes glorification of or threats to inflict physical pain, hurt, or injury toward a person, group or thing.
Content filtering depends on the confidence classification of user inputs and FM responses across each of the four harmful categories. All input and output statements are classified into one of four confidence levels (NONE, LOW, MEDIUM, HIGH) for each harmful category. For example, if a statement is classified as Hate with HIGH confidence, the likelihood of the statement representing hateful content is high. A single statement can be classified across multiple categories with varying confidence levels. For example, a single statement can be classified as Hate with HIGH confidence, Insults with LOW confidence, Sexual with NONE confidence, and Violence with MEDIUM confidence.
For more information, see Guardrails content filters.
This data type is used in the following API operations:
-
- Guardrail
Content Filter Config Contains filter strengths for harmful content. Guardrails support the following content filters to detect and filter harmful user inputs and FM-generated outputs.
-
Hate – Describes language or a statement that discriminates, criticizes, insults, denounces, or dehumanizes a person or group on the basis of an identity (such as race, ethnicity, gender, religion, sexual orientation, ability, and national origin).
-
Insults – Describes language or a statement that includes demeaning, humiliating, mocking, insulting, or belittling language. This type of language is also labeled as bullying.
-
Sexual – Describes language or a statement that indicates sexual interest, activity, or arousal using direct or indirect references to body parts, physical traits, or sex.
-
Violence – Describes language or a statement that includes glorification of or threats to inflict physical pain, hurt, or injury toward a person, group or thing.
Content filtering depends on the confidence classification of user inputs and FM responses across each of the four harmful categories. All input and output statements are classified into one of four confidence levels (NONE, LOW, MEDIUM, HIGH) for each harmful category. For example, if a statement is classified as Hate with HIGH confidence, the likelihood of the statement representing hateful content is high. A single statement can be classified across multiple categories with varying confidence levels. For example, a single statement can be classified as Hate with HIGH confidence, Insults with LOW confidence, Sexual with NONE confidence, and Violence with MEDIUM confidence.
For more information, see Guardrails content filters.
-
- Guardrail
Content Filters Tier The tier that your guardrail uses for content filters.
- Guardrail
Content Filters Tier Config The tier that your guardrail uses for content filters. Consider using a tier that balances performance, accuracy, and compatibility with your existing generative AI workflows.
- Guardrail
Content Policy Contains details about how to handle harmful content.
This data type is used in the following API operations:
- Guardrail
Content Policy Config Contains details about how to handle harmful content.
- Guardrail
Contextual Grounding Filter The details for the guardrails contextual grounding filter.
- Guardrail
Contextual Grounding Filter Config The filter configuration details for the guardrails contextual grounding filter.
- Guardrail
Contextual Grounding Policy The details for the guardrails contextual grounding policy.
- Guardrail
Contextual Grounding Policy Config The policy configuration details for the guardrails contextual grounding policy.
- Guardrail
Cross Region Config The system-defined guardrail profile that you're using with your guardrail. Guardrail profiles define the destination Amazon Web Services Regions where guardrail inference requests can be automatically routed. Using guardrail profiles helps maintain guardrail performance and reliability when demand increases.
For more information, see the Amazon Bedrock User Guide.
- Guardrail
Cross Region Details Contains details about the system-defined guardrail profile that you're using with your guardrail for cross-Region inference.
For more information, see the Amazon Bedrock User Guide.
- Guardrail
Managed Words The managed word list that was configured for the guardrail. (This is a list of words that are pre-defined and managed by guardrails only.)
- Guardrail
Managed Words Config The managed word list to configure for the guardrail.
- Guardrail
PiiEntity The PII entity configured for the guardrail.
- Guardrail
PiiEntity Config The PII entity to configure for the guardrail.
- Guardrail
Regex The regular expression configured for the guardrail.
- Guardrail
Regex Config The regular expression to configure for the guardrail.
- Guardrail
Sensitive Information Policy Contains details about PII entities and regular expressions configured for the guardrail.
- Guardrail
Sensitive Information Policy Config Contains details about PII entities and regular expressions to configure for the guardrail.
- Guardrail
Summary Contains details about a guardrail.
This data type is used in the following API operations:
- Guardrail
Topic Details about topics for the guardrail to identify and deny.
This data type is used in the following API operations:
- Guardrail
Topic Config Details about topics for the guardrail to identify and deny.
- Guardrail
Topic Policy Contains details about topics that the guardrail should identify and deny.
This data type is used in the following API operations:
- Guardrail
Topic Policy Config Contains details about topics that the guardrail should identify and deny.
- Guardrail
Topics Tier The tier that your guardrail uses for denied topic filters.
- Guardrail
Topics Tier Config The tier that your guardrail uses for denied topic filters. Consider using a tier that balances performance, accuracy, and compatibility with your existing generative AI workflows.
- Guardrail
Word A word configured for the guardrail.
- Guardrail
Word Config A word to configure for the guardrail.
- Guardrail
Word Policy Contains details about the word policy configured for the guardrail.
- Guardrail
Word Policy Config Contains details about the word policy to configured for the guardrail.
- Human
Evaluation Config Specifies the custom metrics, how tasks will be rated, the flow definition ARN, and your custom prompt datasets. Model evaluation jobs use human workers only support the use of custom prompt datasets. To learn more about custom prompt datasets and the required format, see Custom prompt datasets.
When you create custom metrics in
HumanEvaluationCustomMetricyou must specify the metric'sname. The list ofnamesspecified in theHumanEvaluationCustomMetricarray, must match themetricNamesarray of strings specified inEvaluationDatasetMetricConfig. For example, if in theHumanEvaluationCustomMetricarray your specified the names"accuracy", "toxicity", "readability"as custom metrics then themetricNamesarray would need to look like the following\["accuracy", "toxicity", "readability"\]inEvaluationDatasetMetricConfig.- Human
Evaluation Custom Metric In a model evaluation job that uses human workers you must define the name of the metric, and how you want that metric rated
ratingMethod, and an optional description of the metric.- Human
Workflow Config Contains
SageMakerFlowDefinitionobject. The object is used to specify the prompt dataset, task type, rating method and metric names.- Implicit
Filter Configuration Configuration for implicit filtering in Knowledge Base vector searches. Implicit filtering allows you to automatically filter search results based on metadata attributes without requiring explicit filter expressions in each query.
- Imported
Model Summary Information about the imported model.
- Inference
Profile Model Contains information about a model.
- Inference
Profile Summary Contains information about an inference profile.
- Invocation
Logs Config Settings for using invocation logs to customize a model.
- KbInference
Config Contains configuration details of the inference for knowledge base retrieval and response generation.
- Knowledge
Base Retrieval Configuration Contains configuration details for retrieving information from a knowledge base.
- Knowledge
Base Retrieve AndGenerate Configuration Contains configuration details for retrieving information from a knowledge base and generating responses.
- Knowledge
Base Vector Search Configuration The configuration details for returning the results from the knowledge base vector search.
- Lambda
Grader Config Configuration for using an AWS Lambda function to grade model responses during reinforcement fine-tuning training.
- Legal
Term The legal term of the agreement.
- Logging
Config Configuration fields for invocation logging.
- Marketplace
Model Endpoint Contains details about an endpoint for a model from Amazon Bedrock Marketplace.
- Marketplace
Model Endpoint Summary Provides a summary of an endpoint for a model from Amazon Bedrock Marketplace.
- Metadata
Attribute Schema Defines the schema for a metadata attribute used in Knowledge Base vector searches. Metadata attributes provide additional context for documents and can be used for filtering and reranking search results.
- Metadata
Configuration ForReranking Configuration for how metadata should be used during the reranking process in Knowledge Base vector searches. This determines which metadata fields are included or excluded when reordering search results.
- Model
Copy JobSummary Contains details about each model copy job.
This data type is used in the following API operations:
- Model
Customization JobSummary Information about one customization job
- Model
Import JobSummary Information about the import job.
- Model
Invocation JobS3 Input Data Config Contains the configuration of the S3 location of the input data.
- Model
Invocation JobS3 Output Data Config Contains the configuration of the S3 location of the output data.
- Model
Invocation JobSummary A summary of a batch inference job.
- Offer
An offer dictates usage terms for the model.
- Orchestration
Configuration The configuration details for the model to process the prompt prior to retrieval and response generation.
- Output
Data Config S3 Location of the output data.
- Performance
Configuration Contains performance settings for a model.
- Pricing
Term Describes the usage-based pricing term.
- Prompt
Router Summary Details about a prompt router.
- Prompt
Router Target Model The target model for a prompt router.
- Prompt
Template The template for the prompt that's sent to the model for response generation.
- Provisioned
Model Summary A summary of information about a Provisioned Throughput.
This data type is used in the following API operations:
- Query
Transformation Configuration The configuration details for transforming the prompt.
- Rating
Scale Item Defines the value and corresponding definition for one rating in a custom metric rating scale.
- Request
Metadata Base Filters A mapping of a metadata key to a value that it should or should not equal.
- Retrieve
AndGenerate Configuration Contains configuration details for a knowledge base retrieval and response generation.
- Retrieve
Config The configuration details for retrieving information from a knowledge base.
- RftConfig
Configuration settings for reinforcement fine-tuning (RFT), including grader configuration and training hyperparameters.
- RftHyper
Parameters Hyperparameters for controlling the reinforcement fine-tuning training process, including learning settings and evaluation intervals.
- Routing
Criteria Routing criteria for a prompt router.
- S3Config
S3 configuration for storing log data.
- S3Data
Source The Amazon S3 data source of the model to import.
- S3Object
Doc The unique wrapper object of the document from the S3 location.
- Sage
Maker Endpoint Specifies the configuration for a Amazon SageMaker endpoint.
- Status
Details For a Distillation job, the status details for sub-tasks of the job. Possible statuses for each sub-task include the following:
-
NotStarted
-
InProgress
-
Completed
-
Stopping
-
Stopped
-
Failed
-
- Support
Term Describes a support term.
- Tag
Definition of the key/value pair for a tag.
- Teacher
Model Config Details about a teacher model used for model customization.
- Term
Details Describes the usage terms of an offer.
- Text
Inference Config The configuration details for text generation using a language model via the
RetrieveAndGeneratefunction.- Training
Data Config S3 Location of the training data.
- Training
Details For a Distillation job, the status details for the training sub-task of the job.
- Training
Metrics Metrics associated with the custom job.
- Validation
Data Config Array of up to 10 validators.
- Validation
Details For a Distillation job, the status details for the validation sub-task of the job.
- Validator
Information about a validator.
- Validator
Metric The metric for the validator.
- Validity
Term Describes the validity terms.
- Vector
Search Bedrock Reranking Configuration Configuration for using Amazon Bedrock foundation models to rerank Knowledge Base vector search results. This enables more sophisticated relevance ranking using large language models.
- Vector
Search Bedrock Reranking Model Configuration Configuration for the Amazon Bedrock foundation model used for reranking vector search results. This specifies which model to use and any additional parameters required by the model.
- Vector
Search Reranking Configuration Configuration for reranking vector search results to improve relevance. Reranking applies additional relevance models to reorder the initial vector search results based on more sophisticated criteria.
- VpcConfig
The configuration of a virtual private cloud (VPC). For more information, see Protect your data using Amazon Virtual Private Cloud and Amazon Web Services PrivateLink.
Enums§
- Agreement
Status - When writing a match expression against
AgreementStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Application
Type - When writing a match expression against
ApplicationType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Attribute
Type - When writing a match expression against
AttributeType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Authorization
Status - When writing a match expression against
AuthorizationStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Automated
Evaluation Custom Metric Source An array item definining a single custom metric for use in an Amazon Bedrock evaluation job.
- Automated
Reasoning Check Finding Represents the result of an Automated Reasoning validation check, indicating whether the content is logically valid, invalid, or falls into other categories based on the policy rules.
- Automated
Reasoning Check Logic Warning Type - When writing a match expression against
AutomatedReasoningCheckLogicWarningType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Automated
Reasoning Check Result - When writing a match expression against
AutomatedReasoningCheckResult, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Automated
Reasoning Policy Annotation Contains the various operations that can be performed on an Automated Reasoning policy, including adding, updating, and deleting rules, variables, and types.
- Automated
Reasoning Policy Annotation Status - When writing a match expression against
AutomatedReasoningPolicyAnnotationStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Automated
Reasoning Policy Build Document Content Type - When writing a match expression against
AutomatedReasoningPolicyBuildDocumentContentType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Automated
Reasoning Policy Build Message Type - When writing a match expression against
AutomatedReasoningPolicyBuildMessageType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Automated
Reasoning Policy Build Result Asset Type - When writing a match expression against
AutomatedReasoningPolicyBuildResultAssetType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Automated
Reasoning Policy Build Result Assets Contains the various assets generated during a policy build workflow, including logs, quality reports, test cases, and the final policy definition.
- Automated
Reasoning Policy Build Step Context Provides context about what type of operation was being performed during a build step.
- Automated
Reasoning Policy Build Workflow Status - When writing a match expression against
AutomatedReasoningPolicyBuildWorkflowStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Automated
Reasoning Policy Build Workflow Type - When writing a match expression against
AutomatedReasoningPolicyBuildWorkflowType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Automated
Reasoning Policy Definition Element Represents a single element in an Automated Reasoning policy definition, such as a rule, variable, or type definition.
- Automated
Reasoning Policy Mutation A container for various mutation operations that can be applied to an Automated Reasoning policy, including adding, updating, and deleting policy elements.
- Automated
Reasoning Policy Test RunResult - When writing a match expression against
AutomatedReasoningPolicyTestRunResult, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Automated
Reasoning Policy Test RunStatus - When writing a match expression against
AutomatedReasoningPolicyTestRunStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Automated
Reasoning Policy Type Value Annotation An annotation for managing values within custom types, including adding, updating, or removing specific type values.
- Automated
Reasoning Policy Workflow Type Content Defines the content and configuration for different types of policy build workflows.
- Commitment
Duration - When writing a match expression against
CommitmentDuration, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Configuration
Owner - When writing a match expression against
ConfigurationOwner, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Custom
Model Deployment Status - When writing a match expression against
CustomModelDeploymentStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Custom
Model Deployment Update Status - When writing a match expression against
CustomModelDeploymentUpdateStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Customization
Config A model customization configuration
- Customization
Type - When writing a match expression against
CustomizationType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Endpoint
Config Specifies the configuration for the endpoint.
- Entitlement
Availability - When writing a match expression against
EntitlementAvailability, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Evaluation
Config The configuration details of either an automated or human-based evaluation job.
- Evaluation
Dataset Location The location in Amazon S3 where your prompt dataset is stored.
- Evaluation
Inference Config The configuration details of the inference model for an evaluation job.
For automated model evaluation jobs, only a single model is supported.
For human-based model evaluation jobs, your annotator can compare the responses for up to two different models.
- Evaluation
JobStatus - When writing a match expression against
EvaluationJobStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Evaluation
JobType - When writing a match expression against
EvaluationJobType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Evaluation
Model Config Defines the models used in the model evaluation job.
- Evaluation
Precomputed RagSource Config A summary of a RAG source used for a Knowledge Base evaluation job where you provide your own inference response data.
- Evaluation
Task Type - When writing a match expression against
EvaluationTaskType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Evaluator
Model Config Specifies the model configuration for the evaluator model.
EvaluatorModelConfigis required for evaluation jobs that use a knowledge base or in model evaluation job that use a model as judge. This model computes all evaluation related metrics.- External
Source Type - When writing a match expression against
ExternalSourceType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Fine
Tuning JobStatus - When writing a match expression against
FineTuningJobStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Foundation
Model Lifecycle Status - When writing a match expression against
FoundationModelLifecycleStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Grader
Config Configuration for the grader used in reinforcement fine-tuning to evaluate model responses and provide reward signals.
- Guardrail
Content Filter Action - When writing a match expression against
GuardrailContentFilterAction, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Content Filter Type - When writing a match expression against
GuardrailContentFilterType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Content Filters Tier Name - When writing a match expression against
GuardrailContentFiltersTierName, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Contextual Grounding Action - When writing a match expression against
GuardrailContextualGroundingAction, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Contextual Grounding Filter Type - When writing a match expression against
GuardrailContextualGroundingFilterType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Filter Strength - When writing a match expression against
GuardrailFilterStrength, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Managed Words Type - When writing a match expression against
GuardrailManagedWordsType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Modality - When writing a match expression against
GuardrailModality, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
PiiEntity Type - When writing a match expression against
GuardrailPiiEntityType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Sensitive Information Action - When writing a match expression against
GuardrailSensitiveInformationAction, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Status - When writing a match expression against
GuardrailStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Topic Action - When writing a match expression against
GuardrailTopicAction, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Topic Type - When writing a match expression against
GuardrailTopicType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Topics Tier Name - When writing a match expression against
GuardrailTopicsTierName, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Guardrail
Word Action - When writing a match expression against
GuardrailWordAction, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Inference
Profile Model Source Contains information about the model or system-defined inference profile that is the source for an inference profile..
- Inference
Profile Status - When writing a match expression against
InferenceProfileStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Inference
Profile Type - When writing a match expression against
InferenceProfileType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Inference
Type - When writing a match expression against
InferenceType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Input
Tags - When writing a match expression against
InputTags, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Invocation
LogSource A storage location for invocation logs.
- JobStatus
Details - When writing a match expression against
JobStatusDetails, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Knowledge
Base Config The configuration details for retrieving information from a knowledge base and generating responses.
- Model
Copy JobStatus - When writing a match expression against
ModelCopyJobStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Model
Customization - When writing a match expression against
ModelCustomization, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Model
Customization JobStatus - When writing a match expression against
ModelCustomizationJobStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Model
Data Source The data source of the model to import.
- Model
Import JobStatus - When writing a match expression against
ModelImportJobStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Model
Invocation JobInput Data Config Details about the location of the input to the batch inference job.
- Model
Invocation JobOutput Data Config Contains the configuration of the S3 location of the output data.
- Model
Invocation JobStatus - When writing a match expression against
ModelInvocationJobStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Model
Modality - When writing a match expression against
ModelModality, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Model
Status - When writing a match expression against
ModelStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Offer
Type - When writing a match expression against
OfferType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Performance
Config Latency - When writing a match expression against
PerformanceConfigLatency, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Prompt
Router Status - When writing a match expression against
PromptRouterStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Prompt
Router Type - When writing a match expression against
PromptRouterType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Provisioned
Model Status - When writing a match expression against
ProvisionedModelStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Query
Transformation Type - When writing a match expression against
QueryTransformationType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - RagConfig
Contains configuration details for retrieval of information and response generation.
- Rating
Scale Item Value Defines the value for one rating in a custom metric rating scale.
- Reasoning
Effort - When writing a match expression against
ReasoningEffort, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Region
Availability - When writing a match expression against
RegionAvailability, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Request
Metadata Filters Rules for filtering invocation logs. A filter can be a mapping of a metadata key to a value that it should or should not equal (a base filter), or a list of base filters that are all applied with
ANDorORlogical operators- Reranking
Metadata Selection Mode - When writing a match expression against
RerankingMetadataSelectionMode, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Reranking
Metadata Selective Mode Configuration Configuration for selectively including or excluding metadata fields during the reranking process. This allows you to control which metadata attributes are considered when reordering search results.
- Retrieval
Filter Specifies the filters to use on the metadata attributes/fields in the knowledge base data sources before returning results.
- Retrieve
AndGenerate Type - When writing a match expression against
RetrieveAndGenerateType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - S3Input
Format - When writing a match expression against
S3InputFormat, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Search
Type - When writing a match expression against
SearchType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Sort
ByProvisioned Models - When writing a match expression against
SortByProvisionedModels, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Sort
Jobs By - When writing a match expression against
SortJobsBy, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Sort
Models By - When writing a match expression against
SortModelsBy, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Sort
Order - When writing a match expression against
SortOrder, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Status
- When writing a match expression against
Status, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature. - Vector
Search Reranking Configuration Type - When writing a match expression against
VectorSearchRerankingConfigurationType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.