Regweaver SFDR Workstream Playbook

Version 1.0 | Gate 33 Word File Production | 22 June 2026 | Reflects the SFDR and RTS framework in force as at the version date; subsequent regulatory changes are handled through update-control support (section 24).

Opening note. This playbook is intentionally written as an operating manual. It is not an executive summary, legal opinion or final disclosure document. Its purpose is to explain how Regweaver governs SFDR support using traceable evidence, support states, limitations, review routing and audit trail. Final SFDR disclosure decisions remain with the customer and its legal, compliance, product governance or disclosure-review process. 

 

1. The short version of the whole model

The Regweaver SFDR (Sustainable Finance Disclosure Regulation) workstream exists because financial-product disclosure support depends on governed evidence. A financial product may have a sustainability-risk disclosure need, environmental or social characteristics, a sustainable investment objective, principal adverse impact relevance, website disclosure needs, periodic disclosure needs, marketing claims, EU Taxonomy (European Union Taxonomy)-related statements or RTS (Regulatory Technical Standards) presentation needs. None of these should be supported by loose text, copied spreadsheets or disconnected evidence.

The governing idea is simple: Regweaver takes governed evidence from approved sources, checks whether that evidence supports the financial-product need, records limitations and prepares a controlled support package for customer review.

The financial product is the object being supported. The customer defines the product, objective, target, article context, disclosure need and claim context. Regweaver does not decide final legal compliance. Regweaver prepares traceable support so the customer and its legal, compliance, product governance or disclosure-review process can decide final use.

The most important sentence in this playbook is this: Regweaver does not decide final SFDR compliance; Regweaver turns governed evidence into traceable financial-product disclosure support that the customer can review, limit, correct, approve or use in its own legal and disclosure process.

The second most important sentence is this: SFDR support is product-specific. The same ESRS (European Sustainability Reporting Standards) evidence or EU Taxonomy output may support different financial products in different ways because each product has its own objective, target, article context, scope, disclosure need and claim context.

2. What SFDR is in Regweaver

SFDR is the financial-services disclosure layer. In Regweaver, it is treated as a financial-product workstream that interprets governed evidence in relation to a specific product, objective, target, article need, disclosure context or claim.

SFDR is not the same as ESRS. ESRS evidence usually describes companies, business entities, value-chain entities, activities, policies, metrics, risks, impacts, actions, targets and limitations. SFDR asks how evidence supports financial-product disclosure. That means the SFDR workstream must interpret the evidence in the product context.

SFDR is also not the same as EU Taxonomy. EU Taxonomy output may provide activity mapping, eligibility, substantial-contribution support, DNSH (Do No Significant Harm) support, minimum-safeguards support and KPI (Key Performance Indicator) support. SFDR may reuse that output where relevant, but SFDR must still ask whether the Taxonomy output supports the financial-product disclosure need.

In Regweaver, SFDR therefore sits downstream from governed evidence sources. It does not collect every company datapoint from scratch. It selects governed evidence, tests support, records limitations and prepares a review package.

3. What the SFDR workstream does

The SFDR workstream turns a financial-product disclosure-support need into a controlled process.

It starts by defining the financial product, reporting period, objective, target, article context and selected evidence source. It then checks whether the selected evidence is compatible with the product scope and disclosure need. If the evidence is compatible, it can be used for support assessment. If the evidence is partly compatible, it can be used with limitations. If it is missing, stale, wrong-period, wrong-scope or not connected to the product, the workstream must record the gap or request a corrected source.

The workstream then prepares support for the relevant SFDR areas. These may include sustainability-risk support, principal adverse impact support, Article 8 characteristic support, Article 9 objective support, DNSH and good-governance support, EU Taxonomy-related support, website disclosure support, periodic disclosure support, update-control support, marketing-consistency support and RTS support.

The output is not a final legal disclosure. The output is a controlled support package that shows the evidence basis, support status, limitation, review need and audit trail.

4. What the SFDR workstream does not do

The SFDR workstream does not replace customer legal review.

