Skip to content
Embabel Worlds

16.3 What makes a view plannable

The realm author’s checklist. A view that meets it becomes a step in every plan that needs what it makes, in every world that installs it, with no wiring.

  1. It makes a named fact. It projects text into projected types (ai.fromText), writes a projected type or a declared projected relationship (§7.9), or returns an outputLabel that no world type already declares. A DERIVE rule set makes its derives: label or relationship.
  2. Every fact a goal may read has a description. Projected types and their relationships already must (§7.8); a rule set’s description describes its derives:; a view’s description describes its outputLabel. English mode (§16.9) chooses between facts by these descriptions, and a fact without one is never offered to it.
  3. Its parameters are typed by use. Text it reads into ai.fromText is a text input; a key it matches on a spine, or canonicalizes onto one, is an identity of that spine. Any other parameter needs a default: without one, the view is left out of every plan whose caller does not supply an input of that name.
  4. Its names are distinct from every other step’s. The engine refuses a variable reused across CALL {} bodies and the statement around them (§4), so a plan cannot combine two steps that share a variable or a RETURN column name. The compiler refuses the clash and names it; it never renames, because a rename it chose would be invisible in the pinned query. Choose names that say what they hold — raisedBy, untracked, tc — rather than n and x.
  5. It reads what it needs by label. A step that consumes another’s output matches the fact (MATCH (li:Issue)…); it cannot receive a variable, because no variable crosses a step boundary.

A realm validates the checklist where it can: a goal view it ships is planned at validation (§16.10), so a step that does not make what the goal needs is an error at the goal’s line, not a surprise in a world.