requirements file

Authored

The SINGLE authored input to an engagement (Plan 15 drift ④: consolidates the former mission.json + criteria.json — ehimare led this and is canonical). Holds the business framing (purpose/useCases/stakeholders/stressTest/values/narrative) AND the scored criteria[] the kernel reads via ctx.data.requirements.criteria. Instance extensions narrow via allOf + $ref to this $id with unevaluatedProperties:false.

Authored — The single authored input — you edit this file directly. 43 fields.

Feeds a build step — requirements.md is generated from this file (node scripts/generate-requirements-md.mjs). Edit this source, never the output.

This table is generated at build time from requirements.schema.json — change the schema, and this page changes.

Field	Type	Description
`_comment`	string	Free-text authoring note; ignored by the kernel.
`title` required	string	Document title — 'Requirements & Constraints — <client>'.
`statusBanner`	string	Optional Markdown banner flagging the document's confidence/status (e.g. model signed off, facts draft-to-verify).
`purpose` required	string	One paragraph: what the solution is FOR — the engagement's reason to exist, in business language.
`useCases`	array<object>	The jobs the solution must do, tool-neutral — these ARE the requirements in business language and seed the Fit criteria.
`id` required	string	Stable use-case key (referenced by criteria[].useCase and solution coverage maps).
`title` required	string	Short job name.
`what`	string	What the job is and why it matters — current pain included.
`currentState`	enum	How the job is handled today — drives the improvement story. `none` · `manual` · `digitized`
`improvementLevel`	enum	The kind of lift this job needs — from enabling something impossible today to layering an AI assist on a working baseline. `enable` · `digitize` · `improve` · `ai-assist`
`enables`	string	Optional note on what this job unlocks downstream.
`clientCopy`	object	Client-facing / presentation register for this use case (e.g. ladder captions, an enabler note) — permissive; the shell renders it as public copy. The home for authored display residue when externalizing instance data-as-code, so the semantic fields above stay load-bearing only.
`stakeholders`	array<object>	Who the solution serves and constrains — decider, daily users, the framing authority.
`role` required	string	The stakeholder's relationship to the solution (e.g. 'Decides & pays', 'Uses daily').
`who` required	string	Who fills that role, with the relevant context.
`stressTest`	string	The concrete scenario every candidate solution must survive — the worked case the whole comparison is sanity-checked against.
`values`	array<object>	The client's guiding values/principles, each tied to the criterion or gate that encodes it — the bridge from values to the scored model.
`value` required	string	The value/principle stated plainly.
`evidence`	string	Where the value is encoded in the model (which gate/criterion carries it) — keeps values and scoring honest.
`narrative`	object	The authored long-form framing (the 'why' prose) shown in the requirements view — a leitsatz plus titled Markdown sections.
`leitsatz`	string	The guiding sentence — the one-line thesis of the whole approach.
`sections`	array<object>	Ordered prose sections.
`h` required	string	Section heading.
`md` required	string	Section body as Markdown.
`criteria` required	array<criterion>	The scored model — gates, fit criteria and risk dimensions. The load-bearing array the kernel and shell read. Cross-references (useCase → useCases[].id, assistFor → another criterion id) are SHAPE-valid here and RESOLVED in the semantic tier.
`id` required	string	Stable criterion id (e.g. G-INDEP-01, F-CONTACTS-01, R-DATA-01); pattern conventions checked in the semantic tier.
`name` required	string	Short human name for the criterion.
`category` required	string	Which category/section the criterion belongs to (e.g. 'shared', 'system'); resolves against config.categories in multi-category instances.
`tier` required	enum	Importance tier. 'hard' marks a gate (pass/fail); the other three weight a Fit/Risk criterion via config.tierWeights. `hard` · `critical` · `standard` · `nice-to-have`
`axis` required	string	Which axis the criterion scores on — base vocabulary gate\|fit\|risk. Typed as string (not hard-enumed) so an extension may pin a widened axis set (e.g. skischule's 'curation'); the semantic tier enforces the instance's allowed axes.
`weight`	string,number	Numeric weight (often authored as a string). '0' for gates; the tier weight (e.g. '5'/'3'/'1') for fit/risk criteria.
`description` required	string	What the criterion measures and how its 1–5 scale reads — the rubric a scorer applies.
`useCase`	string	Optional link to the use case this fit criterion serves (→ useCases[].id).
`riskDim`	string	Risk dimension key — present only when axis:risk (e.g. datensicherheit, abhaengigkeit, resilienz, terminSicherheit).
`area`	string	Optional grouping label for display (e.g. 'Knowledge', 'Technical properties').
`appliesTo`	array<string>	Optional scoping — which categories/contexts the criterion applies to.
`assistFor`	string	For an optional AI-assist criterion: the id of the base (non-AI) criterion it augments — encodes the two-tier 'KI-free base + optional assist' model. Resolved in the semantic tier.
`ladderKey`	string	Optional stable slug identifying this criterion in a requirements-ladder / coverage register (e.g. architectures[].cov keys off it). A model cross-reference, NOT display — distinct from id when an instance keeps a coarser ladder vocabulary.
`clientCopy`	object	Client-facing / presentation register for this criterion (e.g. a short ladder label override, the today→digital captions, an assist caption, an enabler note) — permissive; the shell renders it as public copy. The home for authored display residue when a view-model (e.g. a requirements ladder) is derived from criteria rather than copied; the scored fields above stay load-bearing only.
`costNote`	string	How cost/affordability is handled — typically a note that cost is neither a gate nor a fit score but a separate TCO comparison.
`notRequirements`	array<string>	Explicit non-goals — what was deliberately ruled OUT of scope, so the boundary is recorded.
`constraints`	map<string>	Named hard constraints/context (compliance, budget, operating model, …) as free-form keyed prose — permissive map of constraint-area → description.
`openQuestions`	array<string>	Unresolved factual questions whose answers turn placeholder assumptions into real ones.

← Back to the reference