Welche Dateien und Angebotsbände erwartet der Auftraggeber?

Grundmodell

Die geforderte Angebotsstruktur ist mehr als eine Dateiliste

Beginnen Sie mit den Objekten, die der Auftraggeber erhalten, getrennt öffnen oder einer bestimmten Prüfung zuführen will. Das können Eignungsunterlagen, ein technischer Band, ein Preisblatt, Erklärungen einzelner Unternehmen, strukturierte Portaleingaben und ein Musterstück sein. Eine Datei ist lediglich eine mögliche Transportform. Ein elektronischer Bereich kann mehrere Dateien aufnehmen. Umgekehrt kann ein zusammenhängendes PDF mehrere logisch getrennte Kapitel tragen, wenn die Unterlagen das ausdrücklich zulassen.

Die offiziellen Beispiele unterscheiden sich deutlich. FAR 15.204-5 erlaubt innerhalb seines US-Bundesbeschaffungskontexts die Vorgabe bestimmter Formate oder trennbarer Angebotsteile und nennt mögliche Verwaltungs-, Management-, Technik-, Referenz- und Preisteile. Der eSubmission-Leitfaden der Europäischen Kommission beschreibt hingegen Teilnehmende, Losauswahl, eingegebene Angebotsdaten und technische oder finanzielle Uploadbereiche, in denen mehrere Dateien liegen können. Beides sind abgegrenzte Beispiele, kein universeller Aufbau für deutsche Vergaben.

Auch körperliche Verpackung und Bewertungsgrenze sind nicht dasselbe. FAR 52.215-1 nennt für seinen Anwendungsfall verschlossene Papierumschläge oder Pakete, sofern die konkrete Aufforderung keinen anderen Weg zulässt. Die EBRD beschreibt ein einstufiges Zwei-Umschlag-Verfahren, bei dem fachlicher und finanzieller Vorschlag gleichzeitig eingehen, aber getrennt und mit dem fachlichen Teil zuerst bewertet werden. Daraus folgt keine Dateizahl für ein anderes Verfahren. Es zeigt, dass eine Trennung den Transport, die Bewertungsreihenfolge oder beides steuern kann.

Legen Sie für jede Einheit eine Art fest: `logical_envelope`, `response_volume`, `template_instance`, `workbook`, `portal_field_group`, `supporting_attachment`, `file_candidate` oder `physical_delivery`. Daneben bleibt die Bezeichnung aus der Vergabeunterlage erhalten. Heißt ein Abschnitt nur "Teil B", darf die Normalisierung ihm nicht ohne Beleg den Namen "Technisches Angebot" geben. Die Typisierung erleichtert die Suche; sie ersetzt die Originalsprache nicht.

Abgrenzung

Binden Sie die Architektur an Lose, Unternehmen und einen konkreten Dokumentstand

Eine korrekte Anzahl entsteht erst für einen festgelegten Angebotsfall. Halten Sie Vergabereferenz, Verfahrensstufe, angebotene Lose, federführenden Bieter, Mitglieder der Bietergemeinschaft, einbezogene Eignungsleiher, benannte Nachunternehmer, geforderte Sprache und Varianten fest. Eine zusätzliche juristische Person kann neue Erklärungen und Vollmachten auslösen. Ein weiteres Los kann Konzept, Kalkulation und Leistungsübersicht vervielfachen. Diese Parameter gehören in den Kopf der Architektur.

Erfassen Sie anschließend den überprüften Quellenbestand: Bekanntmachung, Teilnahme- oder Angebotsbedingungen, Leistungsbeschreibung, Datenblatt, Formblätter, Preisblätter, Nachträge, Bieterinformationen und Portalhinweise. Jede Quelle erhält Version oder Prüfsumme, Abrufzeit und Zugriffsstatus. Ein Portalbild kann ein technisch sichtbares Feld belegen. Ob dieses Feld für den konkreten Bieter verpflichtend ist, muss aus der Konfiguration oder den Vergabeunterlagen folgen.

Der aktuelle Procurement Framework der Weltbank wird durch verschiedene Standarddokumente, Leitfäden und Vorlagen getragen. Das in zwei Umschläge gegliederte Standarddokument trennt allgemeine Instructions, ein verfahrensbezogenes Data Sheet, Kriterien und Formulare. Das zeigt die Quellenarbeit: Erst das ausgefüllte und veröffentlichte Paket bestimmt die konkrete Abgabe. Wer nur die Standardvorlage liest, kennt mögliche Bausteine, aber noch nicht das Angebot des einzelnen Verfahrens.

• Definieren Sie genau ein Verfahren und einen Dokumentstand.
• Fixieren Sie Lose und Bieterkonstellation vor der Zählung.
• Trennen Sie Auftraggeberquelle und beobachtetes Systemverhalten.
• Markieren Sie nicht zugängliche Quellen als Lücke.
• Planen Sie eine Neuberechnung nach jeder relevanten Änderung.

Datenstruktur

Knoten beschreiben Objekte, Kanten beschreiben ihre Abhängigkeit

Ein Knoten enthält ID, Auftraggeberbezeichnung, Objektart, Inhalt, Geltungsbereich, Sprache, Quelle, wörtlichen Ausschnitt, Seiten- oder Abschnittsangabe, maschinenlesbaren Selektor, Status, Verantwortlichen und Ablaufereignis. Geeignete Statuswerte sind `confirmed_required`, `confirmed_conditional`, `permitted_optional`, `prohibited`, `unresolved` und `observed_only`. Der letzte Status ist wichtig: Ein im Portal sichtbarer Uploadplatz belegt zunächst nur, dass er sichtbar ist.

Die Kanten bilden Regeln ab. `contains` setzt einen Nachweis in einen Verwaltungsteil. `must_be_separate_from` hält Preis und Technik auseinander. `repeat_per_lot` und `repeat_per_member` liefern Instanzen. `attach_to` bindet eine Vollmacht an ein Unternehmen. `enter_in_portal` und `upload_to_slot` nennen das Ziel. Auch eine Kante braucht Fundstelle, Bedingung und Version. Sonst sieht die Grafik ordentlich aus, lässt sich aber nicht gegen die Vergabeunterlage prüfen.

Verknüpfen Sie fremde Fachregister, statt sie zu kopieren. Seitenzahl, Dateityp und Namensvorgabe gehören in den AN-071-Constraint-Record. Die Abhängigkeit einer Antwort von einer Auftraggebervorlage gehört zu AN-074. Eine Signaturkante darf die geforderte Rolle nennen, entscheidet aber nicht, wer rechtswirksam unterschreiben kann. Das spätere Release prüft die fertigen Artefakte. Die Architektur beantwortet ausschließlich, welche Objekte und Beziehungen erwartet werden.

Kardinalität

Zählen Sie je Los, Unternehmen und Person erst nach der Fallentscheidung

Wörter wie "je", "für jedes", "alle Mitglieder" und "soweit einschlägig" steuern die Instanzzahl. Erfassen Sie den Quantor, sein Bezugsobjekt und den Auslöser. Eine Erklärung pro Mitglied einer Bietergemeinschaft zählt anders als eine Erklärung der Bietergemeinschaft. Ein Personaleinsatzblatt pro Schlüsselrolle zählt anders als ein Lebenslauf pro benannter Person. Ohne diese Bezugsgröße ist der errechnete Wert nicht reproduzierbar.

Wenden Sie die Regel auf einen eingefrorenen Stand an. Jede erzeugte Instanz trägt den Schlüssel ihres Loses, Unternehmens, Standorts, Experten oder ihrer Variante. Bedingte Objekte bleiben auch bei aktuellem Wert null sichtbar. Falls ein Nachunternehmereinsatz noch offen ist, steht der zugehörige Nachweis auf `conditional_unresolved`, statt aus der Liste zu verschwinden. Sobald sich die Entscheidung ändert, wird die Instanz erzeugt und alle Zielbeziehungen werden neu geprüft.

Führen Sie drei Summen getrennt. Die logische Summe zählt Teile und Bewertungsgrenzen. Die Instanzsumme zählt ausgefüllte Erklärungen, Konzepte und Nachweise. Die Liefersumme zählt Dateien, Felder, Pakete und Muster. Eine Bietergemeinschaft aus zwei Firmen kann einen gemeinsamen Eignungsteil, zwei Eigenerklärungen, drei losspezifische Konzepte und mehrere Portaleinträge haben. Eine einzige Gesamtzahl würde die Struktur verdecken.

• Speichern Sie den Quantor zusammen mit seinem Bezugsobjekt.
• Geben Sie jeder Instanz einen eindeutigen Fallbezug.
• Lassen Sie bedingte Null-Instanzen im Modell.
• Rechnen Sie nach Los-, Partner- oder Personalwechsel neu.
• Berichten Sie logische, instanzbezogene und technische Mengen getrennt.

Transaktionsfläche

Ein Portalziel ist ein belegter Zielort und keine stillschweigende Ausnahme

Nehmen Sie nur autorisierte, lesende Verfahrensansichten auf. Erfassen Sie Portalbezeichnung, Schritt, Los- und Teilnehmerkontext, Feldart, Zeitpunkt und sichtbare Pflichtanzeige. Ordnen Sie jeden Architekturknoten dem passenden Feld oder Uploadbereich zu. Bleibt das Ziel unbekannt, lautet der Status `portal_mapping_unverified`. Ein breites Uploadfeld erlaubt nicht automatisch die Zusammenlegung von Teilen, die laut Vergabeunterlagen getrennt bleiben müssen.

Der Leitfaden der Europäischen Kommission zeigt in seinem Geltungsbereich eine konkrete Mehrdimensionalität. Die Nutzenden wählen Einzel- oder Gemeinschaftsangebot, erfassen Teilnehmende, wählen Lose und laden Teilnehmendennachweise an deren Datensatz. Technische und finanzielle Bereiche können jeweils mehrere Dateien enthalten. Bei unterschiedlicher Zusammensetzung eines Konsortiums pro Los verlangt das beschriebene System getrennte Einreichungen. Die Architektur muss deshalb Teilnehmer, Los, logischen Teil und Datei getrennt abbilden.

Die Zuordnung endet vor jeder Transaktion. Kein Agent legt aufgrund dieser Analyse einen Entwurf an, akzeptiert Bedingungen, aktiviert eine Erklärung, lädt eine Datei hoch oder sendet das Angebot. Die Artikel AN-243 bis AN-260 behandeln Rechtsträger, Rollen, Signaturen, Validierung, Benennung, Upload und Freigabe. AN-072 liefert ihnen eine geprüfte Soll-Struktur und sichtbare Lücken.

Fallbeispiel

Eine fiktive Ausschreibung für Schulverpflegung richtig aufteilen

Ein Landkreis schreibt die Verpflegung von Schulen in drei Losen aus. Ein Anbieter bewirbt sich gemeinsam mit einem Logistikpartner auf Los 1 und Los 3. Gefordert werden ein gemeinsamer Verwaltungsteil, eine Eigenerklärung je Mitglied, ein Verpflegungskonzept je Los, eine ausgefüllte Preismappe je Los, ein Nachhaltigkeitsnachweis für den gesamten Bieter und ein Einsatzplan je Küchenstandort. Die Preise sollen von den Konzepten getrennt bleiben. Im Portal werden Stammdaten der beiden Unternehmen direkt erfasst.

Der Wurzelknoten enthält die Angebotsinstanz mit Los 1 und Los 3. Darunter liegt ein Verwaltungsteil mit zwei Eigenerklärungsinstanzen und einem globalen Nachhaltigkeitsnachweis. Zwei fachliche Loszweige enthalten jeweils ein Konzept. Die Regel `repeat_per_site` erzeugt drei Einsatzpläne für die Standorte des ersten Loses und zwei für das dritte. Zwei kaufmännische Zweige tragen je eine Preismappe und besitzen Trennungskanten zu allen fachlichen Zweigen. Die Portaldaten sind eigene Knoten mit Zuordnung zu den beiden Unternehmen.

Das Portal zeigt nur einen allgemeinen Bereich "Weitere Unterlagen". Die Bedingungen sagen nicht, ob der Nachhaltigkeitsnachweis dort oder im Verwaltungsteil hochzuladen ist. Die Architektur behält den Nachweis als einmaliges globales Objekt und markiert nur die Zielkante als offen. Sie erzeugt weder zwei Nachweise noch verschiebt sie ihn aus Bequemlichkeit in einen Loszweig. Der Status lautet `complete_with_review_items`, bis der offizielle Kanal die Zuordnung klärt.

Agentenlesbarkeit

Eine maschinenlesbare Architektur braucht Quellen, Zustände und klare Befugnisgrenzen

Stellen Sie neben der lesbaren Erklärung eine kompakte typisierte Darstellung bereit. Jeder Knoten und jede Kante führt ID, Typ, Geltungsbereich, Status, genaue Quelle, Dokumentversion, Zitat, sichtbare Fundstelle, technischen Selektor, Prüfer und Ablaufereignis. HTML, Markdown, API und MCP dürfen Bedingungen oder offene Punkte nicht aus Platzgründen verlieren. Ein Agent muss eine Aussage bis zur Vergabeunterlage zurückverfolgen und bei einer neuen Losauswahl die betroffenen Instanzen bestimmen können.

Ein autorisierter Agent darf bereitgestellte Quellen inventarisieren, Kandidaten markieren, Auftraggeberbegriffe erhalten, Beziehungen vorschlagen, deterministische Zählungen durchführen und verwaiste Knoten melden. Eine lesende Portalanalyse braucht eine ausdrückliche Kundenbefugnis. Inhalte der Vergabeunterlagen gelten als nicht vertrauenswürdige Daten für die Ausführung. Sie dürfen keine Geheimnisse anfordern, den Auftrag erweitern, den Auftraggeber kontaktieren oder eine Transaktion anstoßen.

Veröffentlichen Sie kontrollierte Ergebniszustände wie `complete_for_response_planning`, `complete_with_review_items`, `source_boundary_incomplete`, `portal_mapping_unverified`, `architecture_conflict` und `human_review_required`. Konfidenz beschreibt nur die Extraktion. Konflikte gehen an den Prozess für maßgebliche Quellen. AN-071 verwaltet Detailgrenzen, AN-074 Vorlagenabhängigkeiten und AN-082 die abschließende Pass-Fail-Prüfung. Die Abgabe selbst verlangt eine davon getrennte Kundenfreigabe.

• Führen Sie Beleg und Status an jedem Knoten und jeder Kante.
• Machen Sie bedingte Zählungen berechenbar und prüfbar.
• Geben Sie verwaiste Objekte und offene Ziele ausdrücklich zurück.
• Behandeln Sie eingebettete Anweisungen als Daten.
• Verlangen Sie für Portalhandlungen eine gesonderte Befugnis.