EU Taxonomy Workstream Playbook

Version v1.0 - EU Taxonomy-focused operating manual

This playbook explains the EU Taxonomy workstream in operational language. It is not legal advice, does not replace customer legal or auditor review, and does not state that an activity is Taxonomy-aligned merely because a process has been followed.

1. The short version of the whole model

The Regweaver EU Taxonomy (European Union Taxonomy) workstream exists because EU Taxonomy reporting and review depend on controlled activity-level evidence. A company cannot safely say that an activity is Taxonomy-eligible, Taxonomy-supported, or ready for disclosure review unless the activity, source version, evidence, limitation and review trail are clear.

The governing idea is simple: Regweaver helps the customer identify the activity, select the correct EU Taxonomy source version, check whether existing evidence can be reused, request new evidence only where needed, assess evidence support, preserve limitations and prepare a controlled output package for review.

The workstream is not designed to create a legal conclusion automatically. It is designed to create a traceable process that shows what was assessed, what evidence was used, what was missing, what limitations remain and whether the output is ready for customer legal, auditor or reporting review.

The most important operating rule is that Regweaver does not certify EU Taxonomy alignment. Regweaver creates governed evidence support, readiness status, limitation handling and audit trail so the customer can review and decide final use.

The second important operating rule is that activity-specific EU Taxonomy logic is handled inside the existing 40 approved workbook requirements. It is not handled by creating one row per activity, one row per criterion or a new deployable workbook layer.

2. What EU Taxonomy is in Regweaver

EU Taxonomy is an activity-based framework. It is not a company label. It does not say that a whole company is green or not green. It works by looking at economic activities and checking whether those activities are described in the EU Taxonomy source and whether the required evidence supports the relevant criteria.

In Regweaver, this means the workstream starts with the activity, not with a final claim. The customer or internal owner must know what activity is being assessed, why it is relevant to the reporting company, which source version is used and whether the activity has a product, service, asset, revenue, CapEx (Capital Expenditure) or OpEx (Operating Expenditure) relation.

Once the activity is clear, the workstream can test whether the activity maps to a Taxonomy activity. If it maps, the workstream can determine eligibility. If eligibility is supported, the workstream can assess evidence support for substantial contribution, DNSH (Do No Significant Harm), minimum safeguards and relevant KPI (Key Performance Indicator) treatment.

The process is therefore sequential, but it is not rigid in the wrong way. If a required data point already exists as governed evidence, Regweaver should reuse it. If the evidence is missing or incompatible, Regweaver should distribute a scoped request. If the evidence is weak, partial or uncertain, Regweaver should preserve the limitation rather than hide it.

3. What the EU Taxonomy workstream does

The EU Taxonomy workstream turns an activity-level Taxonomy question into a governed process. It starts by defining the scope and source version. It then uses the existing Regweaver value-chain network and evidence model to determine what is already known and what still needs to be collected or confirmed.

The workstream helps the customer answer practical questions. Which activity is being assessed? Which entity or internal owner is responsible for the evidence? Does the activity relate to revenue, CapEx or OpEx? Is NACE (Statistical Classification of Economic Activities in the European Community) useful as screening support? Does the activity map to an official Taxonomy activity? Is the activity eligible? What evidence is needed for substantial contribution, DNSH and minimum safeguards? Which KPI treatment is relevant? What gaps remain? Is downstream use permitted?

The output of the workstream is a controlled support package. That package should be understandable to a compliance reviewer, product owner, sustainability owner, legal reviewer or auditor. It should show the source version, activity, evidence, readiness, limitations and audit trail without requiring the reviewer to reconstruct the process from separate notes.

4. What the EU Taxonomy workstream does not do

The EU Taxonomy workstream does not replace the customer’s legal judgment. It does not replace auditor review. It does not automatically decide final Taxonomy alignment. It does not replace Double Materiality Assessment. It does not replace the CSRD (Corporate Sustainability Reporting Directive) or ESRS (European Sustainability Reporting Standards) playbook. It does not replace the SFDR (Sustainable Finance Disclosure Regulation) playbook.

