vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If you want to use something other than our latest image, you can use this parameter.

Example: icr.io/continuous-delivery/toolchains/devsecops/baseimage:some-other-tag





 custom-exempt-label 

This is an optional parameter for the CI and CC pipelines. If you marked an incident issue permanently exempted with a custom label, then this parameter should hold the value of the custom label.





 customer-impact 

This parameter is for the promotion pull request, it records the impact of the change request on the customer. By default the parameter is the pipe separated string 'Critical | High | Moderate | Low | No_Impact'. Edit the default string to select one of the options.





 description 

This parameter is for the promotion pull request. This parameter contains the description of the change, that will be appended to the Change Request Description. By default it is empty.





 detect-secrets-baseline-filename 

This parameter specifies a custom file name for the baseline file that is used by detect-secrets. By default, detect-secrets looks for a file that is named .secrets.baseline in the repository root directory. However, if you name your baseline file differently, you can provide its file name by using this parameter.





 detect-secrets-exclusion-list 

This parameter is an environment property that overrides the default exclusion list when a run is done without an existing baseline file. This pàrameter identifies files to ignore so that issues are not created that are linked to them.





 detect-secrets-verbose 

This parameter, when set to 1, logs the name of the current file being scanned.





 impact 

This parameter is for the promotion pull request. Additional notes on what this Change Implementation will impact. By default it is empty.





 pipeline-debug 

If this is set to 1, the pipeline will run in debug mode, and the logs will show more information. By default, it is set to 0.





 priority 

This parameter is for the promotion pull request. The priority of the change request. By default it is 'Critical | High | Moderate | Low | Plan'. You can change it to one of these values.





 purpose
Custom 

You can use your own custom identity provider when you authenticate. Your identity provider can conform to any authentication mechanism that is not specifically supported by IBM Cloud® App ID, including proprietary.

When App ID does not provide direct support for a particular identity provider, you can use the custom identity flow to bridge the authentication protocol to App ID's existing authentication flow. For example, you want to use GitHub or LinkedIn to allow your users to sign in. You can use the identity provider's existing SDK to facilitate user authentication information before packaging and exchanging it with App ID. In many enterprise scenarios, a legacy identity provider might use its own custom authentication protocol, but you still want to leverage the capabilities of App ID. For this type of scenario, the custom identity flow provides a decoupled means of securely authenticating your users without exposing their credentials.



 Configuring custom identity 

You can use the following steps to configure your custom identity provider to work with App ID.



 Before you begin 

To establish trust between App ID and your custom identity provider, you must have an RSA PEM key pair with a minimum length of 2048. Be sure that you securely back up any keys that you use in production.

How are the keys used?



* Your private key is used in your app or identity provider to sign JWTs.
* Your public key is used by App ID to validate the JWT that contains user information.



To generate an RSA PEM key pair by using Open SSL, run the following command:

openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048
openssl rsa -pubout -in private_key.pem -out public_key.pem





 Configuring with the GUI 



1. Sign in to your IBM Cloud account and navigate to your instance of App ID.
2. In the Manage tab, set Custom Identity Provider to On.
3. Register your public key with App ID.



1. Navigate to the Custom Identity Provider tab
2. Paste your public key in the Public Key box and click Save.









 Configuring with the API
prod-KMIPAdapter-dynamicID-@domainName Used for installation and configuration of the KMIP for VMware service. 
 prod-SPPlus-dynamicID-@domainName Deprecated - Used for installation and configuration of the IBM Spectrum Protect Plus service. 
 prod-Veeam-dynamicID-@domainName Used for installation and configuration of the Veeam service. 
 prod-HCX-dynamicID-@domainName Used for installation and configuration of the VMware HCX™ service. 



where:



* dynamicID is the 8 - 10 characters that are generated dynamically during the service installation.
* shortID is the 5 characters that are generated dynamically during the service installation.
* domainName is the domain name of your instance.







 Related links 



