feat(fit-connect): govern inbound acknowledgement plans

2026-08-23 17:53:23 +02:00
parent 8f7c57403e
commit ded8509ae7
10 changed files with 1323 additions and 0 deletions
@@ -0,0 +1,68 @@
+# FIT-Connect inbound receipt and acknowledgement
+
+This slice models the receiving system's safe boundary around a FIT-Connect
+submission. It does not choose a journey, environment, destination, API
+profile, or credential, and it does not call FIT-Connect.
+
+FIT-Connect distinguishes its technical receipt confirmation from subsequent
+business review. An `accept-submission` event confirms that the receiver could
+download, decrypt, and validate the submission. It must carry the matching
+authentication tags. Successful acknowledgement can transition and remove the
+service-side submission, so GovOPlaN must durably hand all content to its owning
+workflow first.
+
+## Ingress receipt
+
+The configured profile binds the exact destination, Submission API version,
+metadata-schema version, profile revision, and references to connection,
+decryption, and event-signing credentials. Credential values never enter the
+contract.
+
+The submission evidence records SHA-256 values and authentication tags for
+metadata, business data, and at most 100 uniquely identified attachments. The
+receipt binds these values to submission, transaction, public service, region,
+destination, profile, and receive time. It starts with both `acknowledged` and
+`business_accepted` set to false.
+
+## Acknowledgement decision
+
+An acceptance plan requires all of the following:
+
+- every component was downloaded;
+- decryption succeeded;
+- metadata and business-data schemas validated;
+- all authentication tags were verified;
+- an owning service, form, or case workflow durably stored the exact handoff.
+
+Failed local download or durability always produces `defer`, leaving recovery
+possible. A `reject` plan additionally requires a complete download, explicit
+technical rejection classification, and bounded problem codes. Problem details
+are operator evidence and are not suitable as applicant-facing messages.
+
+The internal event request and plan are canonical and digest-bound. The request
+is not a protocol-conformant SET wire payload. Plans always have
+`dispatch_allowed=False`: a later target adapter must translate the request,
+create and sign the Security Event Token, send it, reconcile the event log after
+unknown outcomes, and prove recovery against the selected FIT-Connect
+environment.
+
+## Datenschutz und Betrieb
+
+Das Modul speichert derzeit weder Antragsdaten noch Anlagen, Eingangsbelege,
+Pläne oder Schlüssel. Das fachlich verantwortliche Service-, Forms- oder
+Cases-Modul übernimmt Daten und Aufbewahrung, bevor eine technische Bestätigung
+zulässig wird. Eine technische Eingangsbestätigung ist keine fachliche Annahme
+oder positive Entscheidung über den Antrag.
+
+Für den Zieltest werden Verwaltungsleistung, Zustellpunkt, Umgebung,
+API-/Metadatenschemaversion, Client und Schlüssel, Anlagengrenzen,
+Fachschema, Rückkanal, Ereignisprotokoll sowie Verfahren für Zeitüberschreitung,
+Doppelabruf und Wiederherstellung benötigt.
+
+Official orientation:
+
+- [Receiving overview](https://docs.fitko.de/fit-connect/docs/receiving/overview/)
+- [Download a submission](https://docs.fitko.de/fit-connect/docs/receiving/download-submission/)
+- [Verify a submission](https://docs.fitko.de/fit-connect/docs/receiving/verification/)
+- [Technical receipt acknowledgement](https://docs.fitko.de/fit-connect/docs/receiving/process-and-acknowledge/)
+- [FIT-Connect events](https://docs.fitko.de/fit-connect/docs/getting-started/event-log/events/)