{"id":"1c87f80c-b03f-42be-b298-895a6c2c4058","arxiv_id":"2412.19668","paper_version":1,"verdict":"ACCEPT","confidence":"HIGH","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A software engineering research roadmap organized around four challenges derived from humans' proactive, reactive and passive roles with digital systems, plus trust and trustworthiness.","lead":"This paper argues that software engineers should design digital systems with human, societal and environmental values in mind, not just business goals. It lays out a research roadmap with four human-centric challenges and fourteen research directions for building systems that respect people and the planet.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The roadmap names environmental values as a core driver, but no research direction concretely addresses environmental sustainability, so the claimed HSE coverage is only nominal for one of its three pillars.","rationale":"The reader's weakest assumption concerns completeness of the tripartite human-role taxonomy and the HSE drivers drawn from the authors' prior work. My concern is related but more specific and internally grounded: even if the six drivers are accepted, the paper's stated environmental pillar is not operationalized in the roadmap. Reading the full text, environmental values appear in the motivation and in generic 'relevant for all values' remarks, but none of the 14 research directions proposes concrete environmental engineering work. This is a checkable inconsistency between the paper's declared scope and its delivered content. It is load-bearing because the central claim is a roadmap for HSE values; if environmental values are absent in substance, the claim is only partially supported. The proposed traceability test would settle whether the concern lands: if environmental terms appear substantially in several RDs, the concern is refuted and the roadmap's coverage is adequate. Since the authors explicitly concede incompleteness, the appropriate remedy is conditional acceptance: the roadmap should either concretely address environmental values or explicitly rescope the claim. This is not a fatal flaw, and the paper remains a valuable roadmap for human and societal aspects, which is why the verdict moves to CONDITIONAL rather than REJECT.","tokens_in":33162,"tokens_out":4995,"duration_ms":49853,"concrete_test":"Perform a traceability analysis of the 14 research directions: extract from the text of each RD all sentences containing environment-related terms such as 'environmental', 'energy', 'carbon', 'climate', 'sustainable', 'resource', 'e-waste', or 'footprint', excluding generic statements like 'relevant for all values'. Count how many RDs contain at least one concrete environmental research question, method, or artefact. If fewer than 2 of the 14 RDs do so, the roadmap does not substantively cover driver D1, and the paper should be revised either to add dedicated environmental directions (e.g., green AI, energy-aware architecture, carbon-aware V&V) or to explicitly narrow its claim to human and societal values with environmental aspects deferred to future work.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The paper's central claim is a research roadmap built on human, societal, and environmental (HSE) drivers, with D1 explicitly defined as 'Societal and environmental well-being.' Tracing the 14 research directions (RD1.1 through RD4.3) shows that environmental aspects appear only generically, such as 'relevant for all values' attached to several challenges (CH1.2, CH2.2, CH3.1, CH4.2, CH4.3), and in the high-level HSE-debt metaphor of RD3.4. No research direction proposes concrete work on energy efficiency, carbon footprint, resource consumption, e-waste, or the climate impact of digital systems. The roadmap thus substantively operationalizes human and societal values while leaving environmental values largely unaddressed. This is an internal inconsistency with the paper's stated scope, not merely a completeness limitation. The authors' external-validity caveat concedes that the roadmap may be incomplete, but the gap here is more specific: one of the three pillars explicitly named in the title and abstract is not concretely developed. If environmental values are intended as cross-cutting, the paper should say so and illustrate how each research direction would be instantiated for environmental concerns; otherwise the central claim that this is a roadmap for 'human, societal, and environmental' values is only partially supported.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper proposes a research roadmap for engineering digital systems for humanity. It argues that software engineering should consider human, societal, and environmental (HSE) drivers in addition to business and technology drivers. It identifies four macro-challenges based on human roles (proactive, reactive, passive, and a transversal trust/trustworthiness challenge) and derives 14 research directions organized into four groups: development process, requirements engineering, software architecture and design, and verification and validation. The roadmap is constructed using a design science methodology with three iterations, including literature review, a workshop at FSE 2024, and validation in three of the authors' research projects. The paper includes a threats-to-validity section acknowledging the incompleteness of the proposed drivers, challenges, and directions.","tokens_in":33399,"tokens_out":4930,"duration_ms":44647,"significance":"The paper addresses a timely and important problem: how to bring HSE values into software engineering practice, motivated by regulations such as the EU AI Act. Its main strengths are the explicit design science methodology, the clear structure of challenges and research directions, and the grounding in concrete projects (HALO, Robochor, EXOSOUL) and in the SE2030 workshop report. The roadmap has the potential to influence research agendas in responsible AI and human-centered software engineering. However, its significance is currently limited by the asymmetry between the human/societal and environmental pillars: environmental values are declared as a driver but are not developed into concrete research directions, which weakens the claim of covering HSE values comprehensively.","major_comments":[{"comment":"The roadmap does not concretely address the environmental pillar of the HSE drivers. Although D1 defines 'Societal and environmental well-being' and several challenges are tagged as 'relevant for all values' (CH1.2, CH2.2, CH3.1, CH4.2, CH4.3), none of the 14 research directions in Section 5 proposes concrete work on environmental sustainability, such as energy efficiency, carbon footprint, resource consumption, e-waste, or climate impact of digital systems. The only environmental-specific element is the high-level HSE-debt metaphor in RD3.4. Since the paper's title and abstract claim a roadmap for 'human, societal, and environmental' values, this asymmetry is a load-bearing gap rather than a mere completeness limitation. The authors should either add research directions that operationalize the environmental driver, or explicitly state that environmental values are treated as cross-cutting and illustrate how each direction would be instantiated for environmental concerns.","section":"Section 5, RD1.1–RD4.3; Section 3.3, D1"},{"comment":"The runtime-negotiation direction rests on the unstated assumption that 'HSE requirements are graduable' (Section 5.2, RD2.3). This assumption is load-bearing because the proposed shift from design-time tradeoffs to runtime negotiation requires that values can be relaxed or downgraded, and the paper does not discuss which values admit degrees of satisfaction or how to handle non-negotiable values (e.g., human dignity, safety). The authors should either justify the graduability assumption, or delimit the class of HSE requirements to which runtime negotiation applies.","section":"Section 5.2, RD2.3"},{"comment":"The mapping between challenges and research directions is asserted rather than derived. The paper states that the roadmap was built 'on' the drivers and challenges (Section 5) and presents the mapping in Figure 4, but the text does not explain the criteria for associating a challenge with a direction, nor is there an evaluation of the mapping's completeness or redundancy. The validation is carried out within three projects involving all co-authors and reuses several of the authors' prior frameworks (EXOSOUL, SLEEC compilation, specification patterns). This self-supporting structure, acknowledged in the external-validity paragraph of Section 2, leaves the central claim of the roadmap largely dependent on the authors' own judgment. I would expect at least a more systematic derivation of the mapping or an external validation step to strengthen the roadmap's credibility.","section":"Section 2, Methodology; Figure 4"}],"minor_comments":[{"comment":"There are apparent typographical errors: 'environemnt' should be 'environment' and 'reseach' should be 'research'.","section":"Section 1, first paragraph"},{"comment":"'Easy of use' should be 'Ease of use'.","section":"Section 4.1, CH1.1"},{"comment":"The term 'Seamless DevExe' is used without definition; consider introducing it before using it.","section":"Section 5.1, RD1.2"},{"comment":"'Bruxelles effect' is a misspelling of 'Brussels effect'.","section":"Section 5.4, RD4.3"},{"comment":"The mappings between drivers, challenges, and research directions are presented only as figures; a table or a more detailed verbal explanation would improve accessibility and traceability.","section":"Figures 3 and 4"},{"comment":"The description of SLEEC rules and their translation to formal languages could be clarified with a concrete example or a workflow diagram.","section":"Section 5.2, RD2.2"}],"recommendation":"major_revision","confidential_remarks":"The manuscript relies substantially on the authors' own prior publications (e.g., [100], [6], [99], [84–85]) for the central drivers and several research directions. This is not inappropriate for a roadmap paper, but the editor may want to consider whether an external validation step would increase confidence. The paper is a position/roadmap paper; if the journal accepts such contributions, the environmental gap is the main weakness to address."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know two things about this one. First, it is a genuine synthesis: the four-challenge framing around proactive, reactive, and passive human roles plus trust/trustworthiness is a useful organizing device, and the 14 research directions are concrete enough to react to. Second, the environmental pillar of the HSE triad is mostly nominal. D1 names 'societal and environmental well-being,' and several challenges carry a 'relevant for all values' tag, but no research direction actually targets energy efficiency, carbon footprint, e-waste, or climate impact of software. RD3.4's HSE-debt metaphor nods at environmental cost, but as a metaphor, not as a direction. That is an internal imbalance, not just the usual completeness caveat. The authors should either add an explicit environmental research direction or state plainly that HSE directions are cross-cutting and illustrate how each would instantiate for environmental concerns. As written, the roadmap delivers on human and societal values and only gestures at environmental ones.\n\nWhat the paper does well: the design-science methodology is documented honestly, with three iterations and a real threats-to-validity section. The authors concede they cannot claim completeness, and they name their validation context—their own projects (HALO, Robochor, EXOSOUL) and the SE2030 workshop. That is a real limitation: the challenge-to-direction mapping is asserted through figures and tables rather than independently derived, and several load-bearing pieces (SLEEC rules, specification patterns, the EXOSOUL approach) come from the authors' own prior work. But they do not hide this, which counts for something. The paper is also well-positioned against current regulation and prior roadmaps like Lu et al.'s responsible-AI work and the SE2030 report; the novelty is the synthesis, not the ingredients.\n\nThe tripartite human-role taxonomy is borrowed from HCI and is plausible, though the paper does not defend it as exhaustive. The authors explicitly disclaim completeness, so I would not hammer this too hard.\n\nBottom line: this deserves a serious referee. It is a roadmap, not a falsifiable result, but it is a well-grounded agenda that the SE community will actually want to react to. A good referee will push on the environmental gap and on the self-referential validation, but neither sinks the paper. I would accept it with revisions, and I would want the environmental issue addressed before publication.","headline":"A solid, well-structured SE roadmap that honestly owns its limits, but the environmental pillar is thin where the title promises a third of the scope.","tokens_in":648,"tokens_out":1331,"would_cite":true,"duration_ms":375952,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper argues that software engineering should treat human, societal, and environmental values as first-class drivers and offers a 14-direction research roadmap derived from the roles humans play with digital systems.","keywords":["human values","societal values","environmental values","research roadmap","software engineering","human roles","trustworthiness","digital systems for humanity"],"falsifier":"An empirical study that documents a mode of human-system coexistence that none of the proactive, reactive, or passive roles can describe, or an expert elicitation that surfaces a stakeholder need not captured by the six HSE drivers, would falsify the claimed coverage. The paper's own external-validity concession marks this as the point most likely to fail.","tokens_in":32956,"feed_emoji":"🧭","tokens_out":6163,"duration_ms":51140,"temperature":0.7,"pith_summary":"Software systems are usually built to satisfy business goals and follow technology drivers; the paper argues that this is no longer enough. Because digital systems now mediate jobs, lending, care, and public life, engineering must treat human, societal, and environmental (HSE) values as first-class drivers. To make that concrete, the paper organizes the problem around four human-system challenges: humans as proactive programmers of systems, humans reacting to system events, humans passively affected by system decisions, and the cross-cutting pair of trust and trustworthiness. From six HSE drivers and these four challenges it derives a roadmap of 14 research directions in four engineering areas: development process, requirements engineering, software architecture and design, and verification and validation. The point of the roadmap is to give software engineers a concrete agenda for making their work accountable to the people and societies it serves.","feed_headline":"14 research directions put human values into engineering","feed_subtitle":"The roadmap organizes software engineering around three human roles — proactive, reactive, passive — plus trust.","key_machinery":"The organizing device is a taxonomy of human roles, defined by whether the human initiates, reacts to, or is affected by the system: proactive roles need accessible continuous programming languages and monitoring, reactive roles need ethical interaction and adjustable autonomy, and passive roles need fairness, transparency, and new quality standards. The fourth component, trust versus trustworthiness, separates the human's subjective acceptance from the system's objective safe-and-secure design. The paper also uses explicit two-step mappings—HSE drivers to challenges, and challenges to research directions—so that every research direction is traceable back to a driver.","core_discovery":"The paper's central claim is that human, societal, and environmental values belong in the engineering loop as requirements, not as afterthoughts or external constraints. It identifies six HSE drivers—societal and environmental well-being, accountability, privacy and data governance, human agency and oversight, transparency and explainability, and diversity, non-discrimination, and fairness—and maps them to four macro challenges. Each challenge corresponds to a human role in coexisting with digital systems: continuous systems programming for the proactive human, human-system interaction for the reactive human, digital-systems impact for the passive human, and trust versus trustworthiness as a transversal challenge. The roadmap then translates these challenges into 14 research directions, including seamless development-execution processes, runtime negotiation of HSE requirements, new architecture tactics, and field-based verification and continuous compliance.","pith_inferences":["The paper leaves the 14 research directions unprioritized; a natural next step would be to map dependencies among them, for instance runtime negotiation presupposes elicitation and specification of HSE requirements.","The HSE-debt metaphor could be made operational by borrowing technical-debt measurement ideas, but that would require defining metrics for the cost of not addressing values, which the paper does not supply.","The quality-label analogy for measuring trust-related qualities could eventually support standardized value labels for AI services, but the paper only hints at such a scheme.","The role taxonomy could be tested empirically on current AI assistants: a user who neither initiates, responds, nor is merely affected—but co-constructs behavior through implicit signals—would strain the taxonomy and reveal whether a fourth role is needed."],"forward_implications":["Requirements engineering must treat qualities such as fairness, accountability, and transparency as first-class, possibly re-opening existing quality models like ISO/IEC 25010.","Systems should support continuous programming by non-expert users after deployment, with equally continuous monitoring, assessment, and compliance.","Design-time tradeoffs among values give way to runtime negotiation, because HSE profiles are subjective, evolving, and can conflict among the humans sharing a system.","Verification and validation must move into the field and cover the whole lifecycle, since autonomy, adaptation, and post-market updates defeat design-time-only assurance.","Software engineering research and universities may take on governance roles, producing frameworks that protect humans rather than only optimizing technology."],"supporting_citations":[{"why":"Supplies the stakeholders' needs from which the six HSE drivers are taken.","marker":"[100]"},{"why":"Workshop report used to validate the challenges and inform the research directions.","marker":"[98]"},{"why":"Defines the trust/trustworthiness distinction and provides responsible-AI best practices used as a reference.","marker":"[75]"},{"why":"The AI Act motivates continuous compliance and several new quality requirements.","marker":"[77]"},{"why":"Argues for engineering value-based ecosystems, the backdrop for treating HSE values as architectural drivers.","marker":"[95]"},{"why":"Software-exoskeleton approach that grounds the continuous-programming and ethical-profiling directions.","marker":"[9]"},{"why":"Ethics guidelines that serve as a source for several HSE drivers.","marker":"[58]"},{"why":"Existing roadmap on software engineering for responsible AI that the paper extends and differentiates.","marker":"[76]"}],"fun_headline_variants":["Four human roles, 14 research paths: engineering for society","Proactive, reactive, passive: a 14-direction software roadmap","Human values as requirements: a 14-point engineering agenda","Software that accounts for people: a 14-direction roadmap","Four roles, 14 research directions to put humans first"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The roadmap's value depends on the assumption that the three human roles plus trust/trustworthiness cover the whole space of human coexistence with digital systems, and that the chosen HSE drivers are the right ones; the paper explicitly says it cannot claim these sets are complete.","fun_headline_variants_meta":{"raw":{"variants":["Four human roles, 14 research paths: engineering for society","Proactive, reactive, passive: a 14-direction software roadmap","Human values as requirements: a 14-point engineering agenda","Software that accounts for people: a 14-direction roadmap","Four roles, 14 research directions to put humans first"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00196,"raw_usage":{"total_tokens":7668,"prompt_tokens":960,"completion_tokens":6708,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":576,"completion_tokens_details":{"reasoning_tokens":6624}},"tokens_in":576,"tokens_out":6708,"duration_ms":52246,"temperature":1.0,"reasoning_tokens":6624,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T23:59:08.962650+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"An empirical study that documents a mode of human-system coexistence that none of the proactive, reactive, or passive roles can describe, or an expert elicitation that surfaces a stakeholder need not captured by the six HSE drivers, would falsify the claimed coverage. The paper's own external-validity concession marks this as the point most likely to fail.","supporting_citations":[{"cited_title":"Available at: https://unstats.un.org/ sdgs/!les/report/2024/SG-SDG-Progress-Report-2024-advanced-unedited-version.pdf","cited_arxiv_id":null,"evidence_quote":"Supplies the stakeholders' needs from which the six HSE drivers are taken."},{"cited_title":"Proceedings of the AAAI Conference on Arti \"cial Intelligence 35, 13 (May 2021), 11657–11665","cited_arxiv_id":null,"evidence_quote":"Argues for engineering value-based ecosystems, the backdrop for treating HSE values as architectural drivers."}],"review_version":1}