* [IBM Cloud compliance programs](https://www.ibm.com/cloud/compliance)
* [IBM Cloud Hyper Protect Crypto Services API](https://cloud.ibm.com/apidocs/hs-crypto)
* The responseData.keyId field includes the unique identifier that is associated with the key.
* The responseData.keyVersionId field includes the unique identifier of the current key version that is used to wrap input ciphertext on wrap requests.
* The responseData.keyVersionCreationDate field includes the date that the current version of the key was created.
* The responseData.keyState field includes the integer that correlates to the state of the key.







 Delete key 

The following field includes extra information:



* The responseData.keyState field includes the integer that correlates to the state of the key.







 Expire Key 

The following field includes extra information:



* The requestData.keyType field includes the type of key that was created.
* The responseData.keyId field includes the unique identifier that is associated with the key.
* The requestData.expirationDate field includes the date that the key expired on.
* The responseData.initialValue.keyState field includes the integer that correlates to the previous state of the key.
* The responseData.newValue.keyState field includes the integer that correlates to the current state of the key.







 Wrap or unwrap key 

The following field includes extra information:



* The responseData.keyVersionId field includes the unique identifier of the current key version that is used to wrap input ciphertext on wrap requests.







 Rewrap key 

The following field includes extra information:



* The responseData.keyVersionId field includes the unique identifier of the current key version that is used to wrap input ciphertext on wrap requests.
* The responseData.rewrappedKeyVersionId field includes the unique identifier of the new key version that is used to wrap input ciphertext on wrap requests.







 Restore key 

The following field includes extra information:



* The responseData.keyVersionId field includes the unique identifier of the current key version that is used to wrap input ciphertext on wrap requests.







 Rotate key
Get it from the service credentials section of the App Configuration service dashboard.
* apikey: API key of the App Configuration service. Get it from the service credentials section of the App Configuration service dashboard.
* collectionId: ID of the collection created in App Configuration service instance under the Collections section.
* environmentId: ID of the environment created in App Configuration service instance under the Environments section.





Ensure to create the service credentials of the role Client SDK for using with the React client SDK. API key of the Client SDK role has minimal access permissions that are suitable to use in browser based applications.



 Examples for using feature and property-related APIs 

See the following examples for using the feature-related APIs.



 Get single feature 

import { useFeature } from 'ibm-appconfiguration-react-client-sdk';
const feature = useFeature('feature_id')

if(feature) {
console.log(Feature Name ${feature.getFeatureName()} );
console.log(Feature Id ${feature.getFeatureId()} );
console.log(Feature Type ${feature.getFeatureDataType()} );
console.log(Feature is enabled ${feature.isEnabled()} );
}





 Get all features 

import { useFeatures } from 'ibm-appconfiguration-react-client-sdk';

const features = useFeatures();
const feature = features["feature_id"];

if(feature) {
console.log(Feature Name ${feature.getFeatureName()});
console.log(Feature Id ${feature.getFeatureId()});
console.log(Feature Type ${feature.getFeatureDataType()});
console.log(Feature is enabled ${feature.isEnabled()});
}





 Evaluate a feature 

You can use the feature.getCurrentValue(entityId, entityAttributes) method to evaluate the value of the feature flag.
[Learn more about versioning](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-predefined-profilesprofile-update-levels).

To avoid having to create and maintain a fully customized profile, you can customize a predefined profile by using [parameters](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-posture-management). A parameter is the actual value that your resource is evaluated against. Each parameter is assigned a default value that can be edited at the time of attachment. Each attachment can be assigned a different parameter value, which then changes the evaluation that is completed. However, when a new version of a profile is released, you need to ensure that your customizations are made for the new profile version.





 Working with custom profiles 

If you want total control over your profile - the number of assessments, versioning, or naming, you might want to create a custom profile. With custom profiles, you can mix and match controls from different libraries or only select the assessments that apply to your use case. Or, you can create your own controls.

Although it is possible to add both custom and predefined controls to a profile, it is recommended that you create a separate profile for any controls that you want to add. By keeping predefined and custom controls separate, you are able to update to new versions of the predefined profiles more easily as you won't need to redo your customizations.







 Defining scopes in enterprise accounts 

When you work with Security and Compliance Center through an enterprise account, your experience is a bit different when it comes to your set up options. As an enterprise, you have more scope options than an account. You can choose to evaluate your entire enterprise, specific account groups, or single accounts. It is recommended that if you want to evaluate a single account that you do so from that account.

If you are working in an enterprise account, you must have additional permissions for the enterprise to manage and see results. For more information, see [Assigning access](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-assign-roles).
: The name of the service ID, exclusive with the SERVICE_ID_UUID option. Required.

SERVICE_ID_UUID
: The UUID of the service, exclusive with the SERVICE_ID_NAME option. Required.

-f, --force
: Lock without confirmation.

Examples:

Lock the service API key sample-key of service ID sample-service:

ibmcloud iam service-api-key-lock sample-key sample-service

To unlock a service ID API key, use the following command:

ibmcloud iam service-api-key-unlock (APIKEY_NAME|APIKEY_UUID) (SERVICE_ID_NAME|SERVICE_ID_UUID) [-f, --force]





 Deleting an API key for a service ID 

You can delete an API key that is associated with a service ID. However, deleting an API key that is used by an application removes the ability for that application to authenticate with your services.



1. In the console, go to Manage > Access (IAM), and select Service IDs.
2. If you don't have a service ID created, create the service ID.
3. Click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/action-menu-icon.svg) > Manage service ID.
4. Click API keys.
5. Click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/action-menu-icon.svg) > Delete.



