Behavioural Requirement

Definition

A behavioural requirement is a specific, testable statement about what a product must do or must not do in a defined situation. It is written at the interface level, connected to a rationale, and precise enough to design against and evaluate.

A behavioural requirement specifies the product's behaviour in a specific scenario. It does not describe a user goal, a technical capability, or a general design principle.

For example, “the AI should be transparent” is a principle. “When the AI displays a recommendation, the confidence level must be displayed alongside it in a format that communicates gradations of certainty” is a behavioural requirement.

Behavioural requirements turn governance intent into specification

Behavioural requirements are the foundational unit of behaviour specification. Governance frameworks, safety analyses, and AI accountability documents reduce to behavioural requirements when they move from aspiration to specification.

This distinction matters because broad governance language is not directly designable or testable. A statement such as “the AI should be transparent” does not specify what the interface must do in a particular situation. A behavioural requirement specifies the interface behaviour that must occur, or must not occur, when that situation arises.

Four properties of a well-formed behavioural requirement

A well-formed behavioural requirement has four properties: specificity, testability, interface-level scope, and connection to a rationale.

Specificity

A behavioural requirement applies to a defined situation or scenario, not to the product in general. “The system must be reliable” is not a behavioural requirement. “In the event of a sensor fault, the display must continue showing all remaining sensor values while explicitly indicating which sensor is in fault” is a behavioural requirement.

Testability

A behavioural requirement can be assessed as met or not met without ambiguity. A reviewer should be able to evaluate whether the specified behaviour occurs in the specified situation without making a judgment call about broad terms such as transparency or reliability.

Interface-level scope

A behavioural requirement specifies what the interface must do, not what the model, backend, or algorithm must produce. In AI-enabled products, this distinction is important because model outputs cannot be fully specified in advance, while interface responses to model outputs can be specified and evaluated.

Connection to a rationale

A behavioural requirement traces back to an identified risk, governance obligation, design standard, or operational requirement. Requirements without rationale are preferences. Requirements with rationale are design standards that can be defended in governance review.

Positive and constraint behavioural requirements

Behavioural requirements can specify required behaviour or prohibited behaviour.

Positive behavioural requirements specify what must happen. Examples include: “The AI's confidence level must be visible when its recommendation is shown” and “The audit trail must be accessible from the same interface as the policy configuration, within the same session.”

Constraint behavioural requirements specify what must not happen. Examples include: “AI recommendations must not be displayed before the reviewer has recorded their own assessment in blinded mode” and “Policy evaluation sessions must not permit live policy modifications.”

Both forms are necessary. A specification that includes only positive requirements can still allow behaviours that meet every written requirement while violating the governance intent behind the specification. Constraint requirements close those gaps by excluding behaviours that should not be permitted.

Behavioural requirements differ from adjacent specification types

Behavioural requirements are distinct from functional requirements, user stories, and design principles.

Functional requirements specify what a feature does. Behavioural requirements specify how the product behaves in specific situations. A product can implement all specified features while still behaving in ways that no functional requirement addressed.

User stories describe user goals. Behavioural requirements specify what the interface must do to achieve or constrain those goals. A user story can be satisfied by several different interface behaviours; a behavioural requirement specifies which behaviour is required.

Design principles articulate values and orientations. Behavioural requirements translate principles into specific, testable constraints. “Support human oversight” is a principle. Behavioural requirements specify exactly what the interface must do to support human oversight in each relevant scenario.

Behavioural requirements in regulated medical device development

In regulated medical device development, IEC 62366-1 requires design decisions to be traceable to identified use-related hazards. In this context, behavioural requirements form an intermediate layer between the identified hazard and the design decision.

The traceability chain runs from hazard through requirement to design. For example, the hazard “surgeon activates device in wrong mode” can generate the behavioural requirement “activation state must be recognisable through non-colour cues in the active operating position.” That requirement then generates design decisions intended to address the hazard.

Examples from documented cases

The documented cases show behavioural requirements in governance, AI review, and medical-device interface contexts.

Callsign fraud detection

In the Callsign fraud detection case, behavioural requirements emerged from governance design work. The documented examples include: “Every fraud control decision resulting in a block or step-up authentication must be attributable to a named, reviewable policy accessible in the same session”; “Policy evaluation sessions must not permit live policy modifications”; and “Risk analysts must be able to reconstruct decision logic for any historical event using only the interface, without system logs.”

Each Callsign example is specific, testable, interface-level, and connected to SCA and PCI DSS compliance rationale.

Puraite AI systematic review

In the Puraite AI systematic review case, behavioural requirements were derived from the epistemic independence requirement of systematic review methodology. The documented examples include: “In blinded mode, AI inclusion/exclusion decisions must not be visible before the reviewer has recorded their own decision” and “Override must require no more interaction than acceptance.”

These examples include both a constraint on when AI decisions may be visible and a requirement about the interaction cost of override.

Kardion MCS Controller

In the Kardion MCS Controller case, behavioural requirements were derived from IEC 62366-1 identified use-related hazards. The documented examples include: “Flow rate adjustment must require explicit two-step confirmation before taking effect” and “Muted alarms must remain visually present at reduced prominence.”

The Kardion MCS Controller evidence is identified as formative evaluation only.

Evidence basis and limits

The definition of behavioural requirement is conceptual. The examples are drawn from documented cases and show how the concept appears in specific design and governance contexts.

The documented case evidence supports the structure of the examples: Callsign relates behavioural requirements to SCA and PCI DSS compliance rationale; Puraite relates behavioural requirements to epistemic independence in systematic review methodology; and Kardion relates behavioural requirements to IEC 62366-1 identified use-related hazards.

The available examples do not establish that these are the only valid forms of behavioural requirement. They illustrate how behavioural requirements can be written when interface behaviour must be specified, evaluated, and traced to a rationale.