It also does not operate as a generic supplier questionnaire. The purpose is not to ask every stakeholder every possible sustainability question. The purpose is to ask the right evidence question, to the right entity or internal owner, for the right activity, source version, reporting period and scope.

The workstream also does not use NACE as proof. NACE may help screen and identify possible Taxonomy activity candidates, but it cannot prove eligibility or alignment by itself. The real-world activity description and the official Taxonomy activity description must still be compared.

Finally, the workstream does not create a new workbook architecture. The approved workbook contains 40 requirements. Those 40 requirements are the deployable operating model. Activity-specific detail is recorded inside those requirements through source version, activity reference, evidence expectation, limitation and review state.

5. The Regweaver platform boundary

The EU Taxonomy workbook is the deployable requirement model for the platform. The operational logic is contained in the worksheet Requirement_Data_Sheet_Logic, and the workbook uses the approved 14-column schema. This playbook must therefore remain aligned with the workbook. It may explain the process in fuller language, but it must not create new workbook rows, new workbook columns, new platform objects or a separate activity-specific deployable tab.

This boundary is important because a playbook can easily become more detailed than the platform model. That may look useful at first, but it creates technical debt if the workbook starts describing logic that the platform cannot execute. The EU Taxonomy process must remain within Regweaver’s actual objects: workstream, requirement, evidence, value-chain entity, limitation, readiness, review status and audit trail.

Support worksheets may exist for quality assurance or traceability. They can help reviewers understand how the workbook was built. They are not deployable platform logic unless Regweaver separately implements them as platform objects.

The workbook therefore remains the source of operational execution, while the playbook explains how to understand and run the process.

6. The real-world relationship map

The EU Taxonomy workstream connects several real-world objects. The reporting company is the customer entity or group preparing EU Taxonomy reporting or review support. The activity is the economic activity being assessed. The registered value-chain stakeholder or internal owner is the entity or person that may hold relevant evidence. The source version is the official EU Taxonomy source basis used for the assessment. The evidence package contains existing or newly collected information. The controlled output package is the final workstream result prepared for review.

In plain terms, the relationship works like this: the customer defines the EU Taxonomy workstream and reporting scope. Regweaver checks the registered value-chain network and available governed evidence. The activity is described and mapped to a possible EU Taxonomy activity. Eligibility is assessed. Evidence support is checked for substantial contribution, DNSH, minimum safeguards and KPI treatment. Limitations are recorded. Review is routed where needed. The final output package preserves the source version, evidence basis, limitations, readiness state and audit trail.

The value of Regweaver is not only that it stores evidence. The value is that it keeps the evidence connected to the right activity, source version, entity, reporting period, relation and review state.

7. Regweaver object model for EU Taxonomy

The object model should be simple enough for a non-technical reader to understand, but precise enough to prevent overlap.

A regulation source is the official EU Taxonomy source material used for the workstream. A source version records which version, delegated act, annex, activity reference or consolidation date is being used. A requirement is the structured Regweaver object that asks for, confirms or assesses information. A value-chain entity is a registered stakeholder or internal owner connected to the reporting company. Evidence is the answer, attachment, calculation, record or governed data object used to support the process. A limitation is a documented constraint that affects evidence strength or use. A readiness state explains whether the process is ready, ready with limitations, not ready, not applicable, cannot assess or requires review. The audit trail records how the process was run.

These objects must stay separate. If the same piece of evidence is used more than once, it should remain one governed evidence object with reuse lineage. If a limitation exists, it should follow the evidence into the output package. If a customer wants to use the output downstream, the downstream-use permission must be recorded rather than assumed.

8. End-to-end process playbook

The EU Taxonomy workstream begins with scope. The customer or internal owner defines why the workstream is being run, which reporting period is relevant and what the intended use is. This prevents the workstream from starting as an uncontrolled data collection exercise.

After the workstream is opened, the source version is selected. This step is essential because EU Taxonomy logic depends on the correct legal source, delegated act, annex, activity reference and effective version. The workstream should not mix old and new Taxonomy logic without a transition record.

