Public-works needs one hydrant instance to drop a property that sibling instances must keep. Which pattern matches OpenUSD instancing constraints?
Select an answer to reveal the explanation.
Short Explanation
One hydrant needs a special exception—like one house on the block with a different mailbox. Use overs or deinstance that one; do not rewrite the shared prototype.
Full Explanation
When public-works needs one hydrant instance to drop a property that sibling instances must keep, the pattern that matches OpenUSD instancing constraints is to use overs or selective deinstancing so only that hydrant loses the property. Shared prototypes cannot express per-instance property deletion by editing the prototype attribute—that would remove the property everywhere. Selective deinstancing (or legally authored overs where the property and stage structure allow) creates a single exception hydrant while siblings continue to instance the shared civic prototype.
Editing the shared prototype attribute so composition removes it everywhere fails the 'only that hydrant' requirement and corrupts the fleet. Relying on chronological file save order to hide the property is not how USD composition works; save order is not a strength model. Specializing the hydrant under Payload strength to erase Local opinions misstates LIVERPS: payloads do not outrank local opinions, and specialization/payload tricks are not a correct property-removal pattern for one instance.
Exam caveat: LIVERPS distractors are common. Local opinions are strong; payloads are weak. Instancing exceptions for one prim usually mean selective deinstance or carefully scoped overs—not strength mythology or prototype edits.
Operational check: after the exception is authored, verify only the target hydrant lacks the property, siblings still have it, instancing remains for the fleet, and the exception is documented in the public-works overlay so future aggregators do not 'fix' by editing the prototype.