Editor stops loading when many associations are stored in alignment documents #55

Summary

Alignment documents (frameworkType: "Alignment") work well with a limited number of associations (tested with 20). When we moved all associations between our frameworks into alignment documents, about 5,250 in 62 documents, the editor stopped loading.

Keeping the same associations inline, in the framework's own CFPackage, works without any problem. With #54 the editor shows these inline associations in the Associated Frameworks panel and stays smooth, also with this data set.

Setup

• 13 frameworks on one tenant (one overview framework plus 12 subject frameworks), the largest with about 6,000 items
• About 5,250 associations (two custom ext: association types) between items, both within a framework and across frameworks; up to about 900 originate in a single framework
• Self-hosted OpenCASE based on main (October 2026)

With a small alignment document: works

As a test, an alignment document with only 20 associations works as expected: the editor loads and the Associated Frameworks panel shows them. The problem only appears once there are many associations.

With all associations in alignment documents: editor stops loading

• 62 alignment documents: one per pair of frameworks that have associations (both directions in the same document) and one internal alignment per framework (participants [A, A]), together about 5,250 associations
• Every document validated against the official CASE 1.1 CFPackage schema; published through the management API
• After publishing, the editor no longer loaded after signing in
• The backend kept responding normally: /health, CFDocuments, CFPackages and CFItemAssociations all returned in a few seconds
• We did not find the root cause and restored the previous state

Inline with #54: smooth

The same 5,250 associations stored inline, in the CFPackage of the framework that holds the origin item:

• the editor loads normally and the public API returns them as expected
• with Show a framework's own associations in the tree view #54 the Associated Frameworks panel shows them: associations within the framework under "this framework", associations to other frameworks under that framework (resolved from loaded frameworks, else via the item's CFDocumentURI)
• a framework with about 500 associations within it and 430 to 10 other frameworks stays responsive

Still open: editing inline associations

#54 is read-only. The editor is not yet set up for inline associations on the editing side:

• associations created in the tree view are always saved to a separate alignment document, never to the framework itself
• alignment documents are hidden from the home screen, while API consumers that read a framework's CFPackage do not see the associations stored in them
• with the canvas view disabled, inline associations cannot be edited or removed in the editor

Supporting this would mean saving such changes with the framework's own CFPackage, which the tree view does not do today.

CASE 1.1 specification

The official CASE 1.1 documentation does not mention alignment documents. It does not describe them as bad practice either:

• associations between items of different frameworks are explicitly in scope ("allows one competency framework to be aligned to other competency frameworks"; cross-walks are mentioned in the information model)
• a CFPackage only requires a CFDocument, so a package without items is valid
• CourseCodes is the only predefined frameworkType; other values are allowed but not certified
• the specification does not prescribe whether associations are stored in the framework that holds the items or in a separate document

So alignment documents are an OpenCASE convention on top of CASE 1.1, and inline associations are equally valid CASE 1.1.

Question

Is inline (in the origin framework's CFPackage) the recommended way to store large numbers of associations between frameworks, with alignment documents meant for smaller, hand-made crosswalks? If so, we would be happy to help with the editing side, building on #54.