D72 gives Decisions a real authority hierarchy -- Domain, Area, and Root -- replacing the flat Scope string every governance check has read since the beginning. D71 adds Set, a way to group items across types for the "whole model" reading Pulse has wanted for a while. Both needed new edges. Neither needed a new compiled type.
The type nobody in core should name
decisionScopeRoles -- the map that's supposed to say which role can ratify a Decision in which Scope -- has shipped empty since the day it was written, on purpose. Core doesn't know what Scope values a given instance uses, and it shouldn't: those values are this project's own vocabulary (core/cloud/brand/...), not something every self-hoster running Smeldr for a completely different kind of organization would share. That's the same reason Task.Band was never a fixed enum.
Domain and Area follow the same rule. They're dynamic content types an instance defines for itself, the same mechanism define_content_type already offers for anything else per-instance -- not new compiled Go structs. The core-side work D72 actually needs is two new relation kinds connecting a Decision to whichever Domain/Area node it belongs to, plus one more for Set. Three table rows, not three new files.
A casing question worth stopping for
Every existing relation kind here connects two compiled types -- Decision, Task, Goal -- and every one of them is capitalized, because that's literally the Go struct's own name, and nothing normalizes it on the way in. Domain and Area are the first kind in this function to point at a *dynamic* type instead, and dynamic types have their own, separate convention: lowercase, the same shape as recipe or tag in this project's own tests. Get the casing wrong here and every edge that follows it silently stops matching. It's not enforced anywhere -- no schema validates the string, no registry normalizes it -- so it only had to be gotten right once, in the one place it gets defined.
The question that answers itself
D72 leaves one thing open on purpose: should a Decision be blocked from having two Domain edges at once? Checked before answering: there's no cardinality concept anywhere in this system's relation kinds -- a kind restricts *which* types can connect, never *how many* edges can exist. Built here, that would be a new mechanism nobody has asked for yet, for a constraint that already holds by construction anyway -- the migration that populates these edges reads one Decision, one Scope value, one edge, every time. The question that would need an answer is a different one: what happens when something *other* than a one-time migration tries to reassign a Decision's Domain. That's a write path that doesn't exist yet, so it's not this task's answer to give.
What's not here yet
This ships the edges a Domain assignment travels along. It doesn't ship the Domain nodes themselves, or the migration that moves every existing Decision's Scope string onto one. That part needs to run against the actual instance it's migrating -- not something a library release can carry by itself -- and lands as its own, separate piece of work.