It does not decide the customer’s final product classification. It does not turn ESRS evidence into automatic Article 8 or Article 9 support. It does not turn EU Taxonomy readiness into SFDR compliance. It does not rewrite source evidence. It does not ask a HUB (Requester), SPOKE (Provider), Portfolio Company or value-chain entity to repeat evidence collection when a valid governed evidence source already exists.

The workstream does not hide limitations or convert weak evidence into confident claims. It does not approve marketing text as a legal conclusion. It does not replace official RTS requirements or the customer’s interpretation of those requirements.

The SFDR workstream is a support and review-preparation layer. It makes evidence usable, traceable and reviewable in the financial-product context.

5. The real-world relationship map

The SFDR process connects a financial institution customer, a financial product, customer-defined objectives or targets, article context, evidence sources, limitations, review owners and final customer disclosure decisions.

The customer owns or manages the financial product. The financial product has a reporting period, scope, objective, target, article reference or disclosure need. The evidence may come from ESRS delivery, EU Taxonomy output, portfolio data, investment records, product documents, customer policies, prior SFDR support packages, website disclosures, periodic reporting outputs or marketing text.

Regweaver connects these objects without treating them as the same thing. ESRS evidence remains company and value-chain evidence. EU Taxonomy output remains activity-level Taxonomy support. SFDR support is the product-specific interpretation layer.

The same evidence may be reused in several product contexts. For example, one ESRS emissions datapoint may support sustainability-risk analysis for one product, Article 8 characteristic support for another and Article 9 objective support for a third. The source evidence is the same. The SFDR judgment is different because each product context is different.

6. Regweaver object model for SFDR

The Regweaver SFDR object model should be simple enough for non-technical users to understand and precise enough for review.

The financial product is the product being assessed or supported. The objective and target record defines what the customer says the product is trying to achieve or promote. The source evidence package contains governed evidence selected for the SFDR workstream. It may include ESRS delivery output, EU Taxonomy output, portfolio data, policy documents, previous disclosure support or other governed records.

The support assessment records whether the evidence supports, partly supports, does not support, cannot assess, is not applicable or requires review. The master SFDR support document is the controlled interpretation document for one financial-product workstream. The limitation register records missing, estimated, weak, stale, wrong-period, wrong-scope, unsupported, contradictory or review-dependent evidence. The review package is the customer-facing support output prepared for legal, compliance, product governance or disclosure review.

The audit trail records source version, source evidence, product context, support status, limitation, reviewer, update event and final package handoff. These objects must not be collapsed into one unclear file. A good SFDR process depends on keeping source evidence, product judgment and customer review output separate.

7. Source evidence and evidence lineage

The SFDR workstream should use governed source evidence, not uncontrolled document copying.

A governed evidence source is evidence that has an owner, source reference, period, scope, entity relation, limitation state and audit trail. ESRS controlled delivery output and EU Taxonomy controlled output are examples of governed evidence sources where they have been properly prepared.

The SFDR workstream should not use evidence simply because it exists. It must check whether the evidence is compatible with the financial product. Compatibility depends on product scope, reporting period, portfolio or investment relation, objective, target, article need, activity or entity scope, limitation state and review status.

Evidence lineage matters because SFDR support may be reviewed later. A reviewer should be able to see where the evidence came from, who provided it, which period it covers, what limitation it had, how it was used and why it supports or does not support the product need. If evidence lineage is unclear, the support state should normally be cannot assess or requires review.

8. Source-evidence hierarchy

The SFDR workstream can use several evidence inputs, but they do not have equal function. The hierarchy begins with controlled evidence that has already been governed in another Regweaver workstream or approved customer source. ESRS controlled delivery, EU Taxonomy controlled output, portfolio data, customer product setup and prior SFDR support can all be inputs, but only if source lineage and product compatibility are clear.

ESRS controlled delivery is useful where the product needs company-level, portfolio-company or value-chain evidence. EU Taxonomy controlled output is useful where the product needs Taxonomy-related support. Portfolio data is useful where the product needs investment-scope or holding-scope evidence. Customer product setup is necessary because SFDR support is product-specific. Prior SFDR support may be reused only where the product, period, objective, target and limitation state remain compatible.

