Create your Automated Reasoning policy

When you create an Automated Reasoning policy, your input source document is translated into a set of formal logic rules and a schema of variables and types.

Example: If your source document contains an HR policy stating "Full-time employees who have worked for at least 1 year are eligible for parental leave," Automated Reasoning would extract variables like is_full_time (boolean), years_of_service (integer), and eligible_for_parental_leave (boolean), along with a rule that connects them.

Create your Automated Reasoning policy in the console

Create your Automated Reasoning policy using the API

You can use the CreateAutomatedReasoningPolicy API operation to create an Automated Reasoning policy programmatically.

Request parameters

The following parameters are required or optional when creating an Automated Reasoning policy:

Response elements

The API returns the following information:

Example

The following example shows how to create an Automated Reasoning policy using the AWS CLI:

aws bedrock create-automated-reasoning-policy \
  --name "DeleteMe" \
  --description "A Test AR Policy" \
  --source-document file://policy-document.pdf

Example response:

{
  "createdAt": "2025-07-21T14:43:52.692Z",
  "definitionHash": "f16ba1ceca36e1d21adce559481add6a4998b79ae203d933fd0206a28d5c2896513dd62f57b293cba282441269a72063b1d9da02fcf2b421e9bf8495ff8c87af",
  "description": "A Test AR Policy",
  "name": "DeleteMe",
  "policyArn": "arn:aws:bedrock:us-east-1:286352875722:automated-reasoning-policy/lnq5hhz70wgk",
  "updatedAt": "2025-07-21T14:43:52.692Z",
  "version": "DRAFT"
}

View Automated Reasoning policy details

After you create your policy, you can view its the translated logic and variables on the policy's Definitions page.

Policy creation best practices

Good Automated Reasoning policies capture all the information necessary to validate content from your application. At a high level, the policy should return a validation result of VALID when you deem you LLM's answer to be valid and complete.

Create variables that capture user intent and use implications (=>) to structure relationships

Use boolean variables to capture the conclusion a user is driving towards, such as "can I submit this form," or "is this payment compliant," and then use the variables to create rules that follow an if/then "implicative form." You can use the content description field while creating a policy to give examples of the type of questions users will ask or give direct guidance on what these variables should be.

Example:

✓ Good: (=> isPaymentCompliant (<= paymentAmount 10000))

✗ Poor: (<= paymentAmount 10000)

Use booleans instead of enums for non-exclusive states

Represent characteristics that can co-exist as separate boolean variables rather than as mutually exclusive enum values. This prevents logical contradictions when multiple conditions can apply simultaneously. For example, a user can be both a veteran and a teacher. Two boolean variables allow both to be set true. Using enum values to set customerType to TEACHER and customerType to VETERAN causes a contradiction since a variable can only have a single value.

Example:

✓ Good: isTeacher, isVeteran

✗ Poor: customerType = {TEACHER, VETERAN, OTHER}

Specify units and formats explicitly in variable descriptions

Clearly document the unit and format for all numerical values in their descriptions. This reduces variance when interpreting text with different formats and prevents unit conversion errors, leading to more predictable validation results.

Examples:

Validate ranges for numerical values

Use rules to validate variable values to ensure they are valid. Setting these constraints for numerical variables can guard against non-sensical inputs and highlight them as "impossible" when they occur.

Example:

✓ Good: (> patientAge 0)

✓ Good: (and (> creditScore 300) (< creditScore 1100))

Use intermediate variables to model different levels and create abstractions

Use meaningful intermediate variables to represent complex concepts and connect them explicitly to implementation details. Using conceptual variables instead of explicit expressions creates modularity and makes the logical flow from policy concepts to specific outcomes clear. This also allows validation on generic cases where the explicit inputs are not present, for example: "Do premium benefits include free upgrades?"

Example:

(=> (or (> membershipDurationYears 10)
        lifeTimeStatusGranted) 
    hasLifetimeStatus)

(= qualifiesForPremiumBenefits 
   (or isPlatinumMember hasLifetimeStatus))

(=> qualifiesForPremiumBenefits freeUpgrade)

Use enums for categorization and subjective assessments

Define enumerated types for categorizing issues or representing subjective judgments rather than using numerical scales. Discrete categories allow clear definitions to be assigned for each severity. Numerical scales do not provide a consistent means of categorization. If it's possible for a variable not to have a value from the enum, include an OTHER or NONE among the possible values.

Example:

type "Severity" with values "CRITICAL", "MAJOR", "MINOR"

Logic must be declarative and not procedural

Standard computer code executes in a given order but policies specify rules that do not execute in a given order. Design rules and variables to allow if/then/else logic within a single rule. This approach allows rules to remain decoupled and avoids rule conflicts while still clearly representing the logical structure of the policy.

Example:

✗ Poor: (=> conditionA (= outcome VALUE_1))
✗ Poor: (=> conditionB (= outcome VALUE_2))

✓ Good: (=> (and conditionA conditionB) (= outcome VALUE_1))  // A takes precedence when both apply
✓ Good: (=> (and (not conditionA) conditionB) (= outcome VALUE_2))
✓ Good: (=> (and (not conditionA) (not conditionB)) (= outcome DEFAULT_VALUE))

Use clear and consistent naming conventions

Apply predictable patterns in variable naming to enhance readability and consistent interpretation.

Examples: