A water utility must represent valve-actuator state beyond what stock UsdGeom provides. What should developers create?
Select an answer to reveal the explanation.
Short Explanation
Stock geometry schemas do not know about actuator state—that is plant language. Give it a typed custom schema so the twin speaks utility fluently.
Full Explanation
A water utility representing valve-actuator state beyond stock UsdGeom should create a typed custom schema that defines the proprietary actuator attributes. UsdGeom covers geometry and related imageable concerns; actuator state (open/closed percentage, fail position, SCADA tags, etc.) is domain data that belongs in a purpose-built schema so import/export, validation, and viewers treat it as first-class typed information rather than folklore on prims.
A camera orthographic projection named after each valve is nonsense categorization and stores no actuator state. A pointInstancer prototype list with no properties does not model actuator attributes. A muted sublayer containing only displayColor opinions addresses appearance, not utility actuator semantics.
Exam caveat: when stock schemas are insufficient for proprietary operational fields, define a typed custom schema (and ship it with the utility's pinned USD runtime). Do not overload unrelated prim types or mute layers as a faux schema.
Operational check: generate/apply the typed schema, author actuator attributes on valve prims, validate types in the composed stage, round-trip through the utility's import/export path, and confirm operator-facing viewers read the fields with the schema plug-in loaded.