A Capability Claim Has to Reach an Executable Path

A registry entry can describe a useful capability in convincing detail while the execution path underneath it remains incomplete. That gap matters because builders and agents use registries to decide what work a system can actually perform.

This factory cycle tightened the boundary between describing a capability and being able to execute it.

Current state

WTK uses registries to describe tools, capabilities, inputs, authority, and target bindings. Those descriptions make discovery and package construction possible without tying the governed package to one runtime.

But discovery metadata and executable behavior are different claims. A connector can have a valid schema, a useful description, and a plausible capability name while still lacking the concrete request path needed to perform one advertised action.

That creates a quiet failure mode. The catalog can look complete, package construction can select the capability, and only the compiled runtime reveals that the promised operation was never actually bound.

Changes

WTK now requires shipped connector capabilities to identify the execution path that implements them. The projection must show that the declared operation reaches an active request or target-supported acquisition path, that its required inputs exist, and that those inputs are actually bound into execution.

The same check now applies when a connector is introduced and when the Factory assembles a package. A capability may still be registered for discovery before it is runnable, but that state must be explicit. It cannot quietly appear as an executable option.

Applying the check to the current connector set exposed a concrete mismatch. A geocoding connector described both forward and reverse geocoding even though its active request path implemented forward search only. The unsupported reverse claim was removed until a separate executable path exists.

Failures observed

This was a development-time source-truth mismatch caught before broader distribution. It did not demonstrate an unsafe action, but it showed that the registry said more than the executable projection could support.

The mismatch exposed several ways capability metadata can overstate readiness:

• a capability name can be semantically correct but operationally unbound;
• a connector-level schema can contain inputs that a particular request never uses;
• a package can select a plausible capability whose target adapter cannot execute;
• a catalog can make registration look like runtime support.

Assumptions removed

We no longer assume that a valid connector schema proves every advertised capability is runnable.

We no longer assume that a capability selected during package construction will necessarily survive projection into a target.

We no longer treat registration, executable binding, runtime observation, and qualification as one status.

Evidence boundary

WTK now has a deterministic mechanism for checking that the current shipped connector claims map to declared execution paths and bound inputs. The mechanism also rejected one unsupported claim during the registry sweep.

That is bounded implementation evidence. It does not establish that every request succeeds, that a remote service returns useful or truthful data, that every target preserves the same behavior, or that static binding proves runtime qualification. A correctly wired action can still fail, exceed its authority, return poor evidence, or behave differently in another execution form.

No public evidence package has yet been published for this cycle.

Research question advanced

This cycle advances the question of whether registry discovery can remain useful without allowing registration to imply readiness. A public catalog can describe what a package intends to use, but stronger claims need an executable projection and target-local evidence.

It also sharpens the portability question. The capability can remain part of the governed package, while each target must show how that capability becomes runnable and what limitations the projection introduces.

Next hypothesis

Static projection fidelity should predict a cleaner runtime boundary without being mistaken for runtime proof. The next test should hold one governed capability, package, and input set constant across two supported targets.

For each target, WTK should retain the selected registry entry, executable binding, successful or refused action, sanitized receipt, and declared limitation. An unsupported projection should stop before execution. A supported projection should still earn its own runtime evidence rather than inheriting trust from the registry.