Problem
The canonical flow in shared/discovery-instructions.md correctly says that the returned score is relevance-only and forbids automatic installation. Between presenting ranked results and giving installation guidance, however, there is no extension point for a client that already has configured task-specific eligibility facts and policy.
Consider two results:
- rank one is the most relevant but fails a configured capability, evidence, or authority requirement;
- rank two is slightly lower-ranked and satisfies the requirement.
A top-result-only check stops even though a lower-ranked eligible result is available.
Proposed contract addition
Would the project accept a small, opt-in addition to the shared interaction contract stating that:
- relevance score is not eligibility evidence;
- when the client has configured external facts and local policy, it may evaluate returned candidates before recommending one;
- backend rank is preserved among candidates that satisfy the configured requirements;
- missing facts are not invented, and indeterminate results are explained;
- the connector still never installs or invokes a resource automatically.
This would be implementation-neutral. It would not add a dependency or require every connector to perform eligibility checks.
Working reference
I validated this integration boundary in ARDGuard 0.1.0b3, an external eligibility and fallback implementation. It can consume an ARD SearchResponse through JSON stdin/stdout or a loopback HTTP service, preserve backend ranking, return an explained selection/fallback/defer decision, and never install or invoke the selected resource. The concrete integration paths are documented in its integration guide.
ARDGuard is only a reference implementation for the seam. This proposal does not ask ard-connectors to depend on it or standardize its API.
Scope
I have a documentation-only patch ready for the canonical shared instructions. It changes no finder selection, ARD ranking, endpoint, schema, installer, or executable code. If this direction fits the project, I can submit that focused patch and propagate the agreed wording to the embedded platform instructions.
Problem
The canonical flow in
shared/discovery-instructions.mdcorrectly says that the returned score is relevance-only and forbids automatic installation. Between presenting ranked results and giving installation guidance, however, there is no extension point for a client that already has configured task-specific eligibility facts and policy.Consider two results:
A top-result-only check stops even though a lower-ranked eligible result is available.
Proposed contract addition
Would the project accept a small, opt-in addition to the shared interaction contract stating that:
This would be implementation-neutral. It would not add a dependency or require every connector to perform eligibility checks.
Working reference
I validated this integration boundary in ARDGuard 0.1.0b3, an external eligibility and fallback implementation. It can consume an ARD SearchResponse through JSON stdin/stdout or a loopback HTTP service, preserve backend ranking, return an explained selection/fallback/defer decision, and never install or invoke the selected resource. The concrete integration paths are documented in its integration guide.
ARDGuard is only a reference implementation for the seam. This proposal does not ask ard-connectors to depend on it or standardize its API.
Scope
I have a documentation-only patch ready for the canonical shared instructions. It changes no finder selection, ARD ranking, endpoint, schema, installer, or executable code. If this direction fits the project, I can submit that focused patch and propagate the agreed wording to the embedded platform instructions.