Functional Trustworthiness

• Functional trustworthiness is defined as a system’s ability to operate correctly, safely, and reliably in a given context with measurable evidence.
• Specification of detailed functional requirements and constraints, including performance, safety, and ethical considerations, is essential for verification.
• Evidence-based testing and maturity models help validate both functional behavior and non-functional qualities in diverse application domains.

Searching arXiv for recent and foundational papers on functional trustworthiness, specification, and evaluation. Search query: functional trustworthiness trustworthiness specification verification arXiv Functional trustworthiness denotes the aspect of trustworthiness that is anchored in what a system actually does in context, under what conditions it does it, and what evidence justifies reliance on that behavior. Across the literature, it is treated not as a purely psychological notion of trust, but as a property of systems that “work properly in $C$” and whose relevant functional behaviors can be specified, measured, and, where possible, justified to stakeholders through verification, explanation, or assurance evidence (Kästner et al., 2021). In autonomous systems and soft robotics, this idea is formulated through explicit functional requirements together with non-functional constraints such as reliability, safety, adaptability, ethics, and regulation; in statistically oriented work it is framed as a testable property of the learned function under a well-defined application distribution; and in communication and cyber-physical settings it is expressed through measurable trustworthiness characteristics and runtime indicators linked to concrete threats and operating conditions (Abeywickrama et al., 2023).

1. Conceptual framing

Functional trustworthiness is not introduced as a single universally fixed term across the cited literature, but a common core recurs. One influential definition states that a system $S$ is trustworthy to a stakeholder $H$ in a context $C$ if and only if “$S$ works properly in $C$” and “$H$ would be justified to believe that (a) if $H$ came to believe that (a)” (Kästner et al., 2021). The first condition supplies the functional core: the system behaves as it ought to behave in context; the second adds the epistemic condition that justified belief in that proper functioning must in principle be available.

A second line of work makes this functional core explicit by defining “functional trustworthiness” as “all those aspects of trustworthiness that are directly dependent on the specific properties of the ML function itself, which is the result of the data-dependent optimization or learning algorithm” (Nessler et al., 2023). In that view, trustworthiness lies “first and foremost in the correct statistical testing on randomly selected samples and in the precision of the definition of the application domain,” and this testable quality includes “a design, development, and deployment that enables correct statistical testing of all relevant functions” (Nessler et al., 2023).

In specification-centered work on autonomous systems, functionality is treated as a first-class aspect of trustworthiness alongside resilience, trust, verifiability, security, and governance and regulation (Abeywickrama et al., 2022). In soft robotics, trustworthiness is built around a selected set of core properties—predictability, reliability, adaptability, safety, ethics, and regulations—and functional trustworthiness emerges from the way the gripper’s concrete behaviors are specified together with the constraints under which those behaviors remain acceptable (Abeywickrama et al., 2023).

This suggests a general synthesis: functional trustworthiness concerns whether a system’s task-level behavior is correct, reliable, safe, and context-appropriate, and whether those claims can be substantiated by evidence proportionate to the stakes and the deployment setting.

2. Functional and non-functional structure

The distinction between functional and non-functional requirements is central. One specification-oriented account explicitly adopts ISO 24765:2017 and defines functional requirements as “those that specify behaviour the system shall perform,” whereas non-functional requirements “specify not what the system will do but how it will do it (quality attributes)” (Abeywickrama et al., 2023). Functional trustworthiness therefore does not reduce to mere task completion. It arises from the interaction between what the system does and how well, how safely, and under what normative constraints it does it.

In the soft gripper case study, the functional core includes grasping, holding, transporting, and placing grocery items without damage. Representative requirements include actuation behavior—fingers curving when inflated and straightening when deflated—task-level success, and robust grasping across variations in size, shape, deformability, and orientation (Abeywickrama et al., 2023). For example, the paper specifies: “The gripper shall grasp, transport, and place an item successfully with a repeatability of $\ge 95\%$,” and requires holding an item without dropping it for at least 10 seconds, 95% of the time (Abeywickrama et al., 2023).

The same literature stresses that non-functional properties are not external add-ons. Predictability constrains the relation between input pressure and finger curvature; reliability constrains dropping and damaging rates across trials and operational lifetime; safety imposes force and deformation bounds on grasping; ethics and regulations constrain allowable physical form factors, environmental effects, and worker impacts (Abeywickrama et al., 2023). Thus, “the system must do the right things (functional) and do them in the right way and with evidence (non-functional)” (Abeywickrama et al., 2023).

A broader AI-oriented account sharpens the same point by observing that “works properly in $C$” is not exhausted by satisfying written requirements. The system may also need to be reliable, safe, fair, and just, even when these properties were not explicitly requested (Kästner et al., 2021). Functional trustworthiness, in this sense, includes not only formal functional correctness but also those normative and quality-of-service properties without which correct functioning in context would be a misdescription.

3. Specification as the basis of functional trustworthiness