The workstream then selects the relevant registered stakeholders and inherited value-chain master data. Regweaver uses the existing value-chain network rather than recreating stakeholder identity, address, NACE code, consent or relation data. This keeps master data separate from EU Taxonomy requirement data.

The next step is the consume-first evidence check. Regweaver checks whether the required data already exists as value-chain master data, CSRD / ESRS evidence, prior EU Taxonomy evidence or another governed evidence object. If the evidence is compatible, it should be reused. If it is partly compatible, it may be reused with limitations. If it is missing, insufficient or incompatible, a scoped Taxonomy-specific request is distributed.

The workstream then confirms the real-world activity description and the activity relation. It asks what the activity is, why it matters to the reporting company and whether it relates to product, service, asset, revenue, CapEx or OpEx. NACE may support screening, but it cannot replace the activity description.

Once the activity is described, it is mapped to a potential EU Taxonomy activity. If the mapping is uncertain, review is required. If the mapping is supported, eligibility can be assessed. Eligibility means the activity is described in the relevant EU Taxonomy source. It does not mean alignment.

If the activity is eligible or requires further support assessment, the workstream identifies the evidence package needed for substantial contribution, DNSH, minimum safeguards and KPI support. Evidence is reused where valid and requested only where needed.

The workstream then records support states, limitations, review needs and readiness. The final output package shows what is supported, what is partly supported, what cannot be assessed, what is not applicable and what needs review. It also records whether downstream use is permitted.

9. Activity identification and source-version control

Activity identification and source-version control are the foundation of the workstream. If either is weak, the rest of the process becomes unreliable.

The activity description explains the real-world activity being assessed. It should be concrete enough to compare with the official Taxonomy activity description. A vague description such as sustainability services or energy project is usually not enough. The description should make clear what is being done, by whom, in what scope and why it matters to the reporting company.

The source version explains which EU Taxonomy source is being used. This may include the regulation, delegated act, annex, section, activity name, environmental objective, criterion reference, consolidation date and extraction date. The source-version record prevents the platform from mixing old and new criteria or applying the wrong activity logic.

The process should never invent a source reference. If the source reference is unknown, that is a limitation. If several possible source references exist, that is a review point. If the source version changes, the workstream should test whether old evidence remains reusable.

10. Value-chain data and EU Taxonomy data boundary

The EU Taxonomy workstream uses existing Regweaver value-chain master data, but it does not redefine what master data is.

Value-chain master data includes the registered company identity, organisation number, address, state, NACE code, consent references, contact person or license signer, value-chain connection, relation type and tier level. This information should be inherited where valid.

EU Taxonomy requirement data is different. Activity description, product relation, service relation, asset relation, revenue relation, CapEx relation, OpEx relation, activity mapping, eligibility support, substantial-contribution evidence, DNSH evidence, minimum-safeguards evidence, KPI evidence, limitations and readiness are produced or assessed inside the EU Taxonomy workstream.

This distinction matters because the platform should not ask a stakeholder to re-enter master data when it already exists. It should also not pretend that master data already contains the activity-specific evidence needed for Taxonomy assessment.

11. Evidence planning, reuse and scoped requests

The EU Taxonomy workstream should not start by sending new requests. It should start by asking what evidence already exists.

Evidence may come from value-chain master data, CSRD / ESRS evidence, prior EU Taxonomy workstreams, internal calculations, policies, site records, technical documents, financial records, attachments or reviewer confirmations. The fact that evidence exists does not automatically mean it can be reused. It must be compatible with the requirement, activity, source version, entity, reporting period, scope and evidence-quality expectation.

When evidence is compatible, reuse is the correct action. When evidence is partly compatible, reuse with limitation may be correct. When evidence is missing, stale, wrong-scope, wrong-period, wrong-activity or insufficient, the workstream should distribute a scoped request.

A scoped request explains exactly what is needed and why. It should not become a broad sustainability questionnaire. The recipient should understand the activity, period, evidence need, expected response and definition of done.

This is one of the most important practical controls in the playbook: collect only what is needed, reuse what is valid, and preserve limitations where evidence is imperfect.

12. Activity mapping and eligibility

Activity mapping compares the real-world activity with a potential EU Taxonomy activity. The mapping should use the confirmed activity description, source version, delegated act reference, activity name, environmental objective and any supporting evidence.

If the mapping is clear, the workstream can proceed to eligibility. If the mapping is uncertain, the item should be routed for review. The workstream should not force a mapping simply because a NACE code suggests a possible connection.

Eligibility means that the activity is described in the relevant EU Taxonomy source. It is a necessary distinction, but it is not the end of the process. An eligible activity may still lack substantial-contribution support, DNSH support, minimum-safeguards support or KPI support.

Where the activity is not eligible, cannot be assessed or is not applicable, the workstream should record the reason. Those outcomes are valid process results. They should not be treated as empty cells or failed administration.

13. Substantial contribution, DNSH and minimum safeguards

After eligibility, the workstream assesses evidence support. The three main support areas must remain separate.

Substantial contribution concerns whether evidence supports the applicable activity-specific substantial-contribution criteria. DNSH concerns whether evidence supports the relevant Do No Significant Harm expectations. Minimum safeguards concern whether the available policy, governance, due-diligence or review evidence supports the minimum-safeguards part of the EU Taxonomy process.

These areas are connected, but they are not the same. Evidence that supports substantial contribution does not automatically support DNSH. DNSH evidence does not automatically prove minimum safeguards. Minimum-safeguards evidence does not automatically prove KPI support.

The workstream should record support states in a controlled way. The most useful support states are support available, support partly available, support not available, cannot assess, requires review and not applicable with reason. A support state should always be accompanied by an evidence basis and limitation where relevant.

This section is where overclaiming risk is high. The playbook therefore requires clear language: Regweaver records evidence support and readiness. It does not certify legal alignment.

14. KPI support: turnover, CapEx and OpEx

The EU Taxonomy workstream must treat KPI support as its own process area. Turnover, CapEx and OpEx are different, and each requires its own evidence basis where applicable.

Turnover support concerns whether the activity has a revenue or turnover relation that can support Taxonomy KPI treatment. CapEx support concerns whether the activity has an asset, investment or plan relation that can support Capital Expenditure treatment. OpEx support concerns whether the activity has an operating expenditure relation that can support Operating Expenditure treatment.

The workstream should first determine whether each KPI is applicable. It should not assume that every activity has turnover, CapEx and OpEx relevance. If a KPI is not applicable, the reason must be recorded. If a KPI is supported only by estimates, partial evidence or unclear allocation, the limitation must be recorded.

KPI support is not the same as eligibility and not the same as final alignment. It is a distinct support area that must remain visible in the controlled output.

15. Source-version transition and target continuity

The workbook includes source-transition rows because EU Taxonomy and evidence sources change over time. These controls do not turn the EU Taxonomy playbook into an ESRS playbook. They exist to answer a narrower question: does evidence previously used in the EU Taxonomy workstream remain valid after a source-version change?

If reused ESRS evidence is affected by an ESRS version change, the EU Taxonomy workstream should test whether that evidence still supports the same Taxonomy requirement. It should not rebuild the ESRS process. It should only decide whether the evidence remains compatible for Taxonomy use.

If the EU Taxonomy source itself changes, the workstream should test whether the activity, criteria, KPI method, effective date or disclosure expectation changed. Historic assessments should not be silently overwritten. Old evidence may remain historically useful, but it should not be treated as current unless compatibility is confirmed.

The workbook also includes target-continuity controls. A target, including a Paris Agreement-aligned target, may be relevant in some contexts. It must not be used as a substitute for activity-specific EU Taxonomy technical screening criteria unless the applicable official criterion expressly allows or requires that evidence.

16. Limitations, not-applicable outcomes and cannot-assess outcomes

Limitations are not administrative noise. They are part of the controlled result.

