---
title: 'SustainableQA: A QA Paradigm for Sustainability'
url: https://www.emergentmind.com/topics/sustainableqa
type: topic
---

# SustainableQA: A QA Paradigm for Sustainability

SustainableQA denotes a sustainability-oriented question-answering and assessment paradigm that appears in two closely connected forms. In one form, it is a “large-scale, domain-specific QA dataset” and “a scalable, semi-automatic pipeline” for corporate sustainability, ESG, and EU Taxonomy reporting. In another, it functions as a sustainability-aware analysis layer over software engineering artifacts, research data, research software, and software architecture decisions, where sustainability is treated as a software quality concern, a requirements concern, or a metadata concern [2508.03000][2606.29439][1309.1640]. Taken together, these strands suggest an umbrella concept: question answering and quality assessment grounded in explicit sustainability models, traceable artifacts, measurable indicators, and reproducible evidence.

## 1. Conceptual scope and definitions

Across the cited work, sustainability is not reduced to a single scalar notion. “Towards a Software Product Sustainability Model” places sustainability inside software quality and treats it as “part of its quality” and “related to non-functional requirements,” with short-term concerns centered on **Energy Consumption** and **Resource Optimization**, and long-term concerns centered on **Perdurability** [1309.1640]. The SAF Toolkit treats sustainability as a software quality property distributed across **technical**, **environmental**, **economic**, and **social** dimensions, and explicitly combines these with a **time dimension** expressed through first-order, second-order, and third-order effects [2405.01391]. JI-RADAR adopts the five-dimensional SuSAF view—**Environment**, **Technical**, **Social**, **Economic**, and **Individual**—for requirements engineering and KPI reporting, while FAIR+S introduces a fifth FAIR-aligned dimension, **Sustainable**, through the principles **S1–S5** [2606.29439][2606.30663].

These sources use different operational vocabularies, but they share a common structure: sustainability is represented through artifacts, metrics, traceability links, and reviewable evidence. That shared structure is what makes a SustainableQA layer possible.

| Manifestation | Core artifact | Scope |
|---|---|---|
| QA benchmark | 195,287 QA pairs from 61 corporate reports | ESG, EU Taxonomy, Sustainability |
| Jira-centered RE layer | JI-RADAR plugin with SuMM, Sustainability Needs, Sustainability Stories | Issues, User Stories, Epics, Tasks, Sprints |
| Requirements framework | SEER with SR Elicitor, Relationship Integrator, Sustainability Optimizer | FR, NFR, SR alignment |
| Quality and architecture evaluation | Sustainability characteristic, Decision Map, SQ Model, SIS | NFRs, QA trade-offs, architecture alternatives |
| Metadata and research infrastructure | Sustainability Model Cards; FAIR+S | training, inference, platform, FAIR-aligned metadata |

A recurring implication is that SustainableQA is not confined to answering questions about sustainability documents. It also encompasses asking whether a requirement harms **energy efficiency**, whether an architectural decision improves **traceability** but worsens **resource utilization**, whether a model card is complete enough for sustainability-aware selection, or whether a research artifact is auditable under **S1–S5**.

## 2. Corporate sustainability reporting and document-grounded QA

The most explicit use of the name appears in “SustainableQA: A Comprehensive Question Answering Dataset for Corporate Sustainability and EU Taxonomy Reporting,” which defines SustainableQA as both a dataset and a generation pipeline for question answering over corporate sustainability reports and annual reports [2508.03000]. The dataset is built from **61 corporate reports** from German and Austrian listed companies and contains **195,287** QA pairs: **191,331** from text passages and **3,956** from tables. It covers three categories—**ESG**, **EU Taxonomy**, and **Sustainability**—with **8,067** text passages and **218** table passages. Factoid questions dominate short-span retrieval, while non-factoid questions require explanatory answers of **1–4 sentences**; table-based questions are generated after a specialized table-to-paragraph transformation. Factoid answer complexity is nontrivial: **83.3%** are single-span and **16.7%** are multi-span, with EU Taxonomy questions showing the highest multi-span share at **21.2%**.

The pipeline combines semantic passage classification, hybrid span extraction, and LLM-based QA generation. Passages are classified by **Llama 3.3 (70B)** into **EU Taxonomy**, **ESG**, **Sustainability**, or **Unknown**. Factoid spans are proposed by a fine-tuned **xlm-roberta-base-esg-ner**, regular expressions, and **spaCy PhraseMatcher**, then refined in two stages by **GPT-4o**. Large EU Taxonomy tables are converted into text paragraphs with **Gemini 2.5 Flash Chat**, followed by manual review and downstream QA generation. Human evaluation used **3 annotators** over **300 QA pairs**; **Krippendorff’s $\alpha$** ranged from **0.69–0.78**, with average scores of **4.2/5.0** for Question Quality, **4.1/5.0** for Answer Accuracy, **4.0/5.0** for Context Appropriateness, and **3.8/5.0** for Practical Utility. In benchmarking, fine-tuning proved decisive: **Llama 3.1 8B-FT** achieved **50.30% EM** and **54.28% F1** on factoid QA, **50.82% ROUGE-L** on non-factoid QA, and **70.14% ROUGE-L** on tabular QA, outperforming much larger base models.

In this document-centric sense, SustainableQA is a benchmark for retrieval-augmented generation, extraction, multi-span reasoning, and table-grounded compliance support. It is closely aligned with **CSRD** and **EU Taxonomy** workflows, but its underlying design—semantic chunking, domain-specific span extraction, and grounded answer generation—also generalizes to software sustainability artifacts.

## 3. Requirements engineering and traceable software artifacts

JI-RADAR operationalizes sustainability inside day-to-day requirements engineering by embedding it directly into Jira workflows [2606.29439]. It extends Atlassian Jira Cloud through a plugin that supports sustainability-aware elicitation, documentation, analysis, prioritization, and traceability. Its conceptual core is the **Sustainability Management Model (SuMM)**, a “weighted decision matrix” over the five SuSAF dimensions: **Environment**, **Technical**, **Social**, **Economic**, and **Individual**. Projects can select dimensions, assign weights, and configure assessment questions. Each relevant artifact—**Tasks, User Stories, Epics**—receives a **Sustainability Assessment** section with a Likert-scale wizard: **1 = Direct Negative Impact**, **2 = Indirect Negative Impact**, **3 = No Impact**, **4 = Indirect Positive Impact**, **5 = Direct Positive Impact**, plus **Indifferent**. The plugin also models **Sustainability Needs** and **Sustainability Stories**, links them to ordinary Jira items, and aggregates issue-level assessments into **Sprint KPI Reports** and **Product KPI Reports** with **weighted KPIs, heatmaps, trend graphs**, sprint filters, dimension filters, and **CSV** export. A pilot study with **$N=4$** participants reported that capture and assessment of sustainability information both achieved a **median of 4.5 out of 5**.

SEER relocates the same concern even earlier, to the requirements engineering phase itself [2510.08981]. It has three stages: **SR Elicitor**, **Relationship Integrator**, and **Sustainability Optimizer**. The framework derives project-specific sustainability requirements from a general taxonomy spanning **Environmental**, **Social**, **Economic**, and **Technical** dimensions, then evaluates semantic relatedness between **FRs**, **NFRs**, and **SRs**, and finally rewrites requirements that negatively affect sustainability. The related-pair extractor uses a fine-tuned sentence transformer and regards a pair as semantically related if
$$
\cos(e(r_a), e(r_b)) \ge 0.65.
$$
The relation extractor classifies related pairs as **positive**, **negative**, or **neutral**. SEER was evaluated on four projects—**Smart Home**, **Healthcare**, **E-commerce**, and **Transport System**. Its training data for relatedness comprised **5,000** labeled requirement pairs, and the best threshold yielded **Precision 98%**, **Recall 93%**, and **F1 95%** for related pairs. The optimizer then rewrites negatively correlated requirements and re-runs the relation analysis; in the reported experiments, most negative pairs became positive or neutral after optimization.

Both systems treat sustainability as a first-class RE concern, but they differ in emphasis. JI-RADAR is artifact- and workflow-centric: it structures assessments, KPIs, and traceability inside Jira. SEER is reasoning-centric: it derives **SRs**, classifies requirement relations, and rewrites problematic requirements. A SustainableQA layer can use either pattern: structured issue-level evidence, or taxonomy-plus-RAG reasoning over FR/NFR/SR relationships.

## 4. Architecture-centric and product-quality assessment

At the product-quality level, “Towards a Software Product Sustainability Model” proposes **Sustainability** as a new characteristic in the ISO/IEC 25010 software product quality model [1309.1640]. Its sub-characteristics are **Energy Consumption**, **Resource Optimization**, and **Perdurability**. The paper defines **Energy consumption** as the “Degree to which the amounts of energy used by a software product when performing its functions meet requirements” and **Resource optimization** as the “Degree to which the amounts and types of resources used by a product when performing its functions meet sustainability requirements.” For long-term sustainability it introduces **Perdurability**, defined as “the degree to which a software product can be modified, adapted and reused in order to perform specified functions under specified conditions for a long period of time.” This directly supports a SustainableQA interpretation in which sustainability is specified as NFRs, measured through indicators, and evaluated alongside other ISO 25010 characteristics.

The SAF Toolkit extends that position to architecture modeling and trade-off reasoning [2405.01391]. Its core instruments are the **Decision Map (DM)** and the **Sustainability-Quality (SQ) Model**, supported by a **Decision Graph**, **SQ Model Template**, and **Interdimensional Dependency Matrix (DMatrix)**. The DM represents **features**, **design concerns**, **quality attributes**, their **positive**, **negative**, or **undecided** effects, and their placement in **first-order**, **second-order**, or **third-order** impact levels. The SQ Model then turns those concerns into defined QAs with metrics, classified across **technical**, **environmental**, **economic**, and **social** dimensions. The DMatrix makes cross-dimensional dependencies explicit, using `+`, `–`, and `I` to encode how one QA tends to influence another. Over a decade of applications, including **KPMG Qubus**, **Mobility as a Service – City of Amsterdam**, **Food Security in Low-Resource Environments**, **Responsible Flight Planning**, and industrial feature-variability cases, the toolkit has been used to surface trade-offs between performance and energy, accessibility and efficiency, and equity and environmental priorities.

The **Sustainability Impact Score (SIS)** adds an explicit quantification step for QA trade-offs at architecture level [2501.17004]. For two sustainability dimensions \(dim_1\) and \(dim_2\), the improved score is
$$
\text{SIS}_{dim1, dim2} =
\sum_{i=1}^{n} \sum_{j=1}^{m}
\bigl( \text{Priority}_{dim1\_i} + \text{Priority}_{dim2\_j} \bigr)
\times \text{Impact}_{ij}.
$$
Priorities are derived from **importance** and **risk** using
$$
\text{Priority}_{S_i} = w_I \cdot I + w_R \cdot R,
$$
with \(I,R \in \{\text{High}=3,\text{Medium}=2,\text{Low}=1\}\), followed by min–max normalization to \([0.1,1]\). In the industrial **MMvIB** case, the **multi model** architecture achieved **76.51%** normalized \(SIS_{T-Ec}\), **100.00%** normalized \(SIS_{T-S}\), and **100.00%** normalized \(SIS_{S-Ec}\), but **0.00%** normalized \(SIS_{T-En}\); the **single model** architecture scored **28.41%** on \(SIS_{T-En}\) and **0.00%** on the other three reported normalized SIS values. The result is a concrete illustration of a recurring SustainableQA pattern: technical decisions may improve economic and social sustainability while worsening environmental sustainability.

## 5. Metadata, research infrastructures, and scientific software sustainability

For AI systems, “Towards Sustainability Model Cards” defines a **Domain-Specific Language** and **Sustainability Model Cards** that formalize sustainability information for models and make it machine-readable [2507.19559]. The metamodel organizes information into **Metadata**, **Training**, **Inference**, and **Platform**. It records **energyConsumption**, **carbonEmissions**, **waterConsumption**, **platform**, and **timestamp** for both training and per-task inference, plus **energySources**, **energyMix**, and **CarbonOffsetCredit** at platform level. The concrete syntax is YAML, with sections for `meta_data`, `training`, `inference`, `platforms`, and `energy_sources`. In SustainableQA terms, this provides a queryable substrate for questions such as model comparison, SLA checking, or deployment selection based on energy, CO\(_2\), water, hardware, and region.

FAIR+S extends the same logic to research data and software metadata [2606.30663]. It keeps FAIR and FAIR4RS intact and adds a separate sustainability dimension through **S1 – Energy Efficiency Attributes**, **S2 – Sustainability Benchmarks**, **S3 – Alignment with Sustainability Frameworks**, **S4 – Carbon Transparency and Accountability**, and **S5 – Life Cycle Sustainability**. A cross-disciplinary survey involved **40** respondents, of whom **27** qualified as experts. Among experts, the reported means were **\(M_{S1}=4.0\)**, **\(M_{S2}=3.7\)**, **\(M_{S3}=3.8\)**, **\(M_{S4}=3.8\)**, and **\(M_{S5}=3.2\)** on a five-point scale. The study also reports that **85.7%** believed lifecycle sustainability statements would improve trust, while **61.9%** supported mandatory disclosure of methods and tools for energy measurement. FAIR+S therefore positions sustainability metadata not as an optional appendix, but as auditable, comparable, FAIR-aligned evidence.

Scientific software studies reinforce the same point from a repository and testing perspective. One study of **CASS Software Portfolio** projects classifies projects as sustainable or unsustainable using both a **t-year activity-based sustainability** criterion and a **Truck Factor–based sustainability** criterion, and then compares structure and testing [2605.03243]. For the main activity criterion, a project is sustainable if it has commits spanning more than **\(t=2\) years** and median monthly commits at least **\(k=6\)**. Across all projects, median **Line Coverage** is about **21%**, median **Function Coverage** about **50%**, and median **Branch Coverage** about **14%**. Under stricter activity definitions, sustainable projects show higher coverage and more stable structural–testing correlations, while unsustainable projects show weaker patterns. The study states directly that **high complexity and coupling reduce testability**. A second Sci-OSS study frames sustainability through **Community Engagement** and **Software Quality**, mining **141,687 issues**, **184,536 issue comments**, **52,172 pull requests**, **164,708 PR comments**, and **706,384 commits** from **10** prominent projects, and introduces the **Software susTainability Graph (STG)** with **18 leads** as a compact temporal visualization of repository sustainability patterns [2511.07851]. A broader Apache Incubator study then shows that selected sustainability metrics do not significantly affect **defect density**, while **community age** has a positive impact on specific code quality metrics such as **risk complexity**, **number of very large files**, and **code duplication percentage**; it also reports that even when communities are experiencing sustainability, certain code quality metrics are negatively impacted [2402.06916].

Taken together, these results shift SustainableQA away from single-score thinking. In research and scientific software, sustainability evidence is distributed across metadata completeness, testing practice, structural maintainability, response patterns, review usefulness, and contributor continuity.

## 6. Operational QA workflows, Q&A detection, and open problems

SustainableQA also applies to QA workflows themselves. “Towards a Knowledge Base of Common Sustainability Weaknesses in Green Software Development” defines a **sustainability weakness** as “a part of code that has a detrimental impact on energy consumption and can potentially be remediated by leveraging an energy-efficient alternative” [2506.08812]. The paper argues that existing catalogs such as **CWE** cannot simply be re-tagged as sustainability weaknesses. Its proof-of-concept compares two Java cases on an **AWS EC2 m5.xlarge** with **Intel Xeon Platinum 8259CL**, using **psutil** and **ESAVE** over **1,000,000** iterations. For **CWE-1046**, replacing repeated `String` concatenation with `StringBuilder` reduced execution time from **41.43 s** to **10.18 s** and energy from **285.49 J** to **70.97 J**, a **75.14% reduction**. For **CWE-595**, replacing `==` with `.equals()` increased execution time from **27.73 s** to **114.30 s** and energy from **192.99 J** to **795.56 J**, an increase of about **312.23%**. The conclusion is not that correctness should be sacrificed, but that sustainability classification must be evidence-based and dimension-specific.

The environmental cost of QA automation is made explicit in “Sustainability Analysis of Prompt Strategies for SLM-based Automated Test Generation” [2604.02761]. The study evaluates **seven prompt strategies** across **three open-source instruction-tuned SLMs**—**DeepSeek-Coder-7B-Instruct-v1.5**, **Meta-Llama-3-8B-Instruct**, and **Mistral-7B-Instruct-v0.3**—all in **4-bit NF4** on a single **NVIDIA A100 80 GB GPU**. It measures token usage, execution time, energy, carbon emissions, and coverage, and defines coverage-efficiency metrics such as
$$
\text{QPerkWh} = \frac{Q}{E_{tot}}
$$
and a composite
$$
\text{SQScore} =
\alpha \cdot
\frac{Q}{CO_2 \cdot E_{tot} \cdot \tau_{hr}}.
$$
Across models, **Fewshot** and **Least-to-Most** offered the best sustainability–quality trade-offs, while **SC\_CoT** was consistently worst. For example, on **Meta-Llama-3-8B-Instruct**, **Fewshot** achieved **Q = 0.98** and **SQScore = 0.48**, whereas **SC\_CoT** achieved **Q = 0.94** and **SQScore = 0.03**. This makes prompt strategy a first-order sustainability lever for QA systems that rely on inference-heavy reasoning.

At the retrieval and labeling layer, “Sustainability Flags for the Identification of Sustainability Posts in Q&A Platforms” proposes **seven sustainability flags**—**Resource Efficiency**, **Network Efficiency**, **Storage Efficiency**, **Code Efficiency**, **Infrastructure Efficiency**, **Energy Efficiency**, and **Dynamic Resource Allocation**—derived from **92** cloud-provider best practices from AWS and Azure [2507.02695]. In a controlled experiment over **121** Stack Exchange Software Engineering posts from **2016 onward**, **17** Master students were split into a base group using definitions only and a flag group using definitions plus flags. The flag group classified fewer posts as sustainability-related—**129 Yes** versus **152 Yes**—but performed markedly better against ground truth: **Accuracy 0.71** versus **0.52**, **Precision 0.72** versus **0.53**, **Recall 0.73** versus **0.64**, and **F1 0.72** versus **0.58**. The result is especially relevant for SustainableQA because it shows that sustainability-aware retrieval and annotation benefit from operational, domain-grounded cues rather than abstract definitions alone.

Several open problems recur across these strands. Detailed quantitative aggregation remains incomplete in architecture toolkits; FAIR+S does not yet define a numeric scoring system; JI-RADAR and SEER rely heavily on human judgments and manual validation; the sustainability weakness knowledge base is still early-stage; and prompt-sustainability studies remain limited to specific models, tasks, and hardware. A broader implication is that SustainableQA is strongest when it combines explicit sustainability ontologies, artifact-level traceability, measurable indicators, and careful treatment of trade-offs. It is weakest when sustainability is treated as a synonym for a single metric, a single document genre, or a single dimension such as energy alone.

Source: https://www.emergentmind.com/topics/sustainableqa