Regweaver ESRS Workstream Playbook

Version v1.0

1. The short version of the whole model

The Regweaver ESRS (European Sustainability Reporting Standards) workstream exists because CSRD (Corporate Sustainability Reporting Directive) reporting depends on governed evidence. The reporting company cannot safely prepare a sustainability delivery if its datapoints, evidence sources, providers, scope, period, methods, limitations and review status are unclear.

The governing idea is simple: the HUB (Requester) defines what must be reported, selects the applicable ESRS requirements, assigns the right datapoints to the right SPOKES (Providers), collects or reuses evidence, validates quality, records limitations and prepares a controlled ESRS delivery output.

The HUB (Requester) is the reporting company or central orchestrator. It owns the reporting scope, materiality decisions, datapoint register, methods, assignment logic, final delivery and review process. A SPOKE (Provider) is any internal owner, site, supplier, subcontractor, logistics provider, recycler, distributor or other value-chain entity that provides data, evidence, confirmation or attestation.

Regweaver does not turn an ESRS delivery into final legal compliance by itself. Regweaver creates governed evidence, delivery quality, readiness status, limitation handling and audit trail so the customer can review, correct, approve or use the delivery in its own reporting and assurance process.

ESRS delivery quality must be assessed at three levels: datapoint quality, business-entity quality and total delivery quality.

2. What CSRD is in Regweaver

CSRD is the corporate sustainability reporting framework. In Regweaver, CSRD is not treated as a static document. It is treated as a reporting context that can be structured into requirements, workstreams, evidence expectations, review states and delivery outputs.

The CSRD layer explains why the reporting company must collect sustainability information. The ESRS layer explains what the information should look like. Regweaver sits between the reporting obligation and the practical evidence process. It helps the HUB (Requester) control which datapoints are relevant, who should answer, what evidence is needed, what limitations exist and whether the delivery is ready for review.

The CSRD process should not begin with a final report sentence. It should begin with scope, source hierarchy, datapoint mapping, materiality logic and evidence planning. A report is only reliable if the underlying delivery is governed.

3. What ESRS is in Regweaver

ESRS is the structured reporting language used under CSRD. In Regweaver, ESRS is handled as a hierarchy of standards, chapters, sub-chapters, requirements and datapoints.

The ESRS hierarchy gives the reporting process a common naming system. The workstream should not invent its own requirement names where the source hierarchy already defines them. Every delivery record should be mapped to the correct hierarchy entry before quality assessment begins.

In practical terms, an ESRS datapoint may ask for a number, narrative answer, policy description, action description, target, method explanation, evidence reference, limitation note or not-applicable reason. The quality of the answer depends on whether it actually answers the datapoint, belongs to the correct entity and period, uses the right unit or method, includes evidence where needed and explains limitations honestly.

The ESRS workstream therefore has two jobs. First, it collects and governs evidence. Second, it assesses whether the collected evidence is good enough for the intended ESRS delivery.

4. What the ESRS workstream does

The ESRS workstream turns the reporting company’s ESRS requirement scope into a controlled evidence process. It starts with the ESRS source hierarchy and the datapoint register. It then defines reporting scope, materiality, applicable datapoints, responsible business entities and relevant SPOKES (Providers). For each datapoint, Regweaver determines whether the evidence should be sourced transactionally, relationally or conditionally.

Transactional evidence is evidence that can usually be sourced from systems or structured records, such as ERP (Enterprise Resource Planning) data, invoices, purchase orders, meter logs, manifests, HR (Human Resources) systems, financial records or calculated datasets.

Relational evidence is evidence that requires a person, site, SPOKE (Provider) or internal owner to provide confirmation, attestation, policy records, grievance logs, meeting records, site-level records, audit records, local context or narrative explanation.

Conditional evidence is evidence that may be transactional if the system data has enough detail, but otherwise requires relational confirmation or direct evidence from a SPOKE (Provider).

The workstream uses this classification to avoid two mistakes. It prevents asking a SPOKE (Provider) for information that already exists in a system, and it prevents treating system data as sufficient where local, behavioural, site-level or attested evidence is required.

5. What the ESRS workstream does not do

The ESRS workstream does not replace the customer’s legal judgment, auditor review or final reporting responsibility. It does not decide SFDR (Sustainable Finance Disclosure Regulation) financial-product classification. It does not decide EU Taxonomy (European Union Taxonomy) alignment. It does not transform ESRS evidence into automatic SFDR compliance or automatic Taxonomy eligibility.

The ESRS workstream also does not treat every missing answer as not applicable. A missing answer is a gap unless a valid not-applicable reason is recorded. A boilerplate answer is not high quality merely because it is long. A numeric value is not reliable merely because it is formatted correctly. A narrative answer is not complete unless it responds to the actual datapoint and preserves evidence basis, scope, period and limitation.

The purpose of the ESRS workstream is controlled delivery governance. It should make the ESRS delivery understandable, auditable and reviewable. It should not overclaim what the evidence proves.

6. The real-world relationship map

The ESRS workstream connects a reporting company, business entities, sites, internal owners, value-chain stakeholders, datapoints, evidence, limitations and review outputs.

The HUB (Requester) is the reporting company or central orchestrator. It decides the reporting scope, materiality method, applicable ESRS source version, datapoint register, assignment logic and final delivery use.

A SPOKE (Provider) may be an internal department, business unit, production site, supplier, subcontractor, logistics provider, recycler, distributor or other value-chain entity. The SPOKE (Provider) supplies evidence because it owns or controls the relevant facts.

A datapoint is the structured ESRS evidence request or reporting need. It must be tied to the correct source hierarchy. The evidence is the submitted answer, record, file, calculation, attestation or governed data object. The delivery is the controlled output that shows what was provided, what is missing, what is limited and what is ready for review.

The same SPOKE (Provider) may provide evidence for many datapoints. The same evidence may support several valid reporting needs if the requirement, entity, period, scope and relation context are compatible. Regweaver’s role is to keep those relationships explicit.

7. Regweaver object model for ESRS

The Regweaver object model should be simple enough for non-technical users to understand, but precise enough to support audit and product implementation.

The source hierarchy records the ESRS structure: ID, Standard, Chapter, Sub-chapter and Requirement / data point. The datapoint register translates this hierarchy into operational datapoints with metadata such as type, unit, collection mode, method, evidence expectation, default tier and rationale.

The workstream is the controlled process that assigns datapoints, sends requests, receives answers, validates submissions, records limitations and prepares the delivery.

The HUB (Requester) owns the workstream. The SPOKE (Provider) supplies evidence. The evidence object stores the answer and its supporting files or references. The limitation object records uncertainty, missing data, wrong period, wrong scope, weak evidence, proxy use or cannot-assess status. The readiness state explains whether the datapoint, business entity or total delivery is ready for the next process step.

The audit trail records who requested, who answered, what evidence was provided, when it was submitted, what changed, what limitations were recorded and what output was produced.

8. Source hierarchy and datapoint register

The ESRS playbook must start from the source hierarchy. A delivery cannot be assessed properly if the datapoints are not mapped to the correct source structure.

The required hierarchy fields are ID, Standard, Chapter, Sub-chapter and Requirement / data point. These fields should control naming, communication and rollup. A datapoint quality result should be traceable to the hierarchy entry it belongs to.

The validated ESRS hierarchy workbook contains 1,184 datapoints in the controlled output. This count is used as the hierarchy coverage baseline for workbook alignment and delivery rollup checks.

The primary mapping rule is exact ID matching. If a Regweaver delivery record contains an explicit ESRS datapoint ID, or if the ID can be extracted from the delivery requirement title, the ID match controls. The secondary mapping rule is exact normalized requirement-text matching. This should be used only where a reliable ID is unavailable.

If neither ID nor normalized text gives a confident match, the mapping status is Cannot assess. The record must be excluded from Standard, Chapter and Sub-chapter rollups until reviewed.

A rollup is only meaningful if the underlying records are mapped correctly. Unmapped records must not be counted as valid chapter, sub-chapter or standard coverage.

9. Materiality, scope and assignment

Before evidence collection begins, the HUB (Requester) must define what is in scope. The workstream should identify the reporting entity, reporting period, relevant standards, applicable topics, materiality decisions, selected business entities, selected sites and selected value-chain SPOKES (Providers).

Materiality and scope control assignment. Not every SPOKE (Provider) answers every datapoint. A datapoint should be assigned to the entity or owner that can provide the relevant evidence. A workforce datapoint may belong to HR. A water datapoint may belong to a site or supplier. A policy datapoint may belong to the HUB (Requester). A value-chain worker datapoint may require a SPOKE (Provider) attestation.

