Skip to content
- Ship the projection view with the rule set. Referencing the derived label is what triggers
evaluation, so a small view (
MATCH (p:PhoenixSuccessor) WHERE p.phoenixDepth >= $minDepth RETURN …) is how the label reaches every surface — the console, apps, the SQL door — with no
client work. realm-gov-uk’s views/phoenix-succession.yml is the model.
- A distance belongs in the projection view, not in the fixpoint. Chain length, depth and
shortest route are what authors most often reach for as derived properties, and on cyclic data a
property that recurses through its own value does not settle (§13.2). Conclude membership in the
rule set; measure in the view —
MATCH p = (c:Exposed)-[:DEPENDS_ON*1..10]->(v) … min(length(p))
is bounded whatever the data does.
- Rules conclude over data present in the graph — see §13.6, which is the single most important
thing to understand before writing a rule set over producer-backed types. Say the data contract in
the rule-set description either way.
- If the conclusion is plain reachability, use
*1..n and not a rule. A path that already
exists in the graph needs no fixpoint: the traversal is cheaper, and it reports its own truncation
(INCOMPLETE_TRAVERSAL, naming the hop it reached) where a rule set would simply answer. A rule
earns its keep when the conclusion is NOT reachability — aggregation inside the recursion, a
quorum (“cited by three already-influential papers”), a threshold, or a judgement propagated
along a path.
- Derived labels participate in visibility/tenancy like any label a query names.
- Name derived properties from the head and prefix them for the realm (
phoenixDepth, not
depth) — the label’s vocabulary outlives the file it was declared in.