A limitation explains why evidence is incomplete, uncertain, partial, estimated, wrong-period, wrong-scope, wrong-activity, stale, incompatible or review-dependent. A not-applicable result explains why a requirement does not apply. A cannot-assess result explains why the workstream cannot determine a status from the available information.

These outcomes should be visible in the controlled output package. They should not be hidden in attachments, informal comments or side notes.

A good limitation record explains the affected requirement, activity, entity, period, KPI where relevant, source version, evidence basis, reason, owner, reviewer where relevant and required next action.

The practical rule is simple: a controlled limitation is better than an unsupported conclusion.

17. Review and readiness

Review and readiness are handled near the end of the workstream, but they are shaped by everything that came before.

Readiness means that the process and evidence are ready for the next step. It does not mean final legal compliance. A workstream may be ready, ready with limitations, not ready, not applicable, unable to assess or require auditor/legal review.

A readiness decision should explain why the status was assigned. It should refer to the evidence basis, limitation summary, reviewer status and next action. A readiness status without explanation is weak because the reviewer cannot see what it means.

Legal or auditor review should be routed where the output affects external reporting, where criteria are uncertain, where mapping is disputed, where KPI treatment is unclear, where limitations are material or where customer governance requires review.

Regweaver prepares the review package. The customer’s legal, auditor or reporting-review process decides final use.

18. Controlled output package

The controlled output package is the final evidence and review package produced by the EU Taxonomy workstream.

It should allow a customer, reviewer or auditor to understand which activity was assessed, which source version was used, which evidence was reused or requested, what support was available, what limitations remain and whether downstream use is permitted.

The package should preserve the full chain from source version to activity, from activity to mapping, from mapping to eligibility, from eligibility to evidence support, from support to KPI treatment, from KPI treatment to limitations, and from limitations to readiness and review.

The output package must not state final legal confirmation of Taxonomy alignment unless that conclusion is separately made by the responsible customer legal, auditor or reporting-review process.

The output package may state that the workstream is ready for review, ready with limitations, not ready, not applicable, cannot assess or requires review. It may also state whether downstream use is permitted.

19. Boundary to CSRD and ESRS

CSRD and ESRS are not rebuilt inside this EU Taxonomy playbook.

They appear here only as potential governed evidence sources. The EU Taxonomy workstream may reuse CSRD or ESRS evidence if that evidence is compatible with the Taxonomy requirement, activity, entity, reporting period, scope, source version and evidence-quality expectation.

CSRD or ESRS evidence does not automatically prove EU Taxonomy eligibility, substantial contribution, DNSH, minimum safeguards, turnover KPI support, CapEx KPI support, OpEx KPI support or final Taxonomy alignment.

This boundary is important because the future ESRS playbook should separately govern ESRS delivery quality, datapoint hierarchy, business-entity rollups, evidence quality, sustainability-risk detection and ESRS version transition. The EU Taxonomy playbook only controls whether ESRS evidence can be reused in a Taxonomy context.

20. Boundary to SFDR

SFDR is not rebuilt inside this EU Taxonomy playbook.

SFDR appears here only as a possible downstream use of controlled EU Taxonomy output. The EU Taxonomy output may support SFDR where relevant, but SFDR must still perform its own financial-product assessment.

The EU Taxonomy workstream may provide SFDR with activity mapping status, eligibility status, substantial-contribution support status, DNSH support status, minimum-safeguards support status, KPI support, source-version record, evidence references, limitations, readiness and audit trail. That information may be useful for SFDR, but it is not the SFDR conclusion.

The EU Taxonomy output must not state SFDR compliance. It may state whether the output is permitted for downstream SFDR review, and it must carry limitations forward.

The future SFDR playbook should separately govern financial-product objectives, targets, article support, claim support, marketing consistency, periodic reporting, RTS (Regulatory Technical Standards) support and legal-review packaging.

21. Audit trail and source lineage

The audit trail should be created during execution, not reconstructed afterward.

A strong audit trail shows which source version was used, which requirement was triggered, which entity or internal owner was selected, which activity was assessed, which evidence was reused, which evidence was requested, which limitations were recorded, which reviewer was involved and what output was produced.