If the workstream uses several evidence sources, the relationship between those sources must be visible. The SFDR support package should never merge evidence in a way that hides source, period, scope, limitation or review status.

9. Financial product setup, objective and target

The SFDR workstream begins with the financial product setup.

This setup defines the product name or identifier, reporting period, article context, objective, target, scope, selected evidence source and review owner. It should also identify whether the workstream is being run for internal support, pre-contractual disclosure support, website support, periodic support, update control, marketing consistency or customer legal-review packaging.

The objective and target are customer-defined. Regweaver should not invent them. If the customer has not defined a target, the workstream should not create one to make the evidence look stronger. If the target is vague, the support assessment should record the limitation.

This step is important because later SFDR support depends on it. Article 8 support, Article 9 support, marketing checks and RTS support all need to know what the product is claiming, promoting, targeting or reporting.

10. The master SFDR support document

The master SFDR support document is the controlled support document for one financial-product workstream.

It is not the original evidence store. Source evidence remains in ESRS delivery outputs, EU Taxonomy outputs, portfolio systems, evidence objects or other governed records.

The master document explains how the evidence is interpreted for SFDR support. It should show the product setup, selected evidence source, objective and target support, numerical evidence summary, narrative evidence summary, limitation register, article support sections, update notes, marketing-consistency support, RTS support and customer legal-review handoff.

The purpose of one master document is coherence. Without it, support may become scattered across emails, spreadsheets, slide decks and local files. With it, the reviewer can understand the current support position in one controlled place while still tracing back to original evidence. The master document should be updated through controlled process steps. It should not be edited informally in a way that breaks the audit trail.

11. Facts, judgments and outputs

The SFDR workstream must separate facts, judgments and outputs.

Facts are inherited from governed evidence sources. They may include ESRS values, ESRS narratives, EU Taxonomy support states, portfolio composition, product setup, reporting period, limitation notes, audit timestamps and customer-supplied product information. Facts should not be rewritten inside the SFDR workstream.

Judgments are the SFDR support assessments. A judgment may say that evidence supports, partly supports, does not support, cannot assess, is not applicable or requires review. A judgment belongs to the financial-product context.

Outputs are the controlled support materials. These include the master SFDR support document, objective and target support note, article support sections, limitation register, update-impact note, marketing-consistency note, RTS support section and customer legal-review package.

This distinction is essential. Weak SFDR processes often fail because they mix source facts, product judgments and final disclosure wording. Regweaver should keep them separate so the reviewer can see what is evidence, what is interpretation and what is proposed output.

12. Evidence selection and compatibility

The SFDR workstream should select one controlled evidence basis for the financial-product context wherever possible. If several sources are used, their relationship must be clear.

The selected evidence should be checked against the product scope. A source export for the wrong product, wrong period, wrong portfolio, wrong entity population or wrong objective cannot safely support the workstream without limitation or correction.

Evidence compatibility should answer practical questions. Does the evidence belong to the same reporting period? Does it cover the relevant Portfolio Companies, assets, issuers, investments or value-chain entities? Does it have limitations? Is it based on measured, attested, estimated or proxy data? Does it support the objective or only provide background context? Has it been reviewed? Is downstream use permitted?

If the evidence is compatible, it may be used. If it is partly compatible, it may be used with limitation. If it is incompatible, the workstream should record a gap, request corrected evidence or mark the step cannot assess.

13. Objective and target support

Objective and target support is the first major SFDR judgment step.

The workstream compares the customer-defined product objective or target with the selected evidence. The question is not whether the evidence is generally useful. The question is whether it supports this specific financial-product objective or target.

Support should be classified in a controlled way. The evidence may support the objective, partly support it, not support it, or be insufficient to assess. Where the answer is partly supports, does not support or cannot assess, the reason must be clear.

A strong objective-support note explains the objective, the target, the evidence used, the evidence gap, the limitation and the required correction or review action. It should not rewrite the product objective. It should not upgrade weak evidence into a stronger conclusion.

This step is especially important for Article 8, Article 9 and marketing checks because those later steps rely on the objective and target support logic.

