We’ve encountered an issue related to the built-in concepts that were introduced across two releases of the solution.
- In one release, a set of OOB concepts prefixed with “AIGenerated-” were released as part of the Fact Finding with Copilot functionality. These concepts were automatically linked to CSRD standard requirements.
- In another release, a new batch of predefined concepts prefixed with "esrs-" was added. Many of these represent the same underlying concepts as the AIGenerated ones but with different data types. These were also automatically linked to CSRD standard requirements.
As a result, we now have duplicates: one Standard Requirement linked to duplicate Concepts: one prefixed with AIGenerated with the wrong data type, and another prefixed with esrs mostly with correct data type.
In the screenshot below, you can see a sample Standard Requirement with duplicate concepts marked in the same color.

Moreover, a later release added two fields to Concept entity; Concept Group and Display Name, which were populated for the built-in S&G concepts, but not for the AIGenerated or esrs concepts released earlier.
This has become problematic for several reasons:
- Since both AIGenerated and esrs concepts are managed:
- We can't edit their data types.
- We can't assign them to Concept Groups or update their Display Name.
- We can't remove their links to Standard Requirements.
- When working with assessments:
- When creating an assessment based on the CSRD standard, the Assessment Requirements are automatically linked to both the AIGenerated and the esrs concepts. However, since they can't be modified, they're often unusable.
- To capture the correct data with proper naming, grouping, and data type, we have to create custom concepts and link them to the same requirement.
- This clutters the assessment and introduces unnecessary complexity because for each requirement, we end up with:
- One or more unusable concepts.
- One or more custom concepts that are actually used.

Are there any workarounds or any upcoming fixes?
It would be helpful if the demo data (i.e., built-in managed concepts) were provided in a separate solution that could be optionally installed. That way, we’d have the flexibility to adopt the OOB standard as needed and better tailor the implementation to the client's actual requirements.