A Green Check Can Go Stale

A connection can be listed, configured, and previously checked, then still be the wrong thing to trust for the next governed action. A green mark with no time boundary is an invitation to confuse history with readiness.

Current state

WTK needs to know more than whether a tool exists in a registry. Before a governed run relies on it, the system must distinguish a declared connection from a currently available credential, a fresh check, explicit authority, and final usability.

Those are different facts. Collapsing them lets an old successful check make a missing credential or unapproved connection look ready.

Changes

This cycle made those readiness facts visible independently. A connection can now be described as declared but not usable when its required credential is absent, its earlier check is outside the defined freshness window, or its authority has not been granted.

The operator guidance follows the same boundary. It can ask for a credential, a retest, an authorization decision, or a usable connection without treating any earlier state as proof of the next one.

The check itself remains bounded. It reports whether the connection could be examined under the stated conditions. It does not prove that a later task will succeed, that the returned information will be relevant, or that the action is safe to perform.

Failures observed

This change contains several misleading shortcuts:

• treating a declared connection as an available capability;
• allowing a historical success to conceal a missing current credential;
• treating a stale check as evidence for a new run;
• assuming that a successful check grants action authority;
• presenting a tool as usable before all of its current readiness conditions are met.

Assumptions removed

We no longer assume that a green check stays green.

We no longer assume that registration, configuration, verification, authorization, and usability are interchangeable labels.

We no longer assume that a prior check can answer a present-tense evidence obligation.

Evidence boundary

WTK now has a bounded engineering path that keeps connection declaration, credential availability, check freshness, authority, and usability separate before recommending a tool for a governed task. It can preserve the difference between a past observation and a current readiness decision.

That does not establish that an available tool returns relevant or trustworthy evidence, that every runtime preserves the same boundary, or that operators make the right authorization decisions. It is an implementation observation, not a reliability result.

Research question advanced

This cycle advances the question of whether registration can remain useful without implying current readiness. A registry can describe the connection a package may need, but that declaration alone cannot establish that credentials are present, verification is fresh, authority has been granted, or the connection is usable now.

The same boundary matters when a package moves between runtimes. Its capability requirement may remain stable while credentials, verification, authorization, and usability must be established again for the selected target.

Next hypothesis

The next test should vary absent credentials, stale checks, denied authority, failed retests, and usable connections while holding the underlying evidence obligation constant. The result should show whether every state remains visible and whether an unsupported answer path stays blocked.