14. Numerical and narrative evidence summaries

The SFDR workstream should prepare numerical and narrative evidence summaries when those summaries support later article or disclosure steps.

A numerical summary may include emissions, energy, water, waste, workforce, revenue, exposure, Taxonomy KPI support, adverse impact indicators or other values relevant to the product. The summary should preserve units, period, source, method, limitation and scope.

A narrative summary may include policies, governance descriptions, transition plans, grievance processes, engagement records, target explanations, methodology notes, DNSH context, good-governance evidence or limitation explanations.

These summaries are preparation layers. They do not create new facts. They make the selected evidence easier to use later in the workstream. If a value or narrative is limited, estimated, incomplete or source-dependent, the summary must preserve that limitation.

15. Limitation register

The limitation register is one of the most important controls in the SFDR workstream.

A limitation may come from the source evidence or be identified during SFDR interpretation. It may involve missing evidence, estimated values, partial scope, wrong period, uncertain target connection, weak narrative evidence, unresolved review, contradictory evidence, incomplete portfolio coverage or unclear product relation.

Limitations must not be hidden. They should follow the evidence into objective support, article support, RTS support, marketing checks and customer legal-review package.

A good limitation entry explains what is limited, why it is limited, which product or article step it affects, what evidence basis exists, whether the limitation blocks use or allows use with caveat and what correction or review action is needed. A controlled limitation is better than an unsupported claim.

16. Article 6 sustainability-risk support

Article 6 support concerns sustainability-risk support.

In Regweaver, this step uses the selected evidence, product objective, product scope, limitation register and, where relevant, external risk context to prepare sustainability-risk support. The workstream should distinguish collected source evidence from external risk insight. For example, NACE (Statistical Classification of Economic Activities in the European Community) or location-based risk insight may provide context, but it is not the same as a Portfolio Company or SPOKE (Provider) submitted fact unless confirmed by source evidence.

The Article 6 support note should explain which sustainability risks are supported by evidence, which are only contextual, which are limited and which cannot be assessed. It should also explain whether the evidence is sufficient for the next review step.

This step must not ask for new ESRS data if governed ESRS evidence already exists and is valid. It must not treat external risk intelligence as collected company evidence. It must not state final legal compliance.

17. Article 7 principal adverse impact support

Article 7 support concerns product-level PAI (Principal Adverse Impact) support where relevant.

Article 7 product-level PAI support is distinct from entity-level PAI consideration. Entity-level PAI treatment is outside this product workstream unless the customer explicitly brings it into scope, and the workstream should record which level it is supporting.

The workstream should first determine whether Article 7 support is relevant for the product context. If it is not relevant, the step should be marked not applicable with reason. If it is relevant, the workstream should assess whether the selected evidence supports the required product-level PAI treatment.

This step may use ESRS evidence, portfolio data, adverse impact indicators, limitation records and customer policy positions. The support note should explain what evidence was used, what limitation exists and whether the evidence supports, partly supports, does not support or cannot assess the product-level need.

The workstream should not treat principal adverse impact logic as automatically applicable to every product. Applicability and treatment depend on the customer context and review position.

18. Article 8 characteristic support

Article 8 support concerns environmental or social characteristics promoted by a financial product.

In Regweaver, the workstream should compare the promoted characteristic with the selected evidence. The evidence may include ESRS metrics, narratives, policies, value-chain evidence, portfolio data, EU Taxonomy-related support or other governed records. The key question is whether the evidence supports the characteristic in the financial-product context.

Article 8 support should not be copied from ESRS evidence automatically. ESRS may provide company-level evidence, but Article 8 support requires product-context interpretation. The support note should explain the characteristic, evidence basis, limitation, not-applicable areas and review need.

If the evidence is weak, partial or not connected to the characteristic, the support state should reflect that. The workstream must not create an unsupported product characteristic claim.

19. Article 9 objective support

Article 9 support concerns a sustainable investment objective where the customer has chosen that product logic.

