Catalog Boundary and Namespaces

The standard library defines the canonical connectors. Beyond it, this standard does not define which connectors exist, their names, or their contents. Vendor catalogs are published, versioned, and distributed independently.

A connector reference in a Workfile MAY be version-pinned, as helpdesk@2.1.0. When it is unpinned, the deployment environment resolves the version, and implementations MUST record the resolution.

Canonical and reserved namespaces

The following connector namespaces are canonical: the standard library defines their packages, and nothing else can.

Namespace	Holds
http	Generic requests: the bridge to a system that the catalog does not yet cover.
llm	Model actions: categorize, extract, summarize, generate, transcribe.
time	Schedules. The canonical home of the schedule trigger kind.
data	Content operations on files: checksum, parse.
store	Cross-run state: get, put, compare-and-set, and atomic increment on single keys.

wf is reserved: held for operations on workflows and runs, and not yet defined.

The canonical filter package namespaces are text, html, money, rank, workweek, human, url, markup, match, and phone. The standard library defines each, with the fixtures that the extension contract requires.

Three rules protect these names:

• An implementation MUST NOT bind a private connector or filter package to a canonical or reserved namespace.
• A catalog MUST NOT publish under one.
• Implementations MUST resolve each canonical namespace to its canonical package, at or above the pinned minimum version. A resolution that binds anything else is invalid, and the diagnostic is catalog.reserved_namespace.

The registry lists every canonical and reserved namespace.

A Workfile that references a vendor connector is portable between two implementations that support the same capabilities and resolve the same catalog. A Workfile whose references stay within the library is portable across every implementation of the portable profile.