Source lineage is especially important in EU Taxonomy because small changes can affect the conclusion. A different source version, activity description, reporting period or KPI boundary may change the result. Without lineage, the customer cannot safely explain why an output was produced.

The audit trail is therefore not a technical accessory. It is one of the main compliance controls.

22. Quality controls and common failure modes

The EU Taxonomy workstream must prevent predictable failures.

One common failure is treating NACE as proof. The playbook prevents this by requiring real activity description and source-based mapping.

Another common failure is treating eligibility as alignment. The playbook prevents this by separating eligibility, substantial contribution, DNSH, minimum safeguards and KPI support.

A third common failure is duplicate collection. The playbook prevents this through the consume-first evidence rule.

A fourth common failure is hiding weak evidence. The playbook prevents this through limitation records, not-applicable reasons, cannot-assess outcomes and readiness explanations.

A fifth common failure is using old evidence after source logic has changed. The playbook prevents this through source-version and transition-compatibility controls.

A sixth common failure is treating EU Taxonomy readiness as SFDR compliance. The playbook prevents this through downstream-use permission and SFDR boundary control.

A final common failure is creating new workbook rows for every Taxonomy activity. The playbook prevents this by keeping activity-specific logic inside the existing 40 approved requirements.

23. The 40-requirement workbook traceability appendix

The main playbook explains the process in operating language. This appendix preserves workbook traceability. The 40 approved workbook requirements are the execution backbone and should be used to confirm that the playbook remains aligned with the workbook.

The requirement sequence is shown below in compact traceability form. It should support review without taking over the main narrative.

1. EU_TAX_SCOPE_001 - Start EU Taxonomy workstream and define purpose.

2. EU_TAX_SOURCE_002 - Select EU Taxonomy source version.

3. EU_TAX_NETWORK_003 - Select registered value-chain stakeholders and inherited master data.

4. EU_TAX_SCOPE_DECISION_004 - Record customer scope and materiality decision.

5. EU_TAX_DATA_SOURCE_005 - Check whether required data exists as value-chain master data.

6. EU_TAX_EVIDENCE_SOURCE_006 - Check whether compatible CSRD / ESRS, prior EU Taxonomy or governed evidence exists.

7. EU_TAX_COMPATIBILITY_007 - Test evidence compatibility.

8. EU_TAX_DISTRIBUTION_008 - Distribute scoped Taxonomy-specific requirement only where needed.

9. EU_TAX_ACTIVITY_009 - Collect or confirm activity description.

10. EU_TAX_RELATION_010 - Confirm product, service, asset, revenue, CapEx or OpEx relation.

11. EU_TAX_NACE_011 - Use NACE as screening support only.

12. EU_TAX_MAP_012 - Map activity to potential EU Taxonomy activity.

13. EU_TAX_MAP_REVIEW_013 - Review uncertain activity mapping.

14. EU_TAX_ELIG_014 - Determine eligibility.

15. EU_TAX_NOT_ELIG_015 - Record not-eligible, cannot-assess or not-applicable reason.

16. EU_TAX_EVIDENCE_PLAN_016 - Identify required evidence package.

17. EU_TAX_REUSE_017 - Reuse valid evidence or record limitation.

18. EU_TAX_REQUEST_018 - Request Taxonomy-specific evidence where needed.

19. EU_TAX_EXCEPTION_019 - Record missing, unavailable or insufficient evidence.

20. EU_TAX_TSC_020 - Assess substantial-contribution support.

21. EU_TAX_DNSH_021 - Assess DNSH support.

22. EU_TAX_MINSAFE_022 - Assess minimum-safeguards support.

23. EU_TAX_ALIGNMENT_LIMIT_023 - Record alignment-support limitations.

24. EU_TAX_KPI_SCOPE_024 - Determine KPI applicability.

25. EU_TAX_TURNOVER_025 - Assess turnover KPI support.

26. EU_TAX_CAPEX_026 - Assess CapEx KPI support.

