Skip to main content
User Inputs are what the person running your App provides at runtime. Every downstream block inherits whatever they contain, so it pays to get them clean.

​
Routing is fixed for inputs

Each input type has one mandatory routing behavior.
A Document Upload always becomes a Knowledge Source, never an inline variable. Injecting a full uploaded document into a prompt is exactly the mistake Knowledge Sources: Inline vs. Retrieval exists to prevent.

​
Rules that keep inputs clean

1

Aim for 5 to 7 inputs

Every extra input adds friction for the end user.
2

Name inputs deterministically

“Job Description” becomes /job_description. Lowercase, underscores, no abbreviations, no synonyms. Use the same name everywhere: input definition, prompts, documentation.
3

Write end-user instructions

Fifty words or fewer, for every input. Say what to provide, in what form, with one example. “Paste the full job description, including requirements” beats “Job info”.
4

Use Multiple Choice for anything that branches

Analysis depth, target language, report type. Free text has to be interpreted; a fixed set of choices does not.
If only one option should be selectable, say so in the input instructions. Single-select cannot be enforced yet.
5

Add a Language selector when needed

Include a Language selector (Multiple Choice) when the App may serve users in several languages.
Deterministic naming is what lets a block reliably find its inputs. The same /job_description in the input definition, in every prompt, and in your documentation removes an entire class of “why is this block empty?” failures.
See App Blocks for how these inputs are wired into each block as it runs.

​
Next

Knowledge Sources: Inline vs. Retrieval

How a block knows what it knows.