Planning-time Context Resolvers (read-only) using Provider Capabilities to populate Request.Context

[blindzero]

Problem Statement

IdLE evaluates step Condition during planning. Many workflows require up-to-date, read-only information to decide whether a step applies, for example:

• group membership / entitlements
• identity properties
• device inventory hints

Today this requires host-side enrichment, which reduces portability and standardization.

We want a first-class, portable mechanism to resolve such read-only information during planning, similar to Terraform “data sources”, while keeping IdLE guardrails:

• read-only only (no side effects)
• deterministic plan artifacts (resolved data is captured in plan snapshot/export)
• provider extensibility (providers can contribute additional read operations)
• clear execution order (resolve once per plan build before conditions)

Proposed Solution

1) Workflow-level ContextResolvers section (planning-time)

Add an optional workflow section:

• ContextResolvers: list of resolvers
  • Capability: provider capability to call (read-only only), e.g.:
    • IdLE.Entitlement.List
    • IdLE.Identity.Get (or similar, if/when defined)
    • IdLE.Device.List (if/when Intune provider exists)
  • Provider: optional selector (if multiple providers support the capability)
  • With: resolver inputs (identity keys, filters, etc.)
  • To: path relative to Request.Context (e.g., Identity.Entitlements, Identity.Attributes, Devices.Intune.ManagedDevices)

Rules:

• To MUST write under Request.Context.* only.
• If To points outside Request.Context, planning MUST fail fast with a clear validation error.
• Only allow a defined allow-list of read-only capabilities in ContextResolvers.

2) Planning pipeline behavior

During plan creation:

1. Validate the ContextResolvers schema.
2. Execute resolvers in declared order (ordered execution is sufficient for v1).
3. Enforce read-only by design:
   • only allow calling capabilities from the read-only allow-list
   • do not allow Ensure* / modifying capabilities
4. Write resolver results into Request.Context.* at To.
5. Evaluate step Condition using the now-populated Request.Context.*.
6. Export the plan including Request.Context.* in RequestSnapshot (per Issue 2).

3) Provider extensibility model

• Providers already declare supported capabilities; ContextResolvers reuses this system.
• Providers may implement additional read capabilities; if a capability is added to the allow-list, it can be used by workflows.
• Resolver outputs must be serializable and stable.

4) Minimum viable resolver (required for v1)

Implement at least one end-to-end resolver based on an existing capability:

• Capability: IdLE.Entitlement.List
  • returns normalized entitlements for identity keys in the request
  • writes to Request.Context.Identity.Entitlements (or the configured To)

Alternatives Considered

1. Separate “resolver types” registry (new type system)
   • Adds another classification dimension besides step types and capabilities.
2. Host-only enrichment
   • Works but reduces portability and standardization.
3. Runtime-only evaluation
   • Conflicts with deterministic planning and makes workflows less declarative.

Impact

• Planning will call provider read capabilities when resolvers are configured.
• Requires strong validation and snapshot safety rules to avoid secret leakage.
• Improves portability and declarative workflow authoring.

Dependencies

• Requires Issue 1 (schema: Request.Intent and Request.Context).
• Requires Issue 2 (plan snapshot/export includes Request.Context safely).

Definition of Done (Step-0-Ready / Agent-Safe)

Design / Contracts

• Define workflow schema for ContextResolvers and validate it.
• Define and document the allow-list of read-only capabilities usable in ContextResolvers.
• Define provider selection rules when multiple providers support a capability.
• Define normalized output shape for IdLE.Entitlement.List.

Implementation

• Execute ContextResolvers before condition evaluation during plan build.
• Invoke provider capability calls for resolvers via existing capability dispatch mechanisms.
• Write results under Request.Context.* only.
• Fail fast if To is outside Request.Context.
• Fail fast if a resolver references a capability not in the read-only allow-list.

Tests (Pester)

• Resolver runs before conditions and influences step applicability.
• To outside Request.Context is rejected.
• Resolver output is captured in plan snapshot/export.
• Non-allow-listed capability in resolver -> validation error.

Docs / Examples

• Add example workflow using ContextResolvers and referencing Request.Context.Identity.Entitlements in a condition.
• Document how providers expose capabilities used by ContextResolvers.

Non-Goals

• No general dependency graph engine in v1 (ordered execution is sufficient).
• No interactive UX.