KRMS Constructs

Contexts, agendas, rules and propositions

Business rules in KRMS are placed into ordered sets called "agendas". The order of the rules in an agenda determines the sequencing, which rule gets evaluated first, second and so on, and the agenda also enables you to include conditional branching logic. In turn, agendas are placed into "contexts".

You can set up contexts ro represent any categories that are relevant within your institution, for example they could be document types or business processes or any other categories. In some university environments, the following might be relevant contexts: Awards, Proposals, IRB reviews, Course co-requisites, Course pre-requisites, Student plan evaluations, and so on.

Each defined context contains its own agendas, and each agenda contains its own rules. Rules aren't shared across agendas (though you can copy/paste, they become unique rule instances), and agendas aren't shared across contexts. There is no context hierarchy, that is, agendas and rules can't be inherited across contexts within any sort of hierarchy.

Rules consist of propositions, and KRMS supports the following proposition types: (more coming here)

Namespaces, types (and any other unique KRMS constructs?)

Data model (see reference section for more details)

(Other?)