Explore unifying DMN storage and execution path for custom and library checks

We have complexity arising from the differences in how custom checks and library checks are created, edited, stored, and used in the web app.

Assumption/ideal to explore: All checks should exist under a single "library" paradigm. They should be implemented as similarly as possible and managed via web interface. The difference between "custom" and "library" should come down to permissions and sharing logic.

Advantages:

• less complexity in the web app's code paths and in the "eligibility check" concept. (one paradigm instead of two)
• one interface for creating/managing
• opens up interesting features like sharing checks, duplicating/modifying library checks, promoting custom checks to the library, using existing library checks within a custom check, etc.

Probable challenges:

• keeping the library usable as a standalone API
• the difference between how custom and library checks are currently implemented (e.g. more boilerplate and DMN know-how are required for library checks)
• significant UX challenges to ensure proper editing of checks with guardrails necessary (simplifying or otherwise improving the default DMN-editing experience)

Inizia mappando come i controlli personalizzati e quelli della libreria vengono creati, modificati, archiviati e utilizzati nell'app web, quindi esamina i vincoli del mantenere la libreria come API autonoma. Per considerare concluso il lavoro, sarebbe necessario aver definito un modello di libreria unificato, con le differenze relative alle autorizzazioni e alla condivisione stabilite e l'esperienza di modifica di DMN affrontata.