Dynamic Key Lookup

Dynamic key lookup lets you use a resolved property value as a key to look up data in another object. This is essential for data-driven policies like role-based access control (RBAC).

Basic Lookup

Use looked up in to resolve a property and use its value as a key into another object:

the __user__ of the **request** looked up in **user_roles**

This resolves request.user to a string (e.g., "alice"), then uses it as a key in user_roles to get user_roles["alice"].

Interactive Example

Reset

Policy Rule

A **request** is from_admin if the __user__ of the **request** looked up in **user_roles** contains "admin".

Test Data (JSON)

{ "request": { "user": "alice" }, "user_roles": { "alice": ["admin", "employee"], "bob": ["employee"] } }

▶ Run

Here request.user resolves to "alice", which is used to look up user_roles["alice"] = ["admin", "employee"]. Then the contains "admin" check passes.

Missing Keys

If the resolved key doesn’t exist in the target object, the lookup returns no result and the condition evaluates to false:

Interactive Example

Reset

Policy Rule

A **request** is from_admin if the __user__ of the **request** looked up in **user_roles** contains "admin".

Test Data (JSON)

{ "request": { "user": "unknown_user" }, "user_roles": { "alice": ["admin"] } }

▶ Run

Chained Lookups

Lookups can be chained. When an intermediate result is an array, each element is used as a key into the next target, and the results are flattened:

__user__ of the **request** looked up in **user_roles** looked up in **role_grants**

Step by step:

1. request.user = "bob"
2. user_roles["bob"] = ["employee", "billing"]
3. For each role: role_grants["employee"] + role_grants["billing"] = flattened array of all grants

This is typically combined with compound predicates to check properties of the resulting objects:

Interactive Example

Reset

Policy Rule

A **request** has matching_grant if any __user__ of the **request** looked up in **user_roles** looked up in **role_grants** where (its __action__ is equal to the __action__ of the **request** and its __type__ is equal to the __type__ of the **request**).

Test Data (JSON)

{ "request": { "user": "bob", "action": "read", "type": "dog" }, "user_roles": { "bob": ["employee", "billing"] }, "role_grants": { "employee": [{"action": "read", "type": "dog"}], "billing": [{"action": "read", "type": "invoice"}] } }

▶ Run

Synonym: Resolved Through

You can use resolved through as a synonym for looked up in:

the __user__ of the **request** resolved through **user_roles**

Both forms are identical in behavior.

Summary

Syntax	What it does
__prop__ of **Source** looked up in **Target**	Use resolved value as key in target
__prop__ of **Source** resolved through **Target**	Same as above (synonym)
... looked up in **A** looked up in **B**	Chain lookups, flattening arrays at each step

Related

• Compound Predicates — check multiple properties of looked-up objects
• Platform RBAC — platform roles, ownership, and access behavior
• Quantifiers — any and all operators used with lookups