The assignment should be explainable. The reviewer should be able to understand why a datapoint was assigned to a particular business entity or SPOKE (Provider), and why other entities were excluded.

Scope also controls reuse. Evidence collected for one period, site, entity or relation should not be reused outside that scope unless compatibility is confirmed and any limitation is recorded.

10. Transactional, Relational and Conditional collection model

The Transactional, Relational and Conditional collection model is a practical evidence-routing model. It helps Regweaver decide how evidence should be collected.

Transactional collection is appropriate where the datapoint can be supported by structured records. This often applies to financial values, invoices, procurement data, meter readings, HR records, manifests or system-generated logs. Transactional evidence can be efficient and auditable, but it still needs method, unit, period and reconciliation checks.

Relational collection is appropriate where the datapoint depends on local context, behaviour, governance, site-level events, policy implementation, grievance processes, remediation, community engagement, value-chain worker context or attested confirmation. Relational evidence often requires a SPOKE (Provider) answer, supporting file, attestation or direct review.

Conditional collection is used where the right collection mode depends on the available evidence. For example, a datapoint may be transactional if supplier invoices contain the required activity metric, but relational if the supplier must confirm site-level context or provide an attested explanation.

This model should be applied at datapoint level. It should not be applied only at chapter level, because the same ESRS topic may contain datapoints with different evidence needs.

11. Evidence planning and collection

Evidence planning explains what must be collected before the request is sent. For each datapoint, Regweaver should identify the expected answer type, unit where relevant, collection mode, evidence examples, method requirement, entity scope, reporting period, attestation requirement, default tier and limitation rules.

A strong evidence plan prevents vague requests. It tells the SPOKE (Provider) what the request is part of, what information is needed, what proof is useful, whether an attachment or attestation is required, what period is relevant and what counts as done.

Evidence collection should then follow the plan. If the required evidence already exists in a governed form, it should be reused. If it does not exist, the correct request should be sent to the correct SPOKE (Provider). If the evidence is submitted with gaps, the gap should be recorded and routed for correction or limitation handling.

The workstream should not collect evidence simply to fill fields. It should collect evidence because a datapoint, method, reporting scope or review need requires it.

12. Evidence reuse and non-duplication

Evidence reuse is a core Regweaver control. If a valid answer already exists for the same datapoint, entity, period, scope and relation context, the SPOKE (Provider) should not be asked to answer again. The existing evidence should be reused with lineage.

Reuse is not uncontrolled copying. It requires compatibility. A water withdrawal value for one site cannot automatically support another site. A policy statement from one period cannot automatically support a later period if the policy changed. A supplier attestation cannot automatically support a different legal entity unless the relation and scope are clear.

When evidence is reused, Regweaver should preserve the original source, submitter, timestamp, evidence files, readiness state and limitation notes. If the evidence is reused with a limitation, the limitation must follow it downstream.

One governed answer may serve many valid requesters, but only where scope and lineage support reuse.

13. Validation, reconciliation and exception handling

Validation checks whether the submitted answer is usable. Reconciliation checks whether the answer is consistent with other records. Exception handling controls what happens when something is missing, inconsistent or weak.

Validation should check whether the required fields are present, the unit is correct, the reporting period is correct, the entity is correct, the evidence is attached where required, the attestation is present where required and the method is identified where needed.

Reconciliation should compare the submitted value or narrative with available system records, prior-year data, related datapoints, financial records, procurement records, HR records, meter logs, invoices or other evidence sources where relevant.

An exception should be created when the answer is missing, incomplete, outside expected range, unsupported, contradictory, wrong-period, wrong-scope, wrong-entity, not evidenced, not attested where attestation is required, or inconsistent with related data.

An exception is not a failure of the program. It is a controlled way to show what must be corrected, reviewed or limited.

14. Datapoint delivery quality

Datapoint delivery quality concerns one ESRS datapoint response.

A high-quality datapoint response answers the specific requirement, maps to the correct hierarchy entry, belongs to the correct business entity or SPOKE (Provider), covers the correct reporting period, uses the expected unit or method where relevant, includes evidence where needed and records limitations honestly.

A weak datapoint response may still be usable, but it should not be treated as fully ready. For example, a value based on proxy data may be usable with limitation. A narrative answer that describes a policy but not implementation may be partly useful. A zero value may be valid, but only if the basis is clear.

