Re-categorize modules by function (type vs info); reshape record and merge locator into descriptor

[akijakya]

Summary

Re-categorize module classes by function instead of the current core vs integration split, then reshape the record object around that categorization and fold locator into the module descriptor.

This is a design proposal / discussion — feedback welcome before implementation.

Motivation

Modules naturally fall into two functional groups:

1. Type-defining modules — they determine what the record is / how it is consumed: a2a (A2A card), mcp (MCP server), agentskills (Agent Skill), and likely acp, agentspec.
2. Informational modules — they carry additional information about the record: evaluation, observability.

The current core vs integration taxonomy does not mirror this: e.g. agentskills lives under core/language_model but is type-defining, while evaluation/observability are core but informational. Categorizing by function makes the taxonomy meaningful and lets the record express the distinction structurally.

Proposed changes

1. Module taxonomy

Replace the core / integration categories with two function-based categories (names TBD — see open questions), roughly:

• type category: a2a, mcp, agentskills, acp, agentspec, plus a generic type module — a concrete, protocol-agnostic default so every record can satisfy the required type attribute even when it isn't one of the specific protocols.
• info category: evaluation, observability

language_model and prompt are likely no longer needed and are candidates for deprecation rather than re-categorization — to be confirmed during design.

2. record object

• Add a required attribute scoped to the type category — every record must declare at least one type-defining module. (This is the enforced-scoping use case from the validator/UI work; once Enforce class_type taxonomy scope in the runtime validator and the schema UI link #476 lands, scoping a class_t attribute to a category is enforced end to end.)
• Keep an optional attribute scoped to the info category for the informational modules.

This replaces the previously-floated integration_types idea (which was based on the integration category) with a functional categorization.

3. Fold locator into the existing descriptor object, drop top-level locators

objects/descriptor.json is already an OCI-like artifact descriptor (urls, media_type, artifact_type, size, digest, …) and is already embedded in every module — the base module's artifact attribute is "type": "descriptor". It overlaps heavily with objects/locator.json (type, urls, annotations). Proposal:

• Fold locator's distinguishing fields (notably its type enum: helm_chart, container_image, package, source_code, binary, url) into the existing objects/descriptor.json.
• Artifact locations therefore live on the module that owns them (through its artifact/descriptor), rather than as a flat top-level list.
• Remove the top-level record.locators attribute, and remove/deprecate objects/locator.json.

Out of scope / sequencing

• Depends on Enforce class_type taxonomy scope in the runtime validator and the schema UI link #476 (class_type scope enforcement in validator + UI) so the new required/optional attributes are actually enforced.
• Proto (record.proto, module/descriptor messages) and the runtime validator/sample fixtures will need matching updates.

Open questions

1. Naming of the new required attribute. type is the first instinct, but it now both (a) declares the record's type-defining modules and (b) subsumes the former locator role (where the artifact lives), so it should convey "what this record is / how to obtain it" better than locator did. Candidates to consider: interfaces, manifests, connectors, entrypoints, endpoints, surfaces, kinds, or types. And the optional counterpart for informational modules: keep modules, or extensions / metadata / aspects / info.
2. Exact category names, the contents of the generic type module, and confirming deprecation of language_model/prompt.
3. How much of locator (the type enum) belongs on the merged descriptor vs is inferable from media/artifact type.
4. Migration/back-compat for existing records that use top-level locators and the core/integration module names.