SustainableQA: A QA Paradigm for Sustainability

Updated 8 July 2026

SustainableQA is a sustainability-oriented framework that integrates question answering and quality assessment using explicit models, metrics, and traceability of artifacts.
It combines domain-specific datasets, scalable pipelines, and multi-dimensional indicators to support ESG, EU Taxonomy, and software quality reporting.
The approach spans corporate reporting, requirements engineering, and research metadata, enabling evidence-based evaluations of energy efficiency, resource optimization, and long-term viability.

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 (Ali et al., 5 Aug 2025, Stadler et al., 28 Jun 2026, Calero et al., 2013). 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 (Calero et al., 2013). 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 (Lago et al., 2024). 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 (Stadler et al., 28 Jun 2026, Valko et al., 17 Jun 2026).

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 (Ali et al., 5 Aug 2025). 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 (Stadler et al., 28 Jun 2026). 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 (Roy et al., 10 Oct 2025). 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 (Calero et al., 2013). 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 (Lago et al., 2024). 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 (Fatima et al., 28 Jan 2025). 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 $N=4$ 0, and 100.00% normalized $N=4$ 1, but 0.00% normalized $N=4$ 2; the single model architecture scored 28.41% on $N=4$ 3 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 (Jouneaux et al., 25 Jul 2025). 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 $N=4$ 4, water, hardware, and region.

FAIR+S extends the same logic to research data and software metadata (Valko et al., 17 Jun 2026). 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 $N=4$ 5, $N=4$ 6, $N=4$ 7, $N=4$ 8, and $N=4$ 9 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 (Rahman et al., 5 May 2026). For the main activity criterion, a project is sustainable if it has commits spanning more than $\cos(e(r_a), e(r_b)) \ge 0.65.$ 0 years and median monthly commits at least $\cos(e(r_a), e(r_b)) \ge 0.65.$ 1. 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 (Ahmed et al., 11 Nov 2025). 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 (Alami et al., 2024).

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” (Pathania et al., 10 Jun 2025). 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” (Kumari et al., 3 Apr 2026). 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

$\cos(e(r_a), e(r_b)) \ge 0.65.$ 2

and a composite

$\cos(e(r_a), e(r_b)) \ge 0.65.$ 3

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 (Ahmadisakha et al., 3 Jul 2025). 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.