Registries

Registries define the vocabulary a Datalog policy is allowed to use. A Datalog rule can mention predicates such as owns, shared_with, blocked, or allow, but the Datalog engine does not know what these names mean by itself. The application must first declare which predicates exist, how many arguments they accept, and how they may be used.

In Maelys DL, this is a core security boundary:

For programming details, see C Stable registries, Python registries and TypeScript registries.

Why registries exist

A Datalog engine can evaluate rules generically, but applications need their own vocabulary. For example, a document-access application might need:

owns(User, Document)
shared_with(User, Document)
blocked(User)
allow(User, Document)

A graph application might need:

edge(From, To)
reachable(From, To)

A decision engine might need:

safe(Request)
allow(Request)
deny(Request)

The Datalog engine should not hard-code any of these names. Instead, each application registers a domain that declares the predicates policies may use. For the application, the important object is the domain definition: it lists the predicates that a policy may use. Registering that definition makes the domain available to policy loaders. A manifest may then restrict which of its QUERY predicates callers can inspect, but cannot add predicates.

Where registries fit

The application registers a domain such as documents, declaring owns/2, blocked/1, and allow/2 once. When a policy selects documents, the loader installs those same declarations in a predicate registry belonging to the loaded policy, freezes it, and checks the policy source against it. This is an implementation step, not a second vocabulary for the application to maintain.

For policy A or B, the loader repeats the last three stages. The application registers documents only once; it never defines a second vocabulary for each policy.

Architectural model

Three layers govern how a policy is loaded and evaluated.

Predicate kinds at a glance

Three roles describe where facts come from; QUERY is a separate observation permission. A predicate has one origin and may additionally be query-enabled.

For example, IDB|QUERY declares a derived relation that may be queried. QUERY never stands alone: it does not say where the facts come from. The C predicate flags describe the corresponding declarations.

Domain-closed vocabulary

Maelys DL uses a domain-closed vocabulary model. That means every predicate used by a policy must be accepted by the selected domain. A policy cannot invent predicates during loading, and a manifest cannot add predicates to the domain. For example, this policy:

helper(X) :- safe(X).
allow(X) :- helper(X).

requires the selected domain to declare:

safe/1    EDB
helper/1  IDB
allow/1   IDB|QUERY

If helper/1 is not declared by the domain, loading fails.

Example domain: document access

Suppose an application wants to evaluate document access rules. The application wants this vocabulary:

A policy in this domain might contain:

blocked("mallory").
allow(User, Document) :-
    owns(User, Document),
    not(blocked(User)),
    sensitivity_level(User, Level),
    Level >= 3.
allow(User, Document) :-
    shared_with(User, Document),
    not(blocked(User)),
    sensitivity_level(User, Level),
    Level >= 3.

The extra sensitivity_level/2 guard adds a numeric threshold: ownership or sharing alone is not enough, the caller must also meet the minimum level.

This example also declares "mallory" in the domain's atoms, because that string is written in policy source. This permits the constant; it does not insert blocked("mallory"). The policy fact itself does that. By contrast, request values such as "alice" and "roadmap.pdf" need not be declared as atoms when they are supplied only in the EDB.

In this example:

The application supplies runtime facts such as:

owns("alice", "roadmap.pdf").
shared_with("bob", "roadmap.pdf").
sensitivity_level("alice", 4).
sensitivity_level("bob", 3).

The policy declares policy facts such as:

blocked("mallory").

The solver derives facts such as:

allow("alice", "roadmap.pdf").
allow("bob", "roadmap.pdf").

Both users satisfy the Level >= 3 guard, so the solver still derives allow/2 for each of them. A user with a lower sensitivity level would not derive allow/2 even if the ownership or sharing fact were present.

Whether callers may publicly inspect allow/2 depends on the loading path:

Two registries, one declared vocabulary

For example, two policies can both select documents. Each loaded policy gets its own predicate registry for validation, but both use the vocabulary of the same registered domain. Loading a second policy does not require registering the domain again and cannot silently add a new predicate.

Predicate identity and freeze

A predicate name identifies one relation with one arity: if owns/2 is declared, the same domain cannot also use owns/1 for a different shape. Give different relations different names. A loaded policy receives the selected domain's declarations in an open predicate registry; before parsing, that registry is frozen. The parser then rejects unknown names and wrong arities, and a manifest cannot extend the frozen vocabulary.

Freezing is a loader step, not an extra call required by the public domain API. A domain defines the available vocabulary; a manifest selects a domain and restricts public observation.

What you have learned