If you didn't create the service ID, but you are the account owner or an administrator for the IAM Identity service, you can delete API keys for any service ID in the account.
* [Enumeration](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-typesenumeration)
* [Model](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-typesmodel)
* [Array](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-typesarray)





 Identifier 

The identifier type contains a value which identifies a resource. It MUST uniquely identify a resource among all resources of the same type, and SHOULD uniquely identify a resource among all resources in a system. Identifier values MAY be [RFC 4122 ](https://datatracker.ietf.org/doc/html/rfc4122) UUIDs and SHOULD be selected by the system to ensure uniqueness.

It is not required that all models have identifier values. However, a model which has an identifier value MUST include it in a self-referential field named id. Fields other than id MAY have the identifier type, but such fields MUST refer to other resources.



 Response format 

An identifier value MUST be returned as a JSON string. Case-insensitive identifiers MUST be returned in consistent case and SHOULD be returned in lowercase.

For responses, an identifier field SHOULD have a documented maximum length and character set. For the sake of backward-compatible future expansions, documented constraints MAY be more permissive (allowing for a longer value or larger character set) for responses than for requests.

A resource's self-referential id field MUST be required in any object schema used in a response and representing the resource. An identifier field that expresses an optional binding to a related resource MAY be optional.



Schema guidance for identifiers in responses

 Constraint Recommended value Description 

 type string type MUST be string. 
 format identifier format MUST be identifier. 
 maxLength 128 maxLength SHOULD be present. 
 pattern ^[-0-9a-z]+$ pattern SHOULD be present. 







 Request formats
You must use the name of a model that is returned by the GET /v1/models method. The new custom model can be used only with the base model that it customizes.

description (optional string)
: A recommended description of the new custom model.



* Use a localized description that matches the language of the custom model.
* Include a maximum of 128 characters in the description.



The following example creates a new custom acoustic model named Example acoustic model. The model is created for the base model en-US_BroadbandModel and has the description Example custom acoustic model. The Content-Type header specifies that JSON data is being passed to the method.

IBM Cloud

curl -X POST -u "apikey:{apikey}" --header "Content-Type: application/json" --data "{"name": "Example acoustic model", "base_model_name": "en-US_BroadbandModel", "description": "Example custom acoustic model"}" "{url}/v1/acoustic_customizations"

IBM Cloud Pak for Data

curl -X POST --header "Authorization: Bearer {token}" --header "Content-Type: application/json" --data "{"name": "Example acoustic model", "base_model_name": "en-US_BroadbandModel", "description": "Example custom acoustic model"}" "{url}/v1/acoustic_customizations"

The example returns the customization ID of the new model. Each custom model is identified by a unique customization ID, which is a Globally Unique Identifier (GUID). You specify a custom model's GUID with the customization_id parameter of calls that are associated with the model.

{
"customization_id": "74f4807e-b5ff-4866-824e-6bba1a84fe96"
}





 Add audio to the custom acoustic model 

Once you create your custom acoustic model, the next step is to add audio resources to it.
Viewing a list of all custom resolver forwarding rules using the API 

To view the details of a custom resolver forwarding rule using the API, follow these steps:



1. Set up your API environment with the correct variables.
2. Store the following values in variables to be used in the API command:



* instance_id, which is the unique identifier of a service instance.
* resolver_id, which is the unique identifier of a custom resolver.
* rule_id, which is the unique identifier of a forwarding rule.
* X-Correlation-ID, which is a string that uniquely identifies a request.



3. When all variables are initiated, view the list of your custom resolver forwarding rule:

{
"forwarding_rules": [
{
"id": "5365b73c-ce6f-4d6f-ad9f-d9c131b26370",
"description": "forwarding rule",
"type": "zone",
"match": "example.com",
"forward_to":
"161.26.0.7"
],
"created_on": "2021-04-21T08:18:25Z",
"modified_on": "2021-04-21T08:18:25Z"
}
]
}
* NAME is the name of the instance
* service-plan-id indicates the type of plan.
* RESOURCE_PLAN_ID is the ID of the plan that you want to set. To get the service plan IDs, see [Service plans](https://cloud.ibm.com/docs/monitoring?topic=monitoring-pricing_plans).





For example, to change the service plan of an instance to the graduated plan, run the following command:

ibmcloud resource service-instance-update monitoring-instance-01 231bb072-1b2f-4d7e-ae9e-9574d382be32
"id": "5365b73c-ce6f-4d6f-ad9f-d9c131b26370",
"instance_id": "5cbc3c1b-021c-4ad7-b9e4-a5dfefdecf85",
"name": "example.com",
"description": "linked zone example",
"linked_to": {
"instance_crn": "crn:v1:staging:public:pdnsdev:global:a/01652b251c3ae2787110a995d8db0135:abe30019-1c08-42dc-9ad9-a0682af70054::",
"zone_id": "05855abe-3908-4cdc-bf0d-063e0b1c296d"
},
"state": "PENDING_APPROVAL",
"label": "dev",
"approval_required_before": "2022-03-16T07:23:25Z",
"created_on": "2022-03-09T07:23:25Z",
"modified_on": "2022-03-09T07:23:25Z"
}
It is the settings that are visible in the JSON on the Summary page that are used when the CA is deployed.

