Roadmap¶
Die folgenden Punkte sind für die weitere Pilotphase und die Zeit danach vorgesehen. Es handelt sich um beabsichtigte Ausbaustufen, nicht um Zusagen mit festem Termin — der Pilot dient gerade dazu, vor größeren Festlegungen echte Erfahrung zu sammeln (siehe Pilotprogramm). Was bereits umgesetzt ist, steht im Änderungsprotokoll.
Anmeldung ohne manuellen Schritt¶
Die Selbstregistrierung neuer Autor:innen (E-Mail-Bestätigung, Zustimmung zu Datenschutz und Nutzungsbedingungen) ist als fertiger Ablauf für die zentrale Anmeldeinstanz beschrieben, aber noch nicht produktiv scharf geschaltet. Bis zum Livegang dieses Ablaufs erfolgt eine Kontoeinrichtung manuell.
Signaturzertifikat für den Produktivbetrieb¶
Erzeugte PDF-Dokumente werden plattformseitig signiert — derzeit mit einem selbst ausgestellten Zertifikat der Betreiberin. Für den Produktivbetrieb ist die Beschaffung und Einbindung eines von einer Zertifizierungsstelle ausgestellten, dauerhaften Signaturzertifikats vorgesehen. Auch danach bleibt die Bezeichnung „plattformseitig signiertes Offenlegungsdokument“ — ausdrücklich keine qualifizierte elektronische Signatur und keine inhaltliche Bestätigung durch Dritte (siehe Grundsätze).
Institutionszertifikate beim Signieren¶
Institutionen können bereits ein eigenes Signaturzertifikat hinterlegen (siehe Einsatz in Institutionen). Vorgesehen ist, dass PDF-Dokumente von Records, die einer Institution zugeordnet sind, zusätzlich oder anstelle des Plattformzertifikats mit dem Zertifikat dieser Institution signiert werden. Bis dahin signiert die Plattform ausschließlich mit ihrem eigenen Zertifikat.
Englischsprachige Oberfläche¶
Die Mehrsprachigkeit ist technisch bereits vorbereitet; derzeit existiert jedoch nur die deutsche Übersetzung (mit einem einzelnen, bewusst englisch belassenen Hinweistext auf noch unvollständige Records). Eine vollständige englische Oberfläche ist für eine spätere Ausbaustufe vorgesehen.
Interoperabilitäts-Mapping-Ebene¶
Geplant ist eine Ebene, die verAIficATor-eigene Kategorien (Beitrags-/ Prüfstufen, Tätigkeiten, Zwecke) auf externe, bereits etablierte Standards und Kennungssysteme abbildet — als Mapping-Tabellen, die eine zusätzliche, alternative Sicht auf denselben Record liefern, ohne das verAIficATor-Schema selbst zu verändern:
- Vancouver-Kriterien (Autorenschaft-Richtlinien des ICMJE)
- GAIDeT (KI-Offenlegungsrahmen im deutschsprachigen Hochschulraum)
- CRediT (Contributor Roles Taxonomy)
- AI Usage Cards
- Crossref (Kennungen für Publikationen)
- ORCID (Kennungen für Autor:innen)
Diese Mapping-Tabellen sind rein technische Übersetzungshilfen, die verAIficATor selbst pflegt. Ihre Aufnahme in diese Roadmap ist keine Aussage über eine Kooperation, Zertifizierung oder Partnerschaft mit den Trägerorganisationen der genannten Standards — eine solche Aussage würde diese Dokumentation an keiner Stelle treffen, weder hier noch andernorts.
Unabhängige Prüfstelle¶
Heute kann eine benannte, zuständige Stelle — in der Regel die betreuende Institution — die Angaben eines Records bestätigen (siehe Verifiziert-Kennzeichen). Eine darüber hinausgehende, vom Betrieb und von den beteiligten Institutionen unabhängige Prüfstelle mit eigenem Verfahren existiert nicht. Das Datenmodell hält dafür weiterhin reservierte, nirgends angezeigte Zustände bereit (siehe Governance). Wie eine solche Stelle einen Record einsehen und ihre Einschätzung hinterlegen könnte, ohne die Selbstauskunft-Natur des ursprünglichen Records zu verwischen, wird Teil dieser Roadmap, sobald eine solche Stelle tatsächlich existiert.
Institutionelle Programmierschnittstelle¶
Die heutige institutionelle API (siehe API) ist an eine angemeldete Browsersitzung einer Koordinationsperson gebunden. Für Institutionen, die ihre eigenen Systeme (Prüfungsverwaltung, Campus-Management) direkt anbinden möchten, ist ein maschinenzugänglicher Zugang — etwa über eigene Zugangsschlüssel statt einer Sitzung — als Ausbaustufe vorgesehen, mit denselben Mandanten- und Datenschutzgarantien wie der heutige, sitzungsgebundene Zugang.