> ## Documentation Index
> Fetch the complete documentation index at: https://docs.operata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Lex redaction schema

> Field tiers, mandatory keep-list, and processing order for the Amazon Lex redaction Lambda that runs in your AWS account.

The Amazon Lex redaction Lambda enforces this schema. The Lambda runs inside
your AWS account, applies these rules to every Lex conversation event read
from CloudWatch, and ships only the surviving payload to Operata.

For the model behind the schema and the rollout procedure, see
[Concept: Privacy and redaction](/docs/concepts-privacy-and-redaction)
and [Configure Lex redaction](/docs/guides-configure-lex-redaction).

<Warning>
  This schema applies to the Amazon Lex integration only. Contact
  Flow Logs and CTR integrations have their own schemas.
</Warning>

## Field tiers

Every field in a Lex conversation event belongs to exactly one of six
tiers.

| Tier      | Behavior                                                                               | Controlled by |
| --------- | -------------------------------------------------------------------------------------- | ------------- |
| Mandatory | Key and value transmitted unchanged. Cannot be denied, hashed, encrypted, or redacted. | Operata       |
| Allow     | Key and value transmitted unchanged. Customer-declared.                                | Customer      |
| Deny      | Key and value removed entirely. Operata never sees the field.                          | Customer      |
| Encrypt   | Key retained, value replaced with a hash or ciphertext.                                | Customer      |
| Transform | Key retained, value replaced with derived or calculated data.                          | Customer      |
| Default   | Key retained, value nullified.                                                         | Customer      |

The four customer-configurable tiers (Allow, Deny, Encrypt, Transform)
are mutually exclusive: any one field appears in at most one tier.

<Warning>
  Today only the Mandatory tier is enforced end to end. Allow, Deny,
  Encrypt, and Transform are accepted in the config but applied as
  pass-through. Follow the [Operata changelog](/docs/changelog) for
  rollout.
</Warning>

## Processing order

The Lambda processes every event in four passes, in order.

1. **Mandatory override.** Check each field path against the mandatory
   list. If a mandatory field sits under a denied parent, retain the
   parent and prune all non-mandatory siblings. Mandatory always wins.
2. **Deny.** Evaluate every remaining field path against the deny
   list. Mark matched fields for removal.
3. **Allow, Encrypt, Transform.** Apply the customer-declared tiers
   to remaining fields.
4. **Default nullify.** Every field not covered by the previous three
   passes keeps its key, value becomes `null`.

## Path notation

Both lists use dot notation.

* `sessionState` matches the entire object at that key.
* `sessionState.intent.name` matches only that subfield.
* A trailing `.*` matches every direct child of the path. For
  example, `interpretations.intent.slots.*.shape` matches the `shape`
  field on every slot under `interpretations.intent.slots`.

Rules apply at every depth consistently.

## Parent-key behavior

When a deny entry targets a parent and no mandatory entry references
any child, the Lambda removes the entire key — not an empty object.

When a deny entry targets a parent and the mandatory, allow, encrypt,
or transform list references one or more children of that parent, the
Lambda retains the parent containing only those referenced children.

## Data flow

```text theme={null}
CloudWatch (raw Lex conversation log)
  ↓
Redaction Lambda (in your AWS account)
  ├─ Pass 1: Mandatory override
  ├─ Pass 2: Deny
  ├─ Pass 3: Allow / Encrypt / Transform
  └─ Pass 4: Default nullify
  ↓
Operata API (filtered payload only)
```

## Mandatory keep-list

The redaction Lambda always preserves these fields, regardless of
deny, encrypt, or transform configuration.

```text theme={null}
errorLogSchema
errorLogSchemaType
timestamp
requestId
messageVersion
transcriptions.resolvedContext.intent
transcriptions.transcriptionConfidence
transcriptions.resolvedSlots.*.shape
fulfilledByAssistedNlu
requestAttributes.x-amz-lex:*
sessionId
inputMode
bargeIn
operationName
isTestWorkbenchTraffic
interpretations.intent.name
interpretations.intent.state
interpretations.intent.slots.*.shape
interpretations.intent.confirmationState
interpretations.interpretationSource
interpretations.nluConfidence
developerOverride
bot
sessionState.sessionAttributes.x-amz-lex:*
sessionState.sessionAttributes.bedrock_request_id
sessionState.sessionAttributes.confirm_bedrock_request_id
sessionState.sessionAttributes.confirm_llm
sessionState.sessionAttributes.confirm_llm_input_tokens
sessionState.sessionAttributes.confirm_llm_latency
sessionState.sessionAttributes.confirm_llm_model_id
sessionState.sessionAttributes.confirm_llm_output_tokens
sessionState.sessionAttributes.llm
sessionState.sessionAttributes.llm_input_tokens
sessionState.sessionAttributes.llm_latency
sessionState.sessionAttributes.llm_model_id
sessionState.sessionAttributes.llm_output_tokens
sessionState.dialogAction
sessionState.dialogAction.slotToElicit
sessionState.dialogAction.type
sessionState.intent.name
sessionState.intent.state
sessionState.intent.slots.*.shape
sessionState.intent.confirmationState
sessionState.originatingRequestId
missedUtterance
responseReason
utteranceContext
```

## Related

* [Configure Lex redaction](/docs/guides-configure-lex-redaction) — step-by-step rollout.
* [Concept: Privacy and redaction](/docs/concepts-privacy-and-redaction) — the cross-integration model.
* [Contact Flow Log redaction schema](/docs/contact-flow-log-privacy) — the sibling schema for contact-flow logs.
* [Install the Amazon Lex integration](/docs/lex-integration) — the integration this schema applies to.