This is a higher product-objective support step. The workstream should compare the customer-defined sustainable investment objective and target with the selected evidence. It should preserve limitations and avoid using Article 8 characteristic evidence as automatic Article 9 objective support.

Article 9 support may require stronger evidence links to objective, target, DNSH, good governance, Taxonomy-related information or other product-specific logic depending on the customer’s context and legal-review position.

The support note should be clear enough for a reviewer to understand what is supported, what is partly supported, what is not supported and what cannot be assessed. It should not state final legal compliance.

20. DNSH and good-governance support

DNSH and good-governance support should be activated only where relevant.

The workstream should identify whether the financial-product context, sustainable investment logic, Taxonomy-related logic or customer review position requires DNSH or good-governance support. If it does not, the step should be marked not applicable with reason.

Where relevant, the workstream should use governed evidence to prepare support. This may include ESRS evidence, EU Taxonomy support, governance policies, due-diligence records, incident records, human rights evidence, anti-corruption evidence, engagement records or limitation notes.

DNSH and good-governance support must not be applied universally without context. They should be assessed only where the product logic requires them.

21. EU Taxonomy-related support

EU Taxonomy-related support should use controlled EU Taxonomy output where relevant.

The SFDR workstream should not redo the EU Taxonomy assessment. It should use the controlled Taxonomy output as source evidence where downstream use is permitted. That output may include activity mapping, eligibility, substantial-contribution support, DNSH support, minimum-safeguards support, turnover KPI support, CapEx (Capital Expenditure) support, OpEx (Operating Expenditure) support, source version, limitations and readiness.

The SFDR question is different from the Taxonomy question. SFDR asks whether that Taxonomy output supports the financial-product disclosure need, objective, target, article logic, Taxonomy-related statement or review package.

If Taxonomy output is missing, not permitted for downstream use, limited, not product-compatible or not linked to the product context, the SFDR workstream must record the limitation or cannot-assess status. EU Taxonomy readiness is not SFDR compliance.

22. Website disclosure support

Website disclosure support (Article 10)

The workstream should use the prepared objective and target support, article support, evidence summaries and limitation register. It should not restart the analysis from zero. The purpose is to organize already prepared support into a website-disclosure support section.

The website support section should show what the evidence supports, what limitations must be visible and what customer review is required before external use.

Regweaver prepares support. The customer decides final website wording and legal use.

23. Periodic disclosure support

Periodic disclosure support concerns annual or periodic reporting support for the product.

This step depends on the reporting period and the evidence collected or selected for that period. It should not reuse old evidence as if it were current unless the period and source are correct.

The periodic support section should explain what happened during the period, what evidence supports the reporting position, what limitations exist and whether the prepared support is ready for customer legal or disclosure review.

Article 11 periodic support should remain separate from Article 12 update control. Periodic support explains the period. Update control checks whether existing information must be changed.

24. Update-control support

Update-control support checks whether SFDR information needs to be updated because something relevant changed.

A change may involve a new evidence export, corrected ESRS delivery, changed EU Taxonomy output, changed product objective, changed target, changed article context, changed Portfolio Company list, changed limitation, changed public disclosure, changed marketing wording or regulatory source update.

The output should be an update-impact note. It should identify what changed, which sections are affected, whether a narrow update is enough or whether upstream steps must be reopened.

This prevents two opposite errors. It prevents ignoring material changes. It also prevents restarting the entire process unnecessarily when only one support section is affected.

25. Marketing and claim consistency

Marketing and claim consistency (Article 13)

The workstream should compare customer-supplied marketing, website, investor, pitch-deck, product or sustainability claim wording with the current evidence and support notes. The result should classify the claim as supported, partly supported, unsupported or cannot assess.

Regweaver should not approve marketing language as a legal conclusion. It should show whether the current evidence trail supports the proposed wording and where limitations exist.

This control matters because unsupported claims can create disclosure, green-claim and reputational risk even where the underlying evidence package is otherwise strong. If marketing wording changes, this step should be reopened.

26. RTS support template

RTS support should organize prepared evidence and support. It should not create new facts.

The RTS support section should draw from product setup, objective and target support, article support, evidence summaries, limitation register, website support, periodic support, update-control notes, marketing checks and audit trail.

The purpose is to prepare a structure that the customer and reviewers can use when considering RTS-relevant content, methodology and presentation. Regweaver does not replace the official RTS and does not decide the customer’s final legal disclosure.

The correct operating rule is: RTS support organizes prior support; it does not invent new evidence.

27. Readiness and review

Readiness in the SFDR workstream means process and evidence readiness for the next step. It does not mean final legal compliance.

The useful support states are supports, partly supports, does not support, cannot assess, not applicable with reason and requires review. The useful readiness states are Ready, Ready with limitations, Not ready, Not applicable, Cannot assess and Requires customer legal review.

Every weak or limited state must explain the reason, evidence basis and required correction or review action.

Review is required where product classification, objective support, Article 8 support, Article 9 support, DNSH, good governance, Taxonomy-related support, marketing claims, RTS support or limitations require customer legal, compliance, product governance or disclosure-review decision.

Regweaver prepares the review-ready support package. The customer decides final use.

28. Customer legal-review package

The customer legal-review package is the final SFDR workstream support output.

It should include the product setup, selected evidence source, objective and target support, evidence summaries, limitation register, applicable article support, Taxonomy-related support where relevant, website support, periodic support, update-impact notes, marketing-consistency note, RTS support section, readiness state and audit trail.

The package should make clear what is evidence, what is interpretation and what is proposed support. It should preserve limitations and avoid unsupported legal conclusions.

The package is ready for customer review when all applicable steps are completed or marked not applicable with reason, all material limitations are visible, support states are explained and audit trail references are available. The package should not state final legal compliance unless the customer separately adds that conclusion through its own review process.

29. Boundary to ESRS

ESRS is not rebuilt inside the SFDR playbook.

ESRS provides governed company and value-chain evidence. It may include numeric values, narrative answers, policy evidence, site evidence, limitations, readiness states and audit trail. The SFDR workstream may reuse ESRS evidence where compatible with the financial product.

ESRS delivery readiness is not SFDR compliance. An ESRS answer may be high quality at company level but still not support a specific financial-product objective or claim. The SFDR workstream must interpret ESRS evidence against the product context.

If ESRS evidence is missing, limited or not compatible with the product, SFDR support must show that limitation.

30. Boundary to EU Taxonomy

EU Taxonomy is not rebuilt inside the SFDR playbook.

EU Taxonomy provides controlled activity-level output. It may include activity mapping, eligibility, substantial-contribution support, DNSH support, minimum-safeguards support, KPI support, source version, limitations, readiness and downstream-use permission.

SFDR may use this output where relevant and permitted, but SFDR must still assess the financial-product context. EU Taxonomy readiness is not SFDR compliance.

The SFDR workstream should therefore preserve the Taxonomy limitation state and should not remove or soften limitations when preparing SFDR support.

31. Quality controls and common failure modes

The SFDR workstream must prevent predictable failures.

One common failure is treating ESRS evidence as automatic Article 8 or Article 9 support. The playbook prevents this by requiring product-context assessment.

Another common failure is treating EU Taxonomy readiness as SFDR compliance. The playbook prevents this by treating Taxonomy output as governed source evidence, not as final SFDR conclusion.

A third common failure is duplicate evidence collection. The playbook prevents this by selecting governed evidence sources and reusing valid evidence. A fourth common failure is mixing facts, judgments and outputs. The playbook prevents this by separating source evidence, SFDR support assessment and customer-facing outputs.

A fifth common failure is hiding limitations. The playbook prevents this through the limitation register. A sixth common failure is approving marketing language without evidence support. The playbook prevents this through marketing-consistency checks. A seventh common failure is using outdated support after a product or disclosure change. The playbook prevents this through update-control support.

A final common failure is treating readiness as final legal compliance. The playbook prevents this by requiring customer legal-review handoff.

32. Glossary

Term	Meaning
SFDR (Sustainable Finance Disclosure Regulation)	The EU sustainable finance disclosure framework for financial market participants and financial advisers.
CSRD (Corporate Sustainability Reporting Directive)	The EU corporate sustainability reporting framework.
ESRS (European Sustainability Reporting Standards)	The reporting standards used under CSRD.
EU Taxonomy (European Union Taxonomy)	The EU framework for classifying environmentally sustainable economic activities.
RTS (Regulatory Technical Standards)	Detailed regulatory technical standards relevant to SFDR disclosure support.
DNSH (Do No Significant Harm)	A support area relevant where the product logic requires assessment of whether an investment or activity causes significant harm.
KPI (Key Performance Indicator)	A metric used for disclosure or support purposes, including Taxonomy-related turnover, CapEx or OpEx support where relevant.
CapEx (Capital Expenditure)	Capital expenditure relevant to Taxonomy or financial-product support where applicable.
OpEx (Operating Expenditure)	Operating expenditure relevant to Taxonomy or financial-product support where applicable.
HUB (Requester)	The reporting company or central orchestrator in the ESRS evidence process.
SPOKE (Provider)	An internal owner, site, supplier, subcontractor, logistics provider, recycler, distributor or other value-chain entity that provides evidence, data, confirmation or attestation.
Portfolio Company	A company connected to a financial product and used as an evidence or investment context in the SFDR process.
Support state	The assessment result showing whether evidence supports, partly supports, does not support, cannot assess, is not applicable or requires review.
Readiness	Process and evidence readiness for the next step, not final legal compliance.
Limitation	A documented constraint affecting evidence, support, scope, period, objective, target, article need, disclosure output or review.
Governed evidence source Master SFDR support document	The controlled interpretation document for one financial-product workstream.
Evidence that has an owner, source reference, period, scope, entity relation, limitation state and audit trail, making it usable and traceable in the SFDR workstream. Customer legal-review package	The final support package prepared for the customer’s legal, compliance, product governance or disclosure-review process.

33. Appendix - 18-step SFDR workstream traceability

The main playbook explains the process in operating language. This appendix preserves the 18-step workstream traceability.

This appendix is for requirement alignment. It should not replace the main operating explanation. The workbook sequence confirms that the playbook remains aligned with the deployable SFDR requirement model, while the main text explains how the model should be understood and operated.

Requirement ID	Requirement purpose
SFDR_SCOPE_001	Start up the financial product workstream.
SFDR_SOURCE_002	Select the ESRS workstream export or governed evidence source for SFDR use.
SFDR_OBJECTIVE_003	Check whether evidence supports the objective and target.
SFDR_DATA_004	List relevant evidence numbers for later SFDR use.
SFDR_TEXT_005	Summarize relevant narrative evidence for later SFDR use.
SFDR_LIMIT_006	List missing, estimated or limited evidence.
SFDR_A6_007	Prepare sustainability-risk support.
SFDR_A7_008	Prepare product-level principal adverse impact support.
SFDR_A8_009	Prepare Article 8 characteristic support.
SFDR_A9_010	Prepare Article 9 objective support.
SFDR_DNSH_011	Prepare DNSH and good-governance support where relevant.
SFDR_TAX_012	Prepare Taxonomy-related support where relevant.
SFDR_A10_013	Prepare website disclosure support.
SFDR_A11_014	Prepare periodic annual disclosure support.
SFDR_A12_015	Check whether SFDR information needs update.
SFDR_A13_016	Check marketing claims against SFDR support.
SFDR_RTS_017	Prepare RTS support template.
SFDR_REVIEW_018	Prepare customer-facing legal-review support package.

34. Final operating statement

The Regweaver SFDR workstream is designed to make financial-product disclosure support governed, auditable and understandable.

It uses governed evidence from ESRS, EU Taxonomy and other approved sources where compatible. It interprets that evidence in the financial-product context. It prepares objective and target support, article support, limitation handling, marketing consistency, RTS support and customer legal-review packaging.

It does not replace customer legal responsibility. It does not replace final product-classification decisions. It does not turn ESRS evidence or EU Taxonomy output into automatic SFDR compliance.

It produces traceable SFDR support: selected evidence, product-specific judgments, limitations, readiness, review status and audit trail.