From bdc6b4863cd3f2a698dbd85cae61385350154d26 Mon Sep 17 00:00:00 2001 From: Doga Gursoy Date: Sat, 4 Jul 2026 16:14:41 +0300 Subject: [PATCH] Correct the Assembly id-derivation comment in the catalog The comment claimed the spine derives each Assembly's id as uuid5 over its name, matching Family and Role. The code does not: define_assembly mints a fresh per-registration UUIDv7, and content_hash equality is what makes an Assembly recognizably the same blueprint across facilities. The stale comment misled reasoning about how Assemblies are shared, so align it with the actual behavior and call out the contrast with the name-derived Family and Role ids. --- catalog/catalog.yaml | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/catalog/catalog.yaml b/catalog/catalog.yaml index 106e3f6bc2..3a6595e9e1 100644 --- a/catalog/catalog.yaml +++ b/catalog/catalog.yaml @@ -545,10 +545,14 @@ models: # portable rung is the Method. Authored Recipes, if any, belong in the # deployment docs, not here. -# Assemblies: reusable composition blueprints. The spine computes each -# Assembly's id (uuid5 over name) and content_hash; sub-assembly links reference -# the child by name. A beamline materializes these as Fixtures (slot -> Asset), -# which live in the deployment descriptor, not here. +# Assemblies: reusable composition blueprints. Each Assembly gets a fresh +# per-registration id when it is defined; the spine computes its content_hash +# from the blueprint. Two facilities that define the same blueprint get distinct +# ids but an equal content_hash, so content_hash equality (not a shared id) is +# what makes an Assembly recognizably the same across facilities. This differs +# from Family and Role, whose ids are derived from the name. Sub-assembly links +# reference the child by name. A beamline materializes these as Fixtures +# (slot -> Asset), which live in the deployment descriptor, not here. assemblies: - name: Optics note: >-