This one decision answers the three open questions on the parent epic: a new content system or small steps; a flag on each configuration option or a key on the language-specific Function; and a new top-level type for dispatching NLG Functions. We compare the options on the readiness criteria, on the permissions that each one needs, on migration cost for existing configurations, and on server load (from the run-time cost measurement). We record the decision and the options that we rejected, with reasons.

The options that we know of are below. The decision may find others, or combine them.

• Option A: Keep the current conventions, and add a user interface that reads them. Wikifunctions recognises the configuration pattern inside a dispatching Function's implementation, and offers pre-filled creation and registration on top of it. No data changes. This is the smallest change, but the software then depends on an on-wiki convention that the community can change at any time. It also cannot list unregistered Functions, because the configuration is the only record, so it does not meet all the readiness criteria.
• Option B: Add a "live" flag to each configuration option. The Function option type (Z14293) gets a boolean flag on each registration, and the selector (Z14310) skips options that are registered but not live. The configuration then holds both the link and the status, in one place. These are on-wiki type changes, not software changes. This allows languages to be registered with test cases but no successful implementation yet, so users have somewhere to go. Server load does not change.
• Option C: Add a key to the language-specific Function that names its dispatching Function and languages. The Function itself says what it is a language-specific version of. The software can then list unregistered Functions, and check that the signatures match. Registration stays in the configuration, so there are two records that can disagree, and we need a check for that. This needs a new optional key on the Function type (Z8) in function-schemata. Only language-specific Functions use it, so a general type carries a key for one use. This is not tidy, but it is a reasonable cost.
• Option D: Make dispatching NLG Functions a new top-level type. A second kind of callable object, next to the Function (Z8), which in general returns monolingual HTML (Z91). It holds its signature, its default Function, and its language-specific Functions with their languages and live status. The link and the status are then one record, by construction. The data model has no sub-types, so this is a new type next to Z8, not a kind of Z8; to add sub-types to the model would be more work. Because it is a separate type, it can have its own user rights and rate limits, and the orchestrator can dispatch it natively, which can reduce server load. If its cache keys include the revision of the dispatching object, a status change also makes old cached results unused, without a separate step to remove them. This is the largest option: it changes function-schemata, the orchestrator and the Wikifunctions user interface, and needs a migration of existing configurations. It could also be the route by which monolingual NLG Functions become HTML NLG Functions.
• Option E: Keep a separate list of language-specific Functions for each dispatching Function. A new on-wiki object, next to the configuration, lists every language-specific Function, registered or not. This needs no software change to the data model, but there are two lists to keep in step by hand, and nothing makes them agree. We list it for completeness.
• Option F: Record the link outside wiki content. The software records the link in a database table when a user creates a language-specific Function. This is quick to build, but the link then has no page history, users cannot see it or correct it on-wiki, and it is not in the content dumps. We list it for completeness.

Acceptance criteria

• A decision record compares the options on the readiness criteria, permissions, migration cost and server load, and states the chosen option and the reasons each other option was rejected.
• The decision record is linked from this task and from the parent epic.