# PARAM_SOURCE_KEY

**Kind:** Constant

**Source:** [`atloria-monorepo/libs/parser-core/src/openapi/param-source-inference.ts`](https://github.com/sherkety/atloria/blob/main/atloria-monorepo/libs/parser-core/src/openapi/param-source-inference.ts#L22)

Infer where a parameter's candidate values come from.

A reader opening `GET /projects/{projectId}` has to already possess a UUID, so the
realistic first-call success rate on any path-parameter endpoint is close to zero. The fix
is to render that field as a picker fed by the sibling collection (`GET /projects`), showing
names and submitting ids.

Nobody in the API-documentation market does this (a 2026 survey of ~40 documentation,
playground, portal and client products found zero). It IS proven one category over, in
connector designers — Microsoft Power Platform's `x-ms-dynamic-list`, Zapier, Make, n8n —
so the vocabulary below deliberately mirrors Microsoft's rather than inventing a new one:
we inherit a design that already solved the parameter-ambiguity problem, and any spec
already annotated for Power Platform is trivially interoperable.

What is ours is that nobody has to author it. Those platforms make a human declare every
binding; we infer it from the spec's own shape, because our spec is generated from the same
source tree as the entity graph.