has_netclass_defs

one row when the design declares net-class definitions at all (absent it, a declared-vs-actual rule has no limit to compare against and reads clean)

What it is

has_netclass_defs(present) yields exactly one row, with subject true, when the design declares any net-class DEFINITIONS at all. No rows otherwise. It is the design-level marker for the declared side of a declared-vs-actual comparison.

For hardware engineers

It answers “does this project state what its classes are supposed to route at?” before you trust any answer that depends on it. A conformance check over a project that declares nothing has nothing to check, and that is a different result from a project that checks out clean.

For software engineers

Deliberately distinct from has_netclass, because membership and definitions are independent. net_settings carries assignments and class definitions in separate blocks, so a project can assign nets to a class it never defines, and can define classes it assigns to nothing. A declared-vs-actual rule needs the DEFINITIONS. Gating it on the membership marker would let a project with assignments and no definitions report a clean pass over zero comparisons.

Same shape and purpose as has_netclass, has_nc_channel, and types_power_out: a design-level presence row that lets an ad-hoc query ask whether a question is answerable on this design before trusting the answer.

Go projector

hasNetClassDefsFacts in stdlib/relations/facts.go emits the single row when Model.NetClassDefs() is non-empty.

Absence is not a pass

That is what this relation is for. It is the queryable half of the gate; the rule half is the capability a declared-vs-actual rule declares, so check.Available reports not-applicable with a reason instead of letting the rule find nothing and read clean.

Datalog

Ask whether the project constrains anything before comparing against it:

has_netclass_defs(?_), net.declared_track_width(?net, ?mm) => ?net, ?mm