DiceOwnedSchema

What a node in a graph has to look like for dice to own it: the labels dice's own storage writes, and, per label, the properties dice writes on every such node. Plus the relationship types dice writes for its own bookkeeping.

Why ownership needs saying at all

A drift check compares the domain schema an app declared against what a live graph holds, and it shares that graph with dice's own storage. Nothing dice writes for itself belongs to a declared domain schema, so counting those nodes would report dice's bookkeeping as drift on every run, and would make governance report itself: stamping a version and writing a drift report both add nodes to the graph the next check observes. DrivineObservedSchemaSource subtracts what an instance of this class describes.

Names alone can't decide it. An app is free to govern its own type called Source, and hiding every (:Source) node would hide that type from every report it should appear in. So ownership is decided by shape: a label counts as dice's only while every node wearing it carries the properties dice's own writer always writes.

The real invariant: ownership covers what the application registered

of takes the DiceStorageSchema beans the running application registered, so the exclusion covers every dice store that application wired, whenever it was written. A store added by a later slice takes part by being registered, with no edit here.

The converse is the honest half, and it is the behaviour to expect: a dice store whose schema the application never registered stays visible to observation. Its nodes are then reported as domain drift, which is right — an application that never declared the store to Drivine has told dice nothing about those nodes, and an observation reporting an unexplained label is the correct answer. The way to hide a store's nodes is to register its schema, which is the same act that gives the store its constraints; see diceStorageCatalog.

The shapes come from the schema definitions

Nothing here is a hand-kept list of property names. Each shape is read out of the definition the store already writes from, so the two cannot disagree:

• Node fragments (PropositionNode, Mention, SourceNode, ProcessedChunkNode) carry their label in @NodeFragment and their properties as constructor parameters. The shape is every parameter dice's writer cannot leave out: declared non-null, with no default value to fall back on. Optional and nullable ones stay out, because a node dice wrote is allowed to be missing them, and demanding one would make dice's own nodes look foreign and bring back the self-reporting case above.

• Cypher-backed stores — every registered DiceStorageSchema — declare their labels and natural keys as uniqueness constraints. The shape is the union of the key properties for that label, which is exactly what those stores MERGE on, so every node they create carries all of them.

The four node fragments are in every ownership set, registered or otherwise. They are the core proposition store, and DrivineObservedSchemaSource reads propositions and mentions through their shapes to answer what a graph's extractions claimed, so an observation that could not recognise them could not run at all. DiceStorageSchemaRegistrationTest fails when a new @NodeFragment class appears in the storage model package and is missing from CORE_NODE_FRAGMENTS.

Where the boundary genuinely blurs

A shape is a claim about properties, so a domain node carrying all of dice's properties for a label it shares is indistinguishable from dice's own. A host that keeps (:Source {key, kind}) nodes of its own meaning has built dice's exact shape, and that type stays out of whole-graph observation until dice writes an ownership marker at persistence time, which is a data migration for existing graphs and a decision for a later change. Everything short of that is caught: a domain (:Source {key}) with no kind keeps Source observable, as does any other domain node missing a property dice always writes. Context-scoped observation avoids the question entirely, since it reads mention types and edges marked as projected from domain data.