Here is an example of the minimum required JSON parameters for any override when a CA is deployed.

{
"ca": {
"csr": {
"cn": "<COMMONNAME>",
"keyrequest": {
"algo": "ecdsa",
"size": 256
},
"names": [
{
"C": "US",
"ST": "North Carolina",
"L": "Location",
"O": "Hyperledger",
"OU": "Fabric"
}
],
"hosts": [
"<HOSTNAME>"
],
"ca": {
"expiry": "131400h",
"pathlength": 1024
}
},
"debug": false,
"registry": {
"maxenrollments": -1,
"identities": [
{
"name": "<ADMIN_ID>",
"pass": "<ADMIN_PWD>",
"type": "client",
"attrs": {
"hf.Registrar.Roles": "",
"hf.Registrar.DelegateRoles": "",
"hf.Revoker": true,
"hf.IntermediateCA": true,
"hf.GenCRL": true,
"hf.Registrar.Attributes": "",
"hf.AffiliationMgr": true
}
}
]
},
"affiliations": {
"ibp": []
},
}
}
Show more

You can insert additional fields or modify the JSON that is visible in the Configuration JSON box.
* The responseData.keyVersionId field includes the unique identifier of the current key version that is used to wrap input ciphertext on wrap requests.
* The responseData.rewrappedKeyVersionId field includes the unique identifier of the new key version that is used to wrap input ciphertext on wrap requests.







 Restore key 

The following field includes extra information:



* The responseData.keyVersionId field includes the unique identifier of the current key version that is used to wrap input ciphertext on wrap requests.







 Rotate key 

Rotate key doesn't have any extra fields apart from the [Common Fields](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-at-eventsat-common-fields) section.





 Get key total 

The following field includes extra information:



* The responseData.totalResources field includes the total number of keys within the service instance.







 List keys 

The following field includes extra information:



* The responseData.totalResources field includes the total number of keys that are returned in the response.







 Get key or key metadata 

The following fields include extra information:



* The requestData.keyType field includes the type of key that was retrieved.
* The responseData.keyState field includes the integer that correlates to the state of the key.
* The responseData.keyVersionId field includes the unique identifier of the current key version that is used to wrap input ciphertext on wrap requests.
* The responseData.keyVersionCreationDate field includes the date that the current version of the key was created.







 Patch key 

The following fields include extra information:



* The requestData.initialValue.keyRingId field includes the ID of the key ring that the key previously belonged to.
* The requestData.newValue.keyRingId field includes the ID of the key ring that the key belongs to.







 List key versions 

The following field includes extra information:



* The responseData.totalResources field includes the total number of key versions returned in the response.







 Set or unset key for deletion 

The following fields include extra information:
To request a custom voice or for more information, complete and submit this [IBM Request Form](https://form.asana.com/?k=CBuXK1uwlAf5ek6FwB6mcg&d=8612789739828).







 How customization works 

The customization interface of the Text to Speech service creates a dictionary of words and their translations for a specific language. This dictionary is referred to as a custom model. Each custom entry in a custom model consists of a word/translation pair. A word's translation tells the service how to pronounce the word when it occurs in input text.

The customization interface provides methods to create and manage your custom models, which the service stores permanently. After you create a custom model, you can use it during synthesis with any version of the /v1/synthesize method. When the service synthesizes input text, it determines the pronunciation of words that appear in the custom model by applying their translations either directly or indirectly. Because you create a custom model for a specific language, a custom model can be used with any voice that is available in that language.

You specify the translation for a word in a custom model as a sounds-like translation or a phonetic translation. You can use both methods for entries in the same custom model, and you can mix the two methods within the same translation. A number of rules and guidelines apply to custom entries. For more information, see [Rules for creating custom entries](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-rules).





 Sounds-like translation 

Sounds-like translation uses the service's regular pronunciation rules to represent the pronunciation of a target word indirectly. A sounds-like translation is formed from the regular pronunciations of one or more other words. The service first substitutes the specified translation for any occurrence of the word that appears in the input text. It then applies its regular pronunciation rules to the translation, converting the translation to its phonetic representation to obtain the pronunciation.

For example, the service's regular pronunciation rules properly translate many common abbreviations and acronyms. The service pronounces the abbreviation cm as centimeter.