---
id: MAN-15
family: GR-MAN
level: core
profiles: [storage-api]
posture: normative-target
added: "1.0"
changed: "1.0"
source: https://flowdrop.io/spec/rules/gr-man/man-15
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# MAN-15 — Launch inputs are checked in one fixed order and answered once

*GR-MAN (Part I) · level: core · profiles: storage-api · added in 1.0*

A caller gets one problem to fix at a time, in the order that makes the next attempt useful: what you sent that does not exist, then what you did not send, then what is wrong with what you sent.

## The rule

> **Normative.** This is the rule.
>
> 1. Launch inputs are checked in three stages (keys that are not declared inputs, then required inputs that are absent, then the values themselves), and the check stops at the first stage that fails, returning one message.
>
> 2. Every message ends by naming the inputs the workflow does accept, or by stating that it accepts none.
>
> 3. An input counts as required when its manifest entry says so, or when its name appears in the published contract's top-level required list; either source is sufficient, so a manifest written before the contract was last rebuilt is still enforced.


## What it means

A launch can be wrong in more than one way at once, and the three stages are
ordered so a caller is never told about a problem fixing the first one would
have made moot. A key that is not a declared input name is checked before
whether a required input is missing, which is checked before the values
themselves — and the check stops the moment a stage fails. A caller who both
misspelled an input's name and left a required one out only hears about the
misspelling: the missing-required message would be about a state the caller
has not actually reached yet, since fixing the typo might supply it.

Every message, at whichever stage it stops, ends the same way: it names the
inputs the workflow accepts, or says it accepts none. And "required" has two
sources, not one — a manifest entry can say so directly, or the input's name
can simply appear in the published contract's top-level required list. Either
is enough on its own, so a manifest written before that contract was last
rebuilt is still enforced through the newer source.

## Example

The workflow declares one input, `message`, required.

```json title="A misspelled key, sent alongside a missing required input" verdict="refused"
{ "mesage": "typo" }
```

```json title="No unknown keys, but the required input never arrives" verdict="refused"
{}
```

The first refusal reports only the unknown key and the inputs the workflow
accepts; it says nothing about `message` being missing, even though it is.
The second, sent once the typo is gone, is the first point at which the
missing-required stage gets to speak.

## Why

Recorded under OPEN-16.

## Related rules

- Names: MAN-2, MAN-13, MAN-16
- Referenced by: API-2, MAN-2, MAN-13, MAN-16

---

Rule identifiers are permanent and are never renumbered. This specification carries
no implementation status: each implementation publishes its own standing against
these rules. Licensed CC BY 4.0.