A recurring claim is that functional trustworthiness must be specified before it can be assured. “A specification is a detailed formulation that provides ‘a definitive description of a system for the purpose of developing or validating the system’” (Abeywickrama et al., 2022). In autonomous systems, specification is presented as the precondition for synthesis, formal verification, runtime verification, and testing (Abeywickrama et al., 2022). In soft robotics, the relative neglect of specifications is identified as a barrier to demonstrating trustworthiness even in a mature subfield such as soft grippers (Abeywickrama et al., 2023).

The soft gripper specification illustrates a semi-formal style based on structured “shall” statements with actor, modal verb, behavior, condition, and quantitative threshold (Abeywickrama et al., 2023). Requirements such as pressure range $S$0 to $S$1 psi, flow rate between $S$2 and $S$3 L/min, maximum translation velocity $S$4, and maximum acceleration $S$5 provide operational envelopes within which the required behavior is expected to be predictable and reliable (Abeywickrama et al., 2023). Safety-critical constraints are likewise quantified, including grip force limits for hard-fragile and soft-fragile items and fingertip displacement bounds for delicate produce (Abeywickrama et al., 2023).

The same design pattern appears in communication systems, where trustworthiness is decomposed into “trustworthiness characteristics” with corresponding “TC controls” and “TC measurements” (Fettweis et al., 2024). The cited characteristics include accountability, authenticity, availability, confidentiality, integrity, privacy, reliability, resilience, accuracy, controllability, robustness, safety, transparency, usability, benevolence, functional/non-functional capabilities, and intervenability (Fettweis et al., 2024). Here too, functional trustworthiness is cast as a structured set of system-level properties rather than a single scalar label.

In statistically valid testing for AI systems, specification takes the form of three necessary elements: “(1) the definition of the technical distribution of the application, (2) the risk-based minimum performance requirements, and (3) the statistically valid testing based on independent random samples” (Nessler et al., 2023). The “technical distribution” is a process-like definition of how random samples are generated, precise enough that independent engineers could in principle draw test cases from the intended deployment domain (Nessler et al., 2023). This formulation is explicitly intended to make functional trustworthiness testable rather than rhetorical.

4. Verification, testing, and evidence

Functional trustworthiness is treated throughout this literature as inseparable from evidence. In one formulation, verification is “the process that can be used to increase confidence in the system’s correctness against its specification,” while verifiability means that “a person or a tool must be able to check its correctness in relation to its specification” (Abeywickrama et al., 2023). The same work argues that verifiability should be a first-class design objective, and demonstrates practices such as numeric thresholds, traceable requirement identifiers, refinement of vague requirements into precise sub-requirements, and explicit verification methods including observation, unit tests, edge-case testing, life-cycle testing, and sensor-based measurement (Abeywickrama et al., 2023).

A stronger statistical position argues that for high-dimensional learned systems, formal proofs of correctness are generally unrealistic, but probabilistic guarantees based on independent random samples from a well-defined application distribution are not (Nessler et al., 2023). The paper rejects conformity assessment regimes that rely mainly on documentation or vague representativeness claims and instead insists on measurable functional properties of the final learned function. Typical performance quantities include accuracy,

$S$6

sensitivity, specificity, false positive rate, and false negative rate, together with confidence bounds derived from statistically valid testing (Nessler et al., 2023).

A different operationalization appears in utility-centered work on predictive models. There, trustworthiness is defined relative to a class of utility functions $S$7: a model $S$8 is $S$9-trustworthy if no alternative model yields higher maximum expected utility for any $H$0 (Vashistha et al., 2024). The paper argues that calibration is neither necessary nor sufficient for this form of trustworthiness and instead advocates AUC as a preferred measure when optimal decisions are threshold-based. Its formal claim is that properly ranked models are inherently $H$1-trustworthy, and that AUC aligns with that competence notion more closely than calibration-based metrics in the studied setting (Vashistha et al., 2024).

Maturity-model work adds a complementary perspective: evidence of trustworthiness must be communicated dimension by dimension rather than collapsed into a single opaque score. The Trust Calibration Maturity Model evaluates Performance Characterization, Bias & Robustness Quantification, Transparency, Safety & Security, and Usability on four maturity levels from “Not addressed” to “Comprehensive,” with the explicit purpose of helping users appropriately calibrate trust to the maturity of the available evidence (Steinmetz et al., 28 Jan 2025). This suggests that functional trustworthiness depends not only on technical performance but on the maturity with which that performance and its limits are characterized.

5. Domain-specific instantiations

In soft robotics, functional trustworthiness is instantiated as the reliable execution of the entire pick-and-place pipeline under quantified environmental variation. The warehouse setting includes soft-fragile, soft-non-fragile, hard-fragile, and hard-non-fragile objects, with clutter, varying orientations, and deformable items (Abeywickrama et al., 2023). Trustworthy operation therefore requires not merely grasping in a laboratory sense but context-conditional performance across object classes and motion phases—pre-grasping, ascension, translation, and descension—with explicit numeric bounds (Abeywickrama et al., 2023).

In autonomous systems more broadly, specification challenges arise from open, uncertain, dynamic environments. Examples include automated driving, where machine-readable encodings of rules such as “move back to the left as soon as you can but do not cut in” must coexist with assumptions about other road users; UAVs, where acceptable behavior in situations beyond the training regime remains difficult to specify; swarm robotics, where system-level emergent behavior rather than individual controllers must be specified; human–robot interaction, where correct assistance depends on perceptual, reasoning, and behavioral processes about human mental states; healthcare AI, where diagnostic performance must remain reliable across populations and devices; and emergency response, where SLEEC norms must constrain functional behavior under time pressure (Abeywickrama et al., 2022).

In communication systems and the Tactile Internet, functional trustworthiness is framed through trustworthiness characteristics such as reliability, resilience, safety, controllability, privacy, and intervenability (Fettweis et al., 2024). The paper links these to robotic and teleoperation contexts in which functional safety depends directly on communication properties such as availability, integrity, and timeliness, and proposes “trustworthiness by design/default” together with two architectural meta-requirements: auditability and reputation (Fettweis et al., 2024).

In cyber-physical and IoT systems, trustworthiness is assessed through operational indicators tied to concrete threats. For an ultra-wideband localization service, the adopted definition is the “demonstrable likelihood that the system performs according to designed behavior under any set of conditions as evidenced by characteristics including, but not limited to, safety, security, privacy, reliability and resilience” (Peterseil et al., 2024). The framework uses metrics such as temperature, battery voltage, RSSI, anomaly detection on channel impulse responses, PDoP, number of anchors, encryption, authentication, secure ranging, and dynamic addressing. These are mapped to normalized indicators in $H$2, aggregated into reliability, resilience, security, and privacy indices, and then into an overall trustworthiness index by a non-compensatory minimum operator (Peterseil et al., 2024).

In LLMs, the same problem appears under different names. TrustLLM separates “utility (i.e., functional effectiveness)” from eight trustworthiness dimensions—truthfulness, safety, fairness, robustness, privacy, machine ethics, transparency, and accountability—and empirically reports that trustworthiness and utility are “positively related,” while also warning that some models may be overly calibrated toward exhibiting trustworthiness and thereby compromise utility by mistakenly treating benign prompts as harmful (Huang et al., 2024). This suggests that functional trustworthiness for general-purpose models is not reducible to raw task effectiveness, but neither is it independent of it.

6. Debates, trade-offs, and open questions

A persistent controversy concerns trust versus trustworthiness. One account argues that explanations do not reliably increase trust and can even reduce it when they reveal faults, but that this is not a defect of explainability. The design target should be trustworthiness rather than trust, because trust is a volatile psychological attitude, whereas trustworthiness is comparatively under engineering control (Kästner et al., 2021). From this perspective, explainability contributes to trustworthiness by supporting justified belief, not by guaranteeing positive affect or adoption.

A second debate concerns whether trustworthiness can be meaningfully aggregated into a single number. Communication-oriented work distinguishes between a vector of trustworthiness characteristics and a possible scalar score, noting the trade-off between preserving detail and enabling comparison, and further differentiates “absolute” and “relative” trustworthiness values that may be time-invariant or context-dependent (Fettweis et al., 2024). Maturity-model work similarly avoids a single composite metric and instead reports separate maturity levels across dimensions (Steinmetz et al., 28 Jan 2025). This suggests that functional trustworthiness is inherently multidimensional, even when a system ultimately requires a decision rule about acceptability.

Another controversy concerns the balance between normative and functional views. A recent position paper distinguishes Functional Trustworthy AI (FTAI), concerned with technical design, implementation, and behavior, from Normative Trustworthy AI (NTAI), concerned with regulations and principles, and argues that current practice lacks a semantic bridge between the two (Scala et al., 19 Dec 2025). The proposed remedy is a conceptual language that maps system components and functions to trustworthiness aspects through relations such as supports, negativelyAffects, and possiblyAffects, thereby connecting concrete system behavior to normative obligations (Scala et al., 19 Dec 2025). A plausible implication is that functional trustworthiness remains incomplete when it cannot be related back to legal and ethical expectations in a traceable way.

Open questions recur across the cited work. They include how to operationalize “works properly” in different domains; how to specify and verify evolving functionality; how to measure trustworthiness in contexts where current metrics are weak or absent; how to reason about trade-offs such as confidentiality versus availability, security versus usability, and privacy versus accountability; and how to maintain justified trust under deployment drift, model updates, and sociotechnical change (Abeywickrama et al., 2022). The literature is consistent, however, on one point: functional trustworthiness cannot be established by vague aspiration alone. It requires explicit specification of behavior in context, measurable criteria, and evidence that survives contact with the actual conditions of use.