A datapoint should be marked Red, Amber or Green only with explanation. Red means the datapoint is not ready or cannot support the delivery without correction. Amber means the datapoint may support the delivery but has limitations. Green means the datapoint is sufficiently supported for the next process step.

Every Red or Amber result must explain the reason, evidence basis and required correction or review action.

15. Business-entity delivery quality

Business-entity delivery quality concerns all assigned datapoints for one reporting entity, business unit, site, internal owner or SPOKE (Provider). This level matters because a total delivery may look acceptable while one entity has repeated evidence gaps.

For example, a supplier site may have missing water evidence, weak worker grievance evidence and no attestation. A business unit may have strong environmental metrics but weak governance narratives. A site may submit numeric values but no method documentation.

The business-entity quality assessment should identify whether the entity’s assigned datapoints are complete, coherent, evidence-backed and limitation-controlled. It should also identify patterns: repeated missing values, repeated estimates, weak attestations, inconsistent units, late responses, contradictory narratives or unusually high limitation load.

Business-entity quality is not a legal judgment. It is a delivery-quality view that helps the HUB (Requester) understand where correction, review, escalation or remediation is needed.

16. Total delivery quality

Total delivery quality concerns the complete ESRS delivery or export. This level asks whether the full delivery is ready for reporting review, ready with limitations, not ready, cannot assess or requires review. It looks across Standards, Chapters, Sub-chapters, Requirements / data points and business entities.

The total delivery quality assessment should show coverage, missingness, readiness distribution, limitation distribution, evidence strength, hierarchy mapping gaps, review blockers and unresolved exceptions.

A total delivery should not be marked ready if important records are unmapped, if material datapoints are missing, if major entities have unresolved gaps, if limitations are hidden, or if Red / Amber results are unexplained.

The total delivery output should allow a reviewer to understand the state of the ESRS delivery without opening every individual datapoint first. The detail must remain traceable, but the delivery-level explanation should be understandable.

17. Numeric analysis model

Numeric ESRS datapoints require their own quality checks. A numeric value should be checked for unit, period, entity, method, evidence source, reasonableness, completeness and variance. Regweaver should identify missing values, impossible values, values with wrong unit, unexplained zeroes, large deviations, high or low outliers, estimates and values that conflict with related datapoints.

Numeric analysis should not produce unsupported scores. The purpose is not to invent a quality number. The purpose is to explain whether the value is usable, limited, questionable or blocked.

Where averages, deviations or outliers are used, the basis should be clear. A deviation may be meaningful across similar sites or entities, but misleading across unrelated operations. The analysis should therefore preserve context.

The output should explain the issue in plain language: what value was checked, why it is unusual or weak, what evidence supports it, what limitation applies and what correction or review action is required.

18. Narrative analysis model

Narrative ESRS datapoints require a different quality logic. A narrative answer may be weak even if it is long. It may be boilerplate, generic, incomplete, unrelated to the datapoint, unsupported by evidence, inconsistent with other answers or full of limitation language without a correction plan.

A high-quality narrative answer should respond to the requirement directly. It should explain the policy, action, target, process, governance arrangement, stakeholder engagement, risk, impact, opportunity or method that the datapoint asks for. It should be specific to the entity, period and scope. It should refer to evidence where evidence is required.

Narrative analysis should check specificity, relevance, completeness, evidence basis, consistency, limitation language, boilerplate risk, missing method, missing owner, missing timeline and unsupported not-applicable claims.

The purpose is to avoid accepting polished but empty text. A narrative answer is only useful if it supports the ESRS datapoint.

19. Sustainability-risk detection inside ESRS delivery

Sustainability-risk detection in the ESRS playbook is limited to ESRS delivery analysis. It does not become SFDR product analysis or EU Taxonomy alignment analysis.

At datapoint level, risk detection identifies weak, missing, contradictory, incomplete, boilerplate, unsupported or limitation-heavy answers.

At business-entity level, risk detection identifies repeated weaknesses for one entity, such as missing evidence across several datapoints, weak attestation, repeated estimates, inconsistent values or repeated non-response.

At total delivery level, risk detection identifies systemic problems, such as missing hierarchy coverage, weak topic coverage, high limitation load, repeated cannot-assess results, unmapped records or unresolved review blockers.

The output should explain the risk signal in practical language. It should not use vague warning labels without evidence. A reader should be able to see what the issue is, where it occurs, why it matters and what action is required.

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

Limitations are part of the delivery, not side notes. A limitation explains that evidence exists but has a constraint. It may be partial, estimated, wrong-period, wrong-scope, proxy-based, unsupported by attachment, lacking attestation, inconsistent with another source or awaiting review.

A not-applicable outcome explains why a datapoint does not apply to the entity or scope. It must include a reason. It should not be used as a shortcut for missing evidence.

A cannot-assess outcome means the platform cannot determine the status from the available information. It should identify what is missing, what must be reviewed and whether the record should be excluded from rollups.

These outcomes must remain visible at datapoint level, business-entity level and total delivery level. They should carry forward into the controlled output package.

21. Readiness and review

Readiness means process and evidence readiness. It does not mean final legal compliance, assurance sign-off or final reporting approval.

The useful readiness states are Ready, Ready with limitations, Not ready, Not applicable, Cannot assess and Requires review.

A readiness state should always have an explanation. Ready means the record can proceed to the next step. Ready with limitations means it can proceed, but the limitation must remain visible. Not ready means correction is required. Not applicable means the reason has been documented. Cannot assess means required information is missing or mapping is uncertain. Requires review means a qualified reviewer must decide before the item can be used.

Review may be required when a datapoint is material, evidence is weak, a limitation is significant, a hierarchy mapping is uncertain, an entity has repeated gaps, a method is disputed, proxy data is used or the output is intended for external reporting.

Regweaver prepares the review-ready delivery. The customer and its assurance or legal-review process decide final use.

22. Controlled ESRS delivery output

The controlled ESRS delivery output is the final workstream package. It should show what was requested, who answered, what evidence was provided, what was reused, what limitations remain, what quality status applies and whether the delivery is ready for review.

The output should preserve the chain from ESRS hierarchy to datapoint, from datapoint to assignment, from assignment to SPOKE (Provider), from SPOKE (Provider) to evidence, from evidence to validation, from validation to limitation and from limitation to readiness.

The controlled delivery should include enough summary for a reviewer to understand the total delivery, but enough traceability to inspect individual datapoints and business entities.

The output should not state final CSRD legal compliance. It should state delivery readiness, evidence quality, limitations and review needs.

23. Technical payloads and implementation appendices

The main playbook is an operating manual, not a technical schema dump. It should explain the process in language that platform, compliance, product, sustainability, auditor and customer legal-review users can follow.

Technical payloads, API fields, Tier-A JSON schemas, exact ingestion templates, checksum rules, exception-ticket schemas, method-registry payloads and assurance-pack folder structures are important, but they should sit in implementation appendices or separate technical artifacts.

This separation protects readability. The main playbook explains how the ESRS workstream works and what it controls. Implementation appendices explain exactly how a system integration, data interface or assurance package should be built.

Where technical fields are referenced in the main playbook, they should be used only to clarify governance, traceability or validation. They should not interrupt the operating-manual flow.

24. Boundary to EU Taxonomy

EU Taxonomy is not rebuilt inside the ESRS playbook. ESRS evidence may support EU Taxonomy where compatible, but compatibility must be tested inside the EU Taxonomy workstream. ESRS evidence does not automatically prove Taxonomy eligibility, substantial contribution, DNSH, minimum safeguards, turnover KPI support, CapEx KPI support, OpEx KPI support or Taxonomy alignment.

The ESRS playbook should therefore prepare high-quality, traceable ESRS evidence. It should not make Taxonomy conclusions. The EU Taxonomy workstream decides whether ESRS evidence can be reused for Taxonomy purposes.

This boundary prevents the ESRS delivery from overclaiming and keeps each workstream fit for purpose.

25. Boundary to SFDR

SFDR is not rebuilt inside the ESRS playbook. ESRS evidence may support SFDR where relevant, but SFDR must still assess the evidence in the financial-product context. ESRS evidence does not automatically prove Article 6, Article 8, Article 9, principal adverse impact, website disclosure, periodic disclosure, marketing consistency or RTS support.

The ESRS playbook should produce governed evidence, delivery quality, limitations and audit trail. The future SFDR playbook should decide how that evidence supports a financial product objective, target, article need, disclosure context or claim.

This boundary preserves the correct relationship: ESRS produces company and value-chain evidence; SFDR interprets evidence for financial-product disclosure support.

26. Quality controls and common failure modes

The ESRS workstream must prevent predictable failures. One common failure is collecting evidence without hierarchy mapping. The playbook prevents this by requiring ID or normalized requirement-text mapping before rollup.

Another common failure is duplicate SPOKE (Provider) requests. The playbook prevents this through evidence reuse and requester lineage.

A third common failure is accepting boilerplate narratives. The playbook prevents this through narrative quality checks.

A fourth common failure is treating missing evidence as not applicable. The playbook prevents this by requiring documented not-applicable reasons.

A fifth common failure is hiding weak evidence. The playbook prevents this through limitation records and readiness explanations.

A sixth common failure is rolling up unmapped records. The playbook prevents this by excluding Cannot assess mappings from hierarchy rollups until reviewed.

A seventh common failure is treating ESRS readiness as final legal compliance. The playbook prevents this by separating delivery readiness from final customer reporting and assurance responsibility.

27. Glossary

Term	Meaning
CSRD (Corporate Sustainability Reporting Directive)	The EU corporate sustainability reporting framework.
ESRS (European Sustainability Reporting Standards)	The reporting standards used under CSRD.
HUB (Requester)	The reporting company or central orchestrator that owns scope, hierarchy, datapoint register, assignment, evidence governance, final delivery and review routing.
SPOKE (Provider)	An internal owner, site, supplier, subcontractor, logistics provider, recycler, distributor or other value-chain entity that provides data, evidence, confirmation or attestation.
Datapoint	A structured ESRS data point, requirement item, narrative request, numeric request or evidence requirement linked to the ESRS hierarchy.
Transactional evidence	Evidence sourced from systems or structured records such as ERP data, invoices, meter logs, manifests, HR systems or financial records.
Relational evidence	Evidence requiring a person, site, entity, SPOKE (Provider), internal owner or reviewer to provide confirmation, attestation, local context, policy evidence, logs or narrative explanation.
Conditional evidence	Evidence that may be transactional if sufficient system data exists but otherwise requires relational confirmation.
Readiness	Process and evidence readiness for the next step, not final legal compliance.
Limitation	A documented constraint affecting evidence, scope, period, entity, method, quality or review.
Not applicable	A documented outcome showing why a datapoint does not apply.
Cannot assess	A documented outcome showing that the platform cannot determine a status based on available information.
Controlled ESRS delivery output	The final workstream package containing hierarchy mapping, datapoint responses, evidence, limitations, readiness, review status and audit trail.

 

28. Appendix - hierarchy mapping and rollup rule

The ESRS delivery must be mapped before quality analysis. The required hierarchy fields are ID, Standard, Chapter, Sub-chapter and Requirement / data point. The validated hierarchy workbook contains 1,184 datapoints and should be treated as the controlling source for rollup coverage.

Each delivery record should be mapped first by exact ID. If exact ID is unavailable, it may be mapped by exact normalized requirement text. If no confident match exists, the mapping status is Cannot assess and the record is excluded from Standard, Chapter and Sub-chapter rollups until reviewed.

Rollups must be available by Standard, Chapter, Sub-chapter, Requirement / data point, business entity, SPOKE (Provider) where relevant and total delivery.

A rollup must not hide Red or Amber results. Each Red or Amber result must explain the reason, evidence basis and required correction or review action.

29. Appendix - recommended technical artifact boundaries

The following artifacts should normally be maintained as implementation appendices or separate technical files rather than placed in the main playbook narrative.

• Datapoint register technical schema and export format.
• Tier-A ingestion JSON schema and API field list.
• Attestation template and signature/hash specification.
• Evidence store checksum and WORM (write once, read many) policy.
• Method registry schema, formula versioning and uncertainty fields.
• Exception ticket schema and escalation rules.
• Assurance-pack folder structure and evidence packaging checklist.
• Sampling and audit-program implementation schedule.

These artifacts are essential for implementation, but the main playbook should remain a readable operating manual. The user should understand the process before being asked to inspect technical payloads.

30. Final operating statement

The Regweaver ESRS workstream is designed to make CSRD / ESRS delivery governed, auditable and understandable. It uses the HUB (Requester) / SPOKE (Provider) model to assign requirements, collect evidence, prevent duplication, validate quality, record limitations and prepare a controlled delivery output.

It does not replace customer legal responsibility. It does not replace assurance judgment. It does not become an EU Taxonomy alignment process. It does not become an SFDR financial-product assessment.

It produces high-quality ESRS delivery support: mapped datapoints, governed evidence, entity-level quality, total delivery quality, limitations, readiness, review status and audit trail.