Konform ab dem Tag der Installation.
Setu ist ein CMS-Framework für indische Fachbehörden und Kommunalverwaltungen, das die Vorgaben des indischen Staates erfüllt. Es ist ab der Installation zu 100 % konform: Alles, wofür ein Framework selbst sorgen kann, ist bereits erfüllt — und alles, was davon abhängt, wie ein Portal betrieben wird, automatisiert und erzwingt die KI, damit es erfüllt bleibt.
// der_ueberblick
Die meisten Behördenportale werden einmal regelkonform gebaut und driften danach ab. Eine Seite erscheint ohne Übersetzung in die eigene Amtssprache, ein Bild ohne Alternativtext, an einem hektischen Tag wird eine Freigabe übersprungen — und wenn der STQC-Prüfer eintrifft, stimmt die Website längst nicht mehr mit dem Zertifikat überein. Setu ist so gebaut, dass dieses Abdriften nicht mehr unbemerkt geschehen kann.
Alles, was ein Framework garantieren kann, garantiert das Framework: GIGW-3.0-Prüfpunkte, ein scharf geschaltetes WCAG-2.2-AA-Gate, ein hash-verketteter Audit-Trail, DPDP-Einwilligungsnachweise mit laufenden SLA-Fristen, die Struktur nach RTI §4(1)(b), Mehrsprachigkeit für die 22 Sprachen des Achten Anhangs samt Englisch, ausschließlich Unicode in jeder indischen Schrift, versionierte OpenAPI, ODF- und PDF/A-Handhabung sowie C2PA-Provenienz auf allem, was die KI berührt hat. setu init erzeugt eine Website, die bereits regelkonform ist. Sie konfigurieren nicht die Regelkonformität — Sie konfigurieren die Abweichung, und jede Abweichung wird protokolliert.
Alles, was davon abhängt, wie das Portal genutzt wird — steht dort tatsächlich die erklärte Amtssprache oder nur Englisch, das in ein übersetztes Feld getippt wurde, sagt der Alternativtext etwas aus, hat wirklich ein Mensch die Barrierefreiheit dieser Seite geprüft, ist diese Bekanntmachung in einfacher Verwaltungssprache verfasst statt in übersetztem Amtsjargon —, übernimmt die KI. Sie schreibt, übersetzt, prüft und blockiert; die zweite Hälfte der Konformität wird damit fortlaufend durchgesetzt statt einmal im Jahr geprüft.
Es ist ein Framework, keine Plattform. Erweitert wird es in TypeScript über eine einzige Modulschnittstelle: neu bauen, Image ausliefern, fertig. Genau deshalb trägt es von der Bekanntmachungstafel eines Distrikts bis zum vollständigen Antragsportal oder zur Bürger-App — ohne Plugin-Sandbox, ohne Registry und ohne dauerhaft zu verteidigende Angriffsfläche.
// das_problem
Sprache ist in der indischen Verwaltung keine Geschmacksfrage. Das Amtssprachengesetz von 1963 bindet die Union an Hindi und Englisch, und jeder Bundesstaat hat sein eigenes Amtssprachengesetz, das seine Behörden, halbstaatlichen Stellen und Kommunen bindet — für Bescheide, Anordnungen, Schriftverkehr und ebenso für Websites. In den meisten Projekten wird die Sprache am Ende als Übersetzungsaufgabe nachgereicht. Die technische Bewertungskommission des Auftraggebers prüft sie dagegen als Erstes.
Der Rest kommt als Stapel einzelner Instrumente. GIGW 3.0 bewertet eine Website an 88 verbindlichen Prüfpunkten. CERT-In räumt sechs Stunden zwischen dem Bemerken eines Vorfalls und der Meldung ein und verlangt, dass Protokolle 180 Tage lang auf Infrastruktur in Indien vorgehalten werden. DPDP fordert Einwilligungsnachweise und einen Meldebericht binnen 72 Stunden. RTI §4(1)(b) fordert siebzehn Offenlegungskategorien. Ein Standard-CMS deckt nichts davon ab.
Und dann die Hälfte, die kein Datenmodell fassen kann. Ob der Text auf der Seite wirklich in der Sprache verfasst ist, die das Feld ausweist. Ob der Alternativtext das Foto beschreibt oder nur dessen Dateinamen wiederholt. Ob zwei Beamte eine Freigabe nach dem Vier-Augen-Prinzip gezeichnet haben oder einer zweimal. Ein Portal kann jedes Feld korrekt führen und der Prüfstelle trotzdem einen leeren Nachweis übergeben.
88
verbindliche GIGW-3.0-Prüfpunkte, an denen eine Behördenwebsite gemessen wird
6 Std.
vom Bemerken eines Vorfalls bis zur Meldung an CERT-In
180 Tage
Systemprotokolle, vorgehalten auf Infrastruktur innerhalb Indiens
// wie_es_funktioniert
Setu ist ein CMS-Framework für Tier A: Ministerien, Fachbehörden und Kommunen. Vier Entscheidungen bestimmen es — wie es erweitert wird, was eine frische Installation bereits erzwingt, was KI dort prüft, wo ein Datenmodell nicht hinreicht, und wie weit eine einzelne Instanz trägt.
Setu wird zur Bauzeit erweitert, über eine einzige SetuModule-Schnittstelle: ein npm install, eine Konfigurationszeile, ein Rebuild. Das erspart dauerhaft Plugin-Sandbox, Capability-Manifeste, Artefakt-Signierung, Registry und die Kompatibilitätsmatrix, die ein Laufzeit-CMS für immer verteidigen muss.
Eine frisch installierte Website bringt die GIGW-Pflichtseiten mit, die Amtssprache zuerst, die Barrierefreiheitsprüfung scharf geschaltet, das Vier-Augen-Prinzip aktiv, die Audit-Kette laufend und die DPDP-Einwilligung eingerichtet. Welche Amtssprache das ist, legt jedes Deployment selbst fest — jede der 22 in der Verfassung anerkannten indischen Sprachen, Englisch an zweiter Stelle. Sie konfigurieren Setu nicht zur Konformität. Sie konfigurieren ausschließlich Abweichungen — und jede einzelne davon wird protokolliert.
Manche Pflichten hängen nicht davon ab, wie ein Portal gebaut ist, sondern wie es benutzt wird. Setu unterzieht diese Hälfte bei jeder Veröffentlichung einer KI-Prüfung: die Sprache, der Alternativtext, die Verständlichkeit eines Bescheids, die Echtheit einer Freigabe, die Kennzeichnung generierter Inhalte.
Zur Laufzeit genügen ein Node-Prozess und PostgreSQL; Speicher, Cache, Virenprüfung und Suche sind Module mit lokalem oder neutralem Standard. Dieselbe Schnittstelle, die eine Bekanntmachungstafel eines Distrikts ergänzt, trägt ein Beschwerdeportal, ein Antragsverfahren, ein vollständiges Fachportal oder das Backend einer mobilen App.
// was_ausgeliefert_wird
Jede davon ist ein eigenes Paket, versioniert im Gleichschritt mit dem Kernel und in einer privaten Registry veröffentlicht. Ein Deployment listet die benötigten in seiner eigenen setu.config.ts und baut neu.
Inhaltstypen & Revisionen
Jeder Dokumenttyp erhält Revisionen, Sprachen, Workflow und die Publikationsprüfung ohne Zutun.
Workflow-FSM
Vom Entwurf zur Veröffentlichung, je Sprache, mit erzwungenem Vier-Augen-Prinzip.
Der Feldvertrag
Ein Validator, ein Renderer — gemeinsam genutzt von Admin, Blöcken und der Inline-Bearbeitung.
Die Barrierefreiheitsprüfung
Dreizehn Regeln, die über das geparste HTML laufen, Feld für Feld. Elf stoppen die Veröffentlichung.
Medien-Pipeline
Typprüfung, Positivliste, Quarantäne, Virenscan, Derivate und Alternativtext-Gate je Sprache.
i18n & das Amtssprachen-Glossar
ICU-Katalog für jede der 22 Amtssprachen, XLIFF- und CSV-Austausch, dazu ein Linter gegen fest verdrahtete Texte.
Identität
TOTP, WebAuthn-Passkeys, CASL-Berechtigungen, Sperren und acht Systemrollen ab Installation.
Die setu-CLI
Ein Binary: init, migrate, doctor, audit verify, update, backup und restore.
// die_zwei_ebenen
Die Konformitätsaussage hat zwei Hälften, und sie gelten nur gemeinsam. Links steht, was ein Framework bei der Installation entscheiden kann und deshalb entscheidet. Rechts steht, was davon abhängt, wie das Portal benutzt wird — von KI geprüft, bevor irgendetwas live geht.
Bei der Installation scharf geschaltet, auf jeder Instanz. Kein Schalter, den jemand vergessen kann.
Die Hälfte, die kein Datenmodell fasst. Geprüft am Entwurf, bevor er live geht.
Was hier nicht behauptet wird. VAPT durch einen bei CERT-In gelisteten Prüfer, die STQC-Zertifizierung, MeitY-gelistetes Hosting in Indien und der manuelle Durchgang mit NVDA und JAWS an Inhalten in indischen Sprachen sind prozedural und je Deployment zu erbringen — keine Software erzeugt sie. Jeder Prüfpunkt meldet bestanden, nicht bestanden oder manuelle Prüfung erforderlich; das dritte Ergebnis zählt nie als Bestehen.
// setu_in_zahlen
13
Barrierefreiheitsregeln, die vor der Veröffentlichung über jedes Feld laufen — elf davon blockieren
33
Prüfpunkte: 19 automatisiert, 14 dauerhaft als manuelle Prüfung ausgewiesen
1 Node
Prozess plus PostgreSQL. Speicher, Scan und Suche sind optionale Module
22
indische Amtssprachen plus Englisch. Den Standard wählt das Deployment
// die_highlights
setu init erzeugt eine Website mit GIGW-Seitenelementen, der eigenen Amtssprache an erster Stelle — welche der 22 Sprachen des Achten Anhangs es auch ist —, scharf geschaltetem Barrierefreiheits-Gate, aktivem Vier-Augen-Prinzip, laufender Audit-Kette und konfigurierter Aufbewahrung. Nichts muss erst eingeschaltet werden.
Was ein Framework nicht prüfen kann — steht dort wirklich die erklärte Amtssprache, sagt dieser Alternativtext etwas aus, ist diese Bekanntmachung lesbar —, prüft die KI bei jeder Veröffentlichung. Ein Fehlschlag blockiert die Veröffentlichung, statt eine Warnung abzulegen.
Dreizehn Regeln aus WCAG 2.2 AA und GIGW laufen über das geparste HTML jeder Seite. Elf davon stoppen die Veröffentlichung sofort. Eine nicht barrierefreie Seite erreicht Bürgerinnen und Bürger gar nicht erst.
Jede Aktion ist ein hash-verketteter Eintrag, der nur angehängt werden kann. setu audit verify belegt, dass die Kette unversehrt ist, und ein Klick stellt das Nachweispaket zusammen, das eine STQC-Einreichung verlangt.
Eine Modulschnittstelle ergänzt Inhaltstypen, Felder, Blöcke, Admin-Masken, Routen, Jobs, Provider und Migrationen — dasselbe Framework trägt eine Bekanntmachungstafel, ein Beschwerdeportal, ein Antragssystem für Förderprogramme oder das Backend einer mobilen App.
Eine Distriktinstanz läuft auf einem einzigen Node-Prozess und PostgreSQL. Objektspeicher, Virenprüfung, Cache und Suche sind Module mit lokalen Voreinstellungen — Sie greifen erst darauf zurück, wenn die Platte nicht mehr reicht.
// stack
// faq
// naechster_schritt
Sagen Sie uns, was Sie betreiben möchten. Wir zeigen Ihnen das Produkt im Einsatz, klären den Umfang der Installation und nennen Ihnen einen belastbaren Zeitplan.
