Redaktionelle Richtlinie

Anfas.Pro veröffentlicht geprüfte Foto-Anforderungen für staatlich ausgegebene Dokumente. Unsere Inhalte werden von Menschen genutzt, deren Reisepläne, Aufenthaltsstatus und Einkommen davon abhängen, dass diese Details stimmen. So gehen wir mit dieser Verantwortung um.

Quelle zuerst

Jede Dokument-Spezifikation auf dieser Website ist auf eine primäre Quelle zurückführbar: die Website der ausstellenden Behörde, ein offizielles PDF, eine Botschaftsmitteilung oder ICAO 9303 als Referenz, wenn keine nationalen Regeln veröffentlicht sind. Die Quell-URL und das Prüfdatum sind auf jeder Detailseite sichtbar.

Wir paraphrasieren nicht aus Wettbewerber-Seiten. Wenn wir eine Zahl nennen, geben wir entweder die exakte Formulierung der Behörde wieder oder rechnen Einheiten explizit um (mm ↔ Pixel bei der angegebenen DPI).

Verifizierungsstufen

Official — exact: Die Behörde veröffentlicht eine numerische Spezifikation, die wir wörtlich übernehmen.
Official — general: Die Behörde veröffentlicht beschreibende Leitlinien, die wir in messbare Parameter übersetzen.
ICAO baseline (Draft): Es ist keine nationale Spezifikation veröffentlicht; wir greifen auf die ICAO-9303-Vorgaben zurück und kennzeichnen das Profil als Draft.

Nur Profile der ersten beiden Stufen werden für die Suche indexiert. Profile auf ICAO-Basis bleiben zugänglich, sind aber von Sitemaps ausgeschlossen.

Redaktionelle Prüfstufen (ehrliches Signal)

Jede Detailseite trägt einen Status zur redaktionellen Prüfung, der die tatsächlich geleistete Arbeit widerspiegelt — kein marketingfreundlicher Pauschalstempel „alles geprüft“.

compile-source-check: Die Foto-Spezifikation wurde bei der initialen Datenerfassung von der Behördenseite extrahiert, ohne weitere inhaltliche Überprüfung.
single-reviewer-cited: Die Foto-Spezifikation wurde von einem internen Prüfer anhand aktueller behördlicher Dokumentation zusammengestellt und mit Quellen belegt, mit Hinweis auf länderspezifische Besonderheiten. Eine externe Prüfung durch eine unabhängige Fachperson steht aus. Die Prüf-Leiste auf jeder Detailseite zeigt diese Stufe ehrlich an: „Zusammengestellt und belegt durch [Prüfer] — externe Prüfung ausstehend“.
independently-reviewed: Reserviert für Profile, die von einer SEPARATEN benannten Fachperson erneut geprüft wurden (nicht vom ursprünglichen Prüfer). Zum Zeitpunkt der Veröffentlichung trägt kein Profil diese Stufe — der externe Editor-Workflow wird aufgebaut.

Nach Google-YMYL-Quality-Rater-Standards gilt es nicht als „unabhängige“ Prüfung, wenn ein einzelner Prüfer 218 Dokumente in kurzer Zeit abzeichnet. Das Drei-Stufen-Modell macht diesen Unterschied sichtbar, statt ihn hinter einem einheitlichen Datumsstempel zu verbergen.

Herkunft der Ablehnungscodes

Wenn Detailseiten Ablehnungsgründe auflisten (z. B. UK P01-P15), trägt jeder Code eine Herkunftsangabe:

authority-published: Die Behörde veröffentlicht einen Katalog mit Ablehnungscodes (UK HMPO, US State Department Review Criteria, deutsche BSI TR-03121). Diese Codes werden wörtlich übernommen.
derived-from-rule: Die Behörde veröffentlicht eine Regel (z. B. „keine Brillen“) und wir synthetisieren einen passenden Ablehnungscode in konsistentem ID-Format.
synthesized: Eine plausible Code-Mnemonik für einen häufigen Fehlertyp, wenn die Behörde keinen Code-Katalog veröffentlicht. Nützlich für interne Querverweise innerhalb von Anfas.Pro; klar gekennzeichnet, damit er nicht mit einem Behördencode verwechselt wird.

Automatisierte Qualitäts-Gates

Vor jedem Build laufen sechs Prüfungen, zwei weitere stehen auf Abruf bereit:

npm run check — Schemas, Links, Snapshots, Redirects, Sitemaps, Jargon, Meta-Budgets.
check:a11y — WCAG 2.1 AA über axe-core (10 repräsentative Seiten).
check:cwv — Lighthouse Core Web Vitals an einer Stichprobe von 9 Seiten.
check:translations — Build schlägt fehl, wenn die Label-/Spec-Abdeckung einer angemeldeten Lokale unter 100 % fällt.
check:localization — strenge Abdeckung pro Lokale + Lint (numerische Specs erhalten, Code-IDs erhalten, kein Kyrillisch in nicht-kyrillischen Lokalen).
check:sources — HTTP-Erreichbarkeit jeder zitierten Behörden-URL.
check:freshness — markiert Profile, deren Reviewer-Log nur Sekundärquellen (nicht Behörden) nennt oder bei denen die letzte Prüfung über 1 Jahr alt ist.
check:consistency — markiert Abweichungen zwischen den narrativen Maßangaben (z. B. „40×60 mm“) und der zugrunde liegenden printSpec (die den Foto-Generator steuert).

Lokale-Gating beim Build: Jede Lokale unterhalb von 80 % Übersetzungsabdeckung wird automatisch aus publishedLangs ausgeschlossen — es wird kein HTML generiert, kein Sitemap-Eintrag erzeugt und keine hreflang-Verlinkung gesetzt. Das verhindert, dass gemischtsprachige Seiten bei Google landen.

Aktualität und Korrekturen

Wir prüfen Profile erneut, wenn ein Land eine Regelung aktualisiert, wenn ein Leser eine Änderung meldet oder im Rahmen unserer vierteljährlichen Prüfung — je nachdem, was zuerst eintritt. Das jüngste Prüfdatum ist auf jeder Seite und in unseren Sitemaps sichtbar. Wenn Sie einen Fehler entdecken, schreiben Sie an hello@anfas.pro mit der Seiten-URL und der gefundenen Quelle; wir veröffentlichen Korrekturen innerhalb von 7 Tagen und führen ein öffentliches Änderungsprotokoll.

Was wir nicht tun

Keine KI-generierten Inhalte ohne Fach-Review. Jede Seite wird vor der Veröffentlichung von Anfang bis Ende gelesen.
Keine Garantien für die Annahme. Die endgültige Entscheidung trifft immer die ausstellende Behörde.
Keine Retusche, die biometrische Merkmale verändert. Unser Werkzeug normalisiert Bildausschnitt, Hintergrund und Belichtung — es verändert die Gesichtsgeometrie nicht.
Keine Werbung und keine bezahlten Platzierungen auf Spezifikations-Seiten von Dokumenten.

Weniger verbreitete, aber geprüfte Dokumentformate

Für diese Länder haben wir weniger als drei geprüfte Spezifikationen auf Anfas.Pro. Jeder Link unten führt zu einer Seite mit der genauen Größe, dem Hintergrund, dem Kopfverhältnis und der offiziellen Quelle, auf die die Spezifikation zurückgeht.