docs(adr): propose 0014, one declared value per OGC service

[thodson-usgs]

Summary

Proposes ADR 0014, Describe each OGC service with one declared value, and the glossary entries it needs. Docs only, opened as a draft so the design is reviewed before it is implemented. Once the record is agreed, the implementation will be generated from it and added to this PR, which is where the record will be marked Accepted.

Why

Reviewing #442 and #443 turned up service-specific facts hard-coded in the shared OGC code: Water Data's date parameter names listed as "the OGC date parameters", a last_modified exemption by name, duration pass-through for every service, and one open-start spelling (../), which the NGWMN and STAC firewalls reject with HTTP 403. ADR 0003 stops ogc from importing a service. It says nothing about naming one, and a string literal is not an import. #443's review missed the open-start regression because no rule covered it.

What the record decides

• An adapter declares one OgcService(adapter, base_url, dialect), and that is everything the shared code knows about the service. Core entry points take it as their first argument.
• The core implements the OGC standard. Each place a service departs from it is one dialect field whose default is the standard, documented with the observed server behavior.
• The core names nothing an OgcService declares.
• Dialect fields are grouped by the code that reads them: DateDialect (also used on its own by the STAC ratings catalog), request construction, result shaping.
• Collection facts (output_id, spatial) stay per call.
• Services and dialects are data passed to functions, not clients, methods, or subclasses.
• Dates are formatted once, before planning.

Compliance: a fitness function over string literals in ogc/, live monitors for each dialect field, and four recorded variances.

Review questions

1. Are the OgcService fields and the split between per-service and per-collection facts right?
2. Is base_url as a function (resolved once per call) acceptable as the one non-data field?
3. Are the four variances the right ones to defer?

Sequencing

#442 and #443 merge first, unchanged. This branch is based on main. After it is reviewed, I'll rebase it onto main with both merged and add the implementation. A prototype of the date-dialect part already exists on thodson-usgs:refactor/ogc-date-dialect and will be regenerated from the final record.

Tested

The docs build has no warnings from the new record, and tests/architecture_test.py passes, including the ADR-reference check. The server behaviors in the record's Context table were observed live on 2026-10-11.

[thodson-usgs]

Superseded by #445. Its ADR 0014 generalizes this proposal: the name and default URL belong to a package-wide Service declaration, not an OGC-only value, and each API is an Endpoint with its own dialect.