The cache is refreshed automatically per org if it is missing or older than
the configured TTL. ``name_contains`` is a case-insensitive substring and
behaves identically to the ``name_contains`` selector on ``aws_query``, so
what you find here is exactly what a query will target.

``service``/``operation``/``params`` follow the AWS CLI and botocore shape,
e.g. ``service="ec2"``, ``operation="DescribeInstances"``,
``params={"Filters": [{"Name": "instance-state-name", "Values": ["stopped"]}]}``.
Paginated operations are followed to completion automatically, so results
are complete rather than a silent first page. If a result is truncated,
raise ``max_items`` to collect more from each account.

``region`` is always required and never defaulted. Account selectors decide
which accounts are touched; with none given, every account in the active org
is targeted, subject to the configured blast-radius cap. The model never
picks which IAM role to assume - pass ``role=`` to override the
deterministic TOML/sole-grant resolution.

Any operation the assumed role may perform is dispatched - reads, writes,
deletes, secret reads, all of it - with AWS IAM as the sole authorization
boundary. Nothing is refused locally; if the role lacks permission, AWS
returns AccessDenied and that is what comes back.

Each entry in ``steps`` is
``{"id": ..., "service": ..., "operation": ..., "params": {...},
"extract": "...", "depends_on": [...]}``.

A later step's ``params`` may reference an earlier step's extracted output
anywhere a literal would go, via ``{"$ref": "<step_id>"}``. There is no
expression language and nothing is ever evaluated as code.

Every resolved account runs its own independent copy of the whole DAG, with
one credential mint per account rather than one per step. As with
``aws_query``, AWS IAM is the sole authorization boundary for every step,
and ``max_items`` raises the per-account pagination ceiling for every step.