27. EU_TAX_OPEX_027 - Assess OpEx KPI support.

28. EU_TAX_KPI_LIMIT_028 - Record KPI limitations, estimates or not-applicable reasons.

29. EU_TAX_ESRS_TRANSITION_029 - Map old ESRS source version to new ESRS source version.

30. EU_TAX_TAXONOMY_TRANSITION_030 - Map old EU Taxonomy source version to new EU Taxonomy source version.

31. EU_TAX_TRANSITION_COMPAT_031 - Test whether old evidence remains reusable under the new source version.

32. EU_TAX_TRANSITION_DISTRIBUTE_032 - Distribute changed or scoped requirements only where transition mapping shows new evidence is needed.

33. EU_TAX_TARGET_CONTINUITY_033 - Review whether changed inputs affect KPI target continuity.

34. EU_TAX_PARIS_TARGET_034 - Assess Paris Agreement-aligned target evidence only where relevant.

35. EU_TAX_TARGET_LIMIT_035 - Record target-support limitations and non-substitution rule.

36. EU_TAX_LIMIT_036 - Register limitations, gaps and not-applicable reasons.

37. EU_TAX_REVIEW_037 - Route for auditor/legal review where required.

38. EU_TAX_READY_038 - Set readiness and prepare controlled output.

39. EU_TAX_DOWNSTREAM_039 - Define permitted downstream use, including SFDR support where relevant.

40. EU_TAX_AUDIT_040 - Confirm audit trail and source lineage.

 

24. Glossary

Term	Plain-language meaning
EU Taxonomy (European Union Taxonomy)	the EU framework for classifying environmentally sustainable economic activities.
CSRD (Corporate Sustainability Reporting Directive)	the EU corporate sustainability reporting framework.
ESRS (European Sustainability Reporting Standards)	the reporting standards used under CSRD.
SFDR (Sustainable Finance Disclosure Regulation)	the EU sustainable finance disclosure framework for financial market participants and financial advisers.
DNSH (Do No Significant Harm)	the requirement that an activity must not significantly harm other environmental objectives.
KPI (Key Performance Indicator)	a metric used for disclosure or target-support purposes, including Taxonomy turnover, CapEx and OpEx where applicable.
CapEx (Capital Expenditure)	capital expenditure relevant to Taxonomy KPI analysis where applicable.
OpEx (Operating Expenditure)	operating expenditure relevant to Taxonomy KPI analysis where applicable.
NACE (Statistical Classification of Economic Activities in the European Community)	the activity classification code that may support screening but does not prove Taxonomy eligibility or alignment.
DMA (Double Materiality Assessment)	the customer’s materiality assessment process. Regweaver records and operationalizes customer decisions but does not replace the customer’s final judgment.
RTS (Regulatory Technical Standards)	detailed regulatory technical standards relevant in SFDR contexts where applicable.
Readiness	process and evidence readiness for review, export or downstream use.
Limitation	a documented constraint affecting evidence, scope, period, source, activity, KPI or review.
Not applicable	a documented outcome showing why a requirement does not apply.
Cannot assess	a documented outcome showing that the workstream cannot determine a status from available information.
Controlled output package	the final workstream support package containing source version, scope, evidence, support states, limitations, readiness, downstream-use permission and audit trail.

 

25. Final operating statement

The Regweaver EU Taxonomy workstream is designed to remain deployable in the Regweaver platform.

It does not create one row per Taxonomy activity. It does not create a new workbook architecture. It does not rebuild the ESRS playbook. It does not rebuild the SFDR playbook.

It uses the approved 40-requirement sequence to manage source version, value-chain data use, scope, activity description, activity relation, NACE screening support, activity mapping, eligibility, evidence planning, evidence reuse, scoped requests, substantial-contribution support, DNSH support, minimum-safeguards support, KPI support, limitations, review, readiness, downstream-use permission and audit trail.

The result is a governed, auditable and fit-for-purpose EU Taxonomy process that supports customer review without creating platform debt or unsupported legal conclusions.