spec(6.3.2): an absent next_available_date must not rank as available

[danieljaffe1]

The gap

§3.6 makes next_available_date optional and never says what its absence means to a consumer. That is the defect, and the natural reading of the field inverts it.

A producer that samples a bounded horizon has no date to publish precisely when nothing in that horizon is open — that is, when the service is fully booked. So an implementation that resolves the absent field to a numeric zero and measures the distance from now awards its largest boost to the services a buyer is least able to book. Not hypothetical: on a live registry index, 3 of 9 returned services carried a valid hint with no next_available_date.

A second registry implementing ranking from this specification alone hits the same trap, because nothing here tells it not to.

What this adds

§6.3.2, two rules:

1. An absent next_available_date is neutral, never maximal. Its contribution MUST be identical to that of a service carrying no hint at all, and MUST NOT be read as availability today or as the nearest possible date.

2. The hint is not an input to matching. §6.3's MUST NOT use the hint as a hard availability filter governs matching: a hint's value MUST NOT cause a service to fail the request's filters or otherwise leave the matched set. Registries SHOULD apply the signal in a re-ranking phase over the already-matched set, so that holds structurally rather than by convention.

Rule 2 also states its converse, and that sentence is load-bearing: ordinary ranking effects within a bounded result window are not exclusion. An earlier draft of this PR required that every matched service "remain reachable by paging the full result sequence" — which is unsatisfiable. A registry pages a bounded window (the reference implementation retrieves the top 500 by score and reports no further pages), and text relevance and geo distance already decide window membership. Requiring otherwise would make every registry backed by a real search engine non-conformant, so the spec says so explicitly rather than leaving the next implementer to discover it.

Plus the enabling MAY, and cross-references from the §6.3 pass-through paragraph and the §3.6.1 use-case table.

What this deliberately does not specify

Not how a registry weights or composes the signal. §6.3.1 already leaves ranking registry-defined, and that is the right default here: no response distinguishes a registry that multiplies its freshness factor from one that adds it. A normative rule that cannot be tested from the wire is a design opinion in spec clothing.

So there is no weight, no decay curve, no horizon, and no scoring formula in this PR — those belong in registry implementation guidance. An earlier draft carried all of it (a freshness-composition SHOULD, a refresh SHOULD, a disclosure SHOULD, and a worked scoring table: 106 lines, 15 RFC-2119 keywords). The refresh SHOULD in particular was redundant — §3.6 already says businesses SHOULD regenerate every 1–6 hours and §6.3 already says registries SHOULD re-index at most every 24 hours.

Scope

No wire change — nothing new is sent or returned, so schemas/, openapi/ and openrpc/ are untouched.

File	Change
specification.md	§6.3.2 (+32 lines), TOC entry, two cross-references
site-docs/specification/discovery-registry.md	mirrored section (same-change-set site sync per AGENTS.md)
site-docs/specification/service-catalog.md	one pointer from the Availability Hint section
CHANGE_LOG.md	entry

Verification

• tools/usp_check.py all → schemas: ok, refs: ok, vectors: ok, authority: ok (run against a built site, so authority exercises rather than skips)
• mkdocs build --strict exits 0; the new #availability-hint-ranking anchor resolves on the registry page and the cross-page link from the service-catalog page resolves to it
• Both rules checked against a shipped implementation: its rank profile guards the absent date (if (attribute(availability_next_date) > 0, …, 0)) and applies the term in second phase only, so it never participates in matching

🤖 Generated with Claude Code