Parks must strip experimental metadata from instanced planter prims in a plaza assembly before release. Which authoring target is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Experimental stickers belong on the plaza draft, not on every planter in the city catalog. Strip them at the assembly with proper overrides.
Full Explanation
Parks should strip experimental metadata from instanced planter prims by authoring removals on the plaza assembly stage using valid override patterns for those instanced components. Experimental keys often accumulate during design reviews; before release, the plaza assembly is the right scope to remove them so the shared planter catalog is not rewritten for one plaza's experiments. Valid override/removal patterns at assembly keep the published plaza clean while leaving citywide planter prototypes stable for other parks.
Rewriting the shared prototype metadata so experimental keys vanish from every park citywide is the wrong blast radius if the experiments were plaza-local—and it may delete keys other sites still need. Deleting the planter kind registration from global plugInfo.json is unrelated to stripping metadata on instances and can break kind classification across the agency. Converting planters to imageable purpose-only proxies with no attributes discards real planter model data and is not a metadata cleanup strategy.
Exam caveat: prefer assembly-scoped cleanup over catalog mutation for site-specific experimental residue. If metadata lives on the prototype and must be removed globally, that is a catalog change with governance—not a silent plaza hack. Instancing constraints still apply to how removals are authored.
Operational check: compose the plaza with release layers, confirm experimental keys are absent from planter instances in the published package, open another park consuming the same planter prototype to ensure it was not collateral-damaged, and record the assembly override in the release notes.