ADR-034: Per-Program Determination Context-Mapping

deprivation_provisional is the seam to generalize. The orchestrator infers TANF deprivation from household composition, sets a provisional flag (orchestrator.rs:711), and canopy-tanf’s mark_provisional_deprivation helper (services/canopy-tanf/src/determine.rs:206-219) writes it into the signed program_extension so an inferred basis is distinguishable from a verified one. This is the "fact absent → mark provisional, don’t silently default" pattern — and program_extension is the only program-signable channel for such a marker today.

So every provisional concept this ADR introduces needs new carriers at up to three layers (signed program output → orchestrator result → persisted row). v1 uses the one that exists (program_extension); a first-class signed field is the coordinated canopy-signing + multi-service + verifier change ADR-028 specifies for snapshot_hash. The decisions below name these additions rather than implying existing fields suffice.

The orchestrator MUST build each program’s /v1/determine input via a dedicated, typed map_<program>_context(facts, policy) → Result<ProgramInput, ContextError> — not by serializing one ApplicationContext and relying on each program to deserialize-or-422 / silently-default. (Replaces orchestrator.rs:714-733/861.)

Rule: every policy-material, required input of a program determination MUST be either (a) satisfiable from the fact source + resolved policy params, or (b) routed to the provisional / input-unsatisfiable path (Decision 4). A program MUST NOT carry a required input the mapper cannot account for.

Enforcement timeline (honest, because the ADR-027 corpus is post-UAT): pre-corpus, the satisfiability gate (Decision 6) checks the mapper against today’s canopy-persons reads + named inference shims (advisory); post-corpus (epic &56), against the fact corpus (blocking).

A determination MUST NOT silently default a policy-material input to a value that yields a verdict (the age.unwrap_or(30) / countable_resources.unwrap_or(0) / has_medicare_part_a.unwrap_or(false) anti-pattern). When such a fact is absent, the outcome is provisional / input-unsatisfiable per Decision 4, naming the missing input(s). Non-material / derived inputs may still default; the rule is scoped to policy-material inputs to avoid absolutism.

These are different because one has a program signature and the other cannot.

Because the orchestrator emits each program’s typed input, a missing required field is a build-time ContextError — never an opaque program-side 422 mis-labeled "Service unavailable." A program whose required inputs are entirely uncapturable today (CAPS / WIC pre-capture, #857 / #769) yields the input-unsatisfiable result of Decision 4 (orchestrator-synthesized, missing inputs named on ProgramResult) — not a 422, not a silent skip, and not a "provisional verdict" (nothing was signed).

Each program declares its determine-input requirements (field; required|optional; policy-material?; source-class) as a single machine-checkable artifact in the ADR-031 compliance/ coverage family, checked by a cargo xtask gate (staged advisory→blocking per ADR-031). The manifest carries a version (composition Plugin.toml-style). One mechanism — the ADR-031-style declared artifact + gate — is canonical; the in-code declaration that feeds it (a linkme distributed-slice, or derivation from the contract structs) is an implementation detail deferred to the manifest slice.

Amendment (#862): for ADR-035 multi-subject contracts (CAPS children[], WIC participants[]), a per-subject row declares nested_in = "<parent array property>" and the gate drift-checks it against the parent’s resolved item schema (items.$ref, or inline items.properties) with the same two-way completeness + required-ness check as the top level. Nested checking is opt-in per parent; a parent array with no nested_in rows (Medicaid members[]) is checked as one opaque field. With the CAPS/WIC contexts exported to their OpenAPI snapshots, the drift cross-check is uniform across all five programs.

ADR-028 already requires the orchestrator to enrich the context (provenance + policy params + corpus-hash) for the signed snapshot. ADR-034 specifies that enrichment is per-program and complete: the mapper produces the exact typed, provenance-carrying input each program signs and snapshots. ADR-034 governs how the input is built; ADR-028 governs what the determination freezes.

For single-subject programs the mapper selects the determination subject (CAPS = the child; WIC = the participant) instead of the orchestrator’s hardcoded applicant = head. Per-member Medicaid subject-selection is explicitly out of scope of this ADR — it brushes ADR-002 program-ownership and is the design subject of #860; it is wholly deferred there.

A provisional verdict (or an input-unsatisfiable result) participates in the assembled combined result and the EE15 most-advantageous-group assignment (ADR-002), but its flag + named missing inputs MUST propagate so it is never presented as firm or allowed to silently win the group assignment without surfacing the verification it needs. This is not free with today’s schema: it requires adding provisional / missing-input fields to ProgramResult (crates/canopy-contracts-eligibility/src/determine.rs:45), CombinedResult (services/canopy-eligibility/src/store/models.rs:47), and the persisted rows, plus the orchestrator parsing the program_extension provisional marker (it reads only program_extension.assigned_coa today, orchestrator.rs:1069). These are named carrier-schema follow-ups.

The mapping assembles only non-restricted worker-authored facts (ADR-027) + policy; the program still signs the determination + snapshot (ADR-002 / ADR-028); ADR-034 changes how the input is assembled, not the black-box output.

ADR-004 governs restricted sources broadly — FTI, SSA SOLQ/BINDEX, FDSH, SAVE — not just IRS FTI. FTI never enters the orchestrator. But the orchestrator today fetches SSA SOLQ pre-dispatch for Medicaid and carries it in ApplicationContext.ssa_solq (orchestrator.rs:~650, crates/canopy-contracts-eligibility/src/determine.rs:113, a pre-existing #384 mechanism). ADR-034 explicitly does not bless that as the target state: restricted-source inputs are out of scope of the mapper, and the existing orchestrator-resident SOLQ is flagged as a pre-existing ADR-004 tension to relocate into the program boundary (program-side fetch) as separate work. ADR-034 neither introduces nor ratifies orchestrator-side restricted-source handling.