>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3550896. --> Reported by: [marcus_johansson](https://www.drupal.org/user/385947) >>> <p>--- AI TRACKER METADATA ---<br> Update Summary: Do not use taxonomy for categorization<br> Check-in Date: MM/DD/YYYY (US format) [When we should see progress/get an update]<br> Due Date: MM/DD/YYYY (US format) [When the issue should be fully completed]<br> Blocked by: [#XXXXXX] (New issues on new lines)<br> Additional Collaborators:<br> AI Tracker found here: <a href="https://www.drupalstarforge.ai/">https://www.drupalstarforge.ai/</a><br> --- END METADATA ---</p> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Currently the module uses taxonomy to organize contexts, however this causes a lot of problems when working with deployments or recipes, because it mixed config entities with content entities.</p> <p>Problem #1:<br> You add a new taxonomy term on development for a , that has a specific ID. Because production has more taxonomy terms added by editors, shipping it on id does not work anymore. This means that you have to manipulate the configs to use uuid instead and somehow ship you taxonomy term as well as a content recipe or something similar.</p> <p>Problem #2:<br> You add a recipe, where you create the generic term "Information Context". Since we can ship content and we use UUID's in this case, this works nice. Another person ships a recipe unbeknown to you with the generic term "Information Context", with another UUID. All of a sudden you have the same term twice.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>If this is just to be searched or filtered on, and if we assume you will not have 10k+ context, can it just not be a simple multi string field?</p> > Related issue: [Issue #3559379](https://www.drupal.org/node/3559379)