Configuring Community Edition.
General setup: connecting your organization's entity and jurisdiction data (feeding the Applicability Engine), setting up users and roles, and connecting your first integrations.
The three configuration surfaces
- Entities and jurisdictions
Your legal entities, sectors and member states — the facts the Applicability Engine reasons over. Get these right and the applicability questions get answered; get them wrong and every downstream mapping inherits the error.
- Users and roles
Role-based access aligned to the same accountability model the platform preaches: named people, scoped permissions, no shared accounts. Administration is an audited activity, not a side channel.
- Integrations
Connector configuration for the tools you already run — read-only credentials, entity scoping, and sync settings per source, following the same model documented across the integration pages.
Configuration is data, not ceremony: declarative settings you can hold in version control, diff on upgrade, and restore on rebuild. The instance you run is reproducible — which is the whole point of self-hosting something inspectable.
The order of the three surfaces is also the order of consequence. Entities and jurisdictions feed the Applicability Engine — every applicability answer downstream inherits those facts, so they are configured first and checked hardest. Users and roles come second, because access before content means administrators configuring an empty system. Integrations come last, once there is an organization for their data to land in.
From here, the one decision that shapes day-to-day operation is the AI inference source.
A misconfigured integration fails loudly and locally — a sync that cannot authenticate reports exactly that, against the entity it was scoped to. Silent partial ingestion is treated as a defect, not a convenience.
Configure your AI inference source