When design tools talk about components, the conversation often turns into asset libraries or model download sites.

For an agent harness, the component library is first a machine-readable placement contract, not a gallery. The agent needs to know how an object should be understood, placed, validated, and referenced.

That is the purpose of a Semantic Component Registry.

A .skp file is not enough

A SketchUp component file can contain geometry, but the agent needs more:

  • category;
  • dimensions;
  • bounds;
  • insertion point;
  • anchors such as wall or floor;
  • front, left, and right clearances;
  • placement rules;
  • asset path and fallback;
  • source and redistribution metadata;
  • search aliases across languages.

Without that metadata, the agent can only “find a model.” It cannot reliably decide how to place it, where to place it, whether it fits, or whether it violates spatial rules.

The registry is a reasoning contract

SAH’s component registry lets the agent reason through machine-readable manifests.

When a user says “place the mirror above the vanity,” the agent should not only search for “mirror.” It needs to know the mirror’s dimensions and bounds, the vanity or sink position, the relative relationship, whether wall provenance should be reused, whether the result enters design_model.json, and which entity id comes back from SketchUp execution.

This is not an asset search problem. It is a semantic placement problem.

Project-local components matter

The product can ship a seed library, but real designer projects will have their own local components.

SAH supports project-local component_library.json, and assets.lock.json records the components actually referenced by the project. This solves two problems:

  • the project can reproduce which components it used;
  • the product does not need a full public asset marketplace on day one.

Project-local components may come from a local .skp, a selected SketchUp object, an external model, or manually registered metadata. Regardless of source, they need semantic fields before entering agent workflow.

Geometry is the asset. The manifest is the contract the agent can reason about.

Asset lock is the reproducibility boundary

assets.lock.json should not record the entire component library. It should record what the current project actually references.

That lets the project know which component ids are used by which instances, where local cache paths point, what source and redistribution metadata exist, whether procedural fallback exists, and whether an asset is merely referenced or already cached.

This is similar to dependency lockfiles in software projects. The project needs to know what it actually depends on instead of assuming the registry will always be available.

Procedural fallback helps early product slices

Early in the product, real .skp assets may be incomplete. SAH supports procedural fallback so the bridge can create box-like placeholders from dimensions.

That is not a final visual-quality strategy, but it is valuable for a vertical slice: component search can work, placement and clearance can be validated, bridge execution can return entity ids, and the asset pipeline can improve gradually.

The developer tradeoff is clear: establish the semantic and execution loop first, then enrich the asset library.

License and provenance are architecture fields

Components are not only geometry. In design software, source and redistribution rights affect product behavior.

If an agent helps a user use external models, it should be able to record source, redistribution metadata, and cache state. Otherwise publishing, sharing, migration, and commercial use become unclear.

That means provenance should not live only in documentation. It belongs in component metadata and asset locks.

Source trace