Österreich-Coverage-/Rechtematrix v1

Stand: 4. August 2026

Zweck

GET /api/v1/data-sources/coverage-matrix weist für alle neun österreichischen Bundesländer den Status jeder bekannten public_display-Quellen-/Fähigkeitskombination der öffentlichen Werkzeuge aus. Die Matrix trennt ausdrücklich:

• Registry- und Rechtestatus,
• zweckgebundenen Active Release,
• Distribution und Consumer-Fähigkeit,
• Coverage und regionale Evidenz,
• Freshness und Quality Summary,
• technische Consumer-Bindung,
• daraus abgeleitete Verfügbarkeit.

„9/9 dokumentiert“ bedeutet nur, dass kein Bundesland verschwiegen wird. unknown, gated und notConfigured zählen niemals als verfügbar.

Scope von v1

• Land: AT
• Regionen: ISO 3166-2 AT-1 bis AT-9
• Nutzungszweck: ausschließlich public_display
• Werkzeuge: pv-yield und site-check
• Export, Derivate, Rohdatenweitergabe und ml_ai sind nicht umfasst.

Die Lanes stammen aus dem technischen Consumer-Binding-Inventar. Zusätzlich wird google-solar/building_solar_lookup ausdrücklich als legacy_shadow-Lane mit ungeklärtem Scope ergänzt, damit diese bestehende öffentliche Verbrauchergrenze in der Matrix nicht verschwiegen wird. Eine statische Scope-Zuordnung beschreibt nur den erwarteten Vertrag. Sie öffnet keine Zelle. Noch nicht regional qualifizierte Legacy-Quellen bleiben für alle neun Bundesländer notConfigured.

Stabiler Schlüssel

Jede Zelle verwendet mindestens:

regionCode|sourceSlug|distributionKey|usagePurpose|capability

Der Lane-Schlüssel enthält dieselbe Identität ohne regionCode. WMS- und Snapshot-Kanäle sind getrennte Lanes und erben weder Rechte noch Coverage voneinander.

Ableitung

Die Matrix liest die redigierte öffentliche Source-Provenienz. Ein dort vorhandener Active Release belegt für den gespeicherten public_display-Kontext einen qualifizierten Release und ein damals gültiges Registry-Rechtegate. Für die konkrete Lane werden zusätzlich exakt geprüft:

1. Registry registered und Rechte conditional oder approved;
2. erwarteter Active-Pointer-Kanal;
3. erwartete Distribution;
4. erwartete Capability;
5. Freshness fresh oder notApplicable;
6. bestandene Quality Summary;
7. erforderlicher Coverage-Key und Status covered oder partial;
8. technische Bindung release_bound.

Der Coverage-Status wird nicht aus dem aggregierten Provenienzfeld abgeleitet. Die Matrix liest den konkret erforderlichen Key aus source_release_coverage und verlangt dabei weiterhin einen qualifizierten, aktiven public_display-Release. Fehlt diese key-genaue Evidenz oder wurde der Active Pointer zwischenzeitlich verschoben, bleibt die Zelle geschlossen.

PVGIS benötigt zusätzlich die hash- und release-gebundene öffentliche 45-Punkte-Evidence. Pro Bundesland müssen exakt fünf valide Referenzpunkte vorliegen. Ein kaputtes oder nicht mehr an den Active Release gebundenes Evidence-Artefakt sperrt alle betroffenen Zellen, ohne den restlichen Matrixvertrag zu erfinden.

Nationale partial-Coverage wird als availableWithGaps ausgewiesen. Regionale Pilot-Coverage wird nur im benannten Bundesland als availableWithGaps dargestellt; die übrigen acht Zellen sind outsideCoverage. Ein Format- oder Identitätskorpus ist kein Coverage-Nachweis.

Availability-Werte

Wert	Bedeutung
available	alle Gates bestanden, belegte Coverage ohne bekannten Coverage-Teilstand
availableWithGaps	alle harten Gates bestanden, aber belegter Partial-/Pilotstand
gated	mindestens ein Rechte-, Release-, Freshness-, Quality- oder Binding-Gate fehlt
outsideCoverage	außerhalb des versioniert belegten regionalen Pilots
notConfigured	Quelle/Capability sichtbar, aber regionaler Scope noch nicht qualifiziert

Reason-Codes nennen alle erkannten Grenzen. knownGaps bleiben davon getrennt: Ein fachlicher Modellhinweis wie „PVGIS ist keine Dachprüfung“ ist sichtbar, sperrt aber keinen ansonsten qualifizierten Standortmodell-Release.

Caching und Fehler

Der erfolgreiche Contract verwendet einen SHA-256-ETag über das vollständige DTO und unterstützt If-None-Match mit HTTP 304. Es gibt keinen requestabhängigen Zeitstempel im Hash; evidenceUpdatedAt wird deterministisch aus Activation-, Coverage-, Quality- und PVGIS-Evidence-Zeitpunkten gebildet.

Kann das Registry-/Release-Ledger nicht gelesen werden, antwortet die API mit HTTP 503 und Cache-Control: no-store. Die Dokumentationsseite zeigt dann keine Ersatzverfügbarkeit, sondern einen expliziten fail-closed Hinweis.

Österreich-Adapter und Canary-Harness

Das Österreich-Adapter-Harness liest diese Matrix als verbindliches Eingangsgate. Ein Quellenadapter darf einen Canary nur für eine Zelle mit available oder availableWithGaps und exakt passender Quellen-, Distributions-, Zweck-, Fähigkeits-, Kanal-, Release-, Pointer- und Coverage-Identität ausführen. gated, outsideCoverage und notConfigured bleiben unverändert geschlossen; ein Source Review oder vorhandener Consumer-Code ersetzt keine aktuell qualifizierte Matrixzelle.

Für PVGIS und SPARTACUS v3 werden ausschließlich die bereits dokumentierten 45 öffentlichen Referenzpunkte verwendet, fünf je Bundesland. Regionale Piloten dürfen erst mit fünf ausdrücklich für ihren exakten Scope versionierten öffentlichen Punkten angebunden werden. Die Canarys lesen nur; sie verändern weder Registry-Freigaben, Quellenstände, Active Pointer noch Coverage.

Erweiterung

Ein weiterer Nutzungszweck oder eine neue Quelle wird erst aufgenommen, wenn Distribution, Capability, Kanal, erwarteter Scope und das zweckspezifische Release-Gate versioniert sind. Insbesondere werden BEV-Exportrechte nicht aus public_display abgeleitet. parcel_dxf ist in seinem separaten Exportvertrag release-gebunden und seit dem vollständigen Produktions-, Parser- und Rollback-Readback #412 mit DXF_EXPORT_ENABLED=true kontrolliert aktiv. Der Consumer bleibt absichtlich außerhalb dieser Public-Display-/Standort-Check- Matrix; false ist sein nachgewiesener Rollbackzustand. NÖGIS bleibt bis zur distributionsweisen Qualifikation in #413 offen. Die SPARTACUS-v3-Migration aus #404 ist produktiv abgeschlossen.