- Geprüft werden Nachträge je Position: "im Vertrag enthalten?" mit Fundstellen - Gliederung Projekt → PFA → Vertrag → LVs, Suchreihenfolge über PFAs - GAEB X86 als Grundlage, PDF zur Anzeige; LV-Suche als Meilenstein M2 - KI-API ITM über API-Werk: Sprachmodell vorhanden, Polling statt Webhook - Bewertungsmatrix und Stellungnahme als Optionen; Höhe Phase 2, Regelwerk Phase 3 - Termine: 16.10. BauIn, M1 30.10., M2 20.11., M3 18.12., M4 29.01. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
225 lines
18 KiB
Markdown
225 lines
18 KiB
Markdown
# KI-BauIN – Projekt- und Zeitplan (Phase 1)
|
||
|
||
Stand: 2. Oktober 2026 (KW 40), nach der ersten Besprechung mit BauIN und der API-Dokumentation
|
||
von ITM. Sobald die Antworten auf den Fragenkatalog vorliegen (Ziel: Termin am 16.10.), wird
|
||
daraus der Detailplan mit Teilplänen je Arbeitspaket.
|
||
|
||
## Beteiligte
|
||
|
||
- **ITM:** Anbieter der KI-API (über API-Werk: Dokumentdienst mit OCR, Embeddings, Reranker,
|
||
Sprachmodell), Projektleitung und abrechnende Firma. Stellt auch die Server (Staging,
|
||
Produktion) und den Gitea, auf den das Repository gespiegelt wird.
|
||
- **BauIn:** Endkunde. Prüft als Bauüberwachung im Auftrag der DB die Nachträge der
|
||
Auftragnehmer dem Grunde nach. Liefert Fachdaten (LVs, Nachträge, Bewertungsmatrizen),
|
||
stellt den fachlichen Ansprechpartner (Nachtragsbearbeitung) und eine Ansprechpartnerin für IT.
|
||
- „Kunde“ meint in diesem Dokument BauIn; wo ITM gemeint ist, steht ITM.
|
||
|
||
## Ergebnis der Besprechung vom 02.10.2026
|
||
|
||
Was sich gegenüber dem Stand vom 01.10. ändert:
|
||
|
||
- **Geprüft werden Nachträge, nicht MKAs.** Aus einer MKA entsteht (oder auch nicht) nach
|
||
einigen Wochen ein Nachtrag; das ist nicht 1:1. Der Nachtrag enthält ein Nachtrags-LV mit
|
||
Positionen (GAEB und PDF), ein Anschreiben, die Kalkulation und Anlagen. Die MKA-Nummer ist nur
|
||
noch ein Bezug am Nachtrag.
|
||
- **Die KI beantwortet je Nachtragsposition eine Frage:** Ist die Leistung schon im Vertrag
|
||
enthalten, also in den LVs einschließlich Vorbemerkungen? Wenn ja, ist der Nachtrag dem Grunde
|
||
nach nicht berechtigt. Schwerpunkt sind geänderte Leistungen (§ 2 Abs. 5 VOB/B, mit Rückgriff
|
||
auf eine Hauptvertragsposition) und zusätzliche Leistungen (§ 2 Abs. 6 VOB/B). Mengenänderungen
|
||
(§ 2 Abs. 3) kommen selten vor und bekommen keine eigene Logik.
|
||
- **Nicht Aufgabe der KI:** die rechtliche Einordnung (richtiger Paragraf), Fristen und
|
||
Vollständigkeit der Anzeige, Leistungen ohne Auftrag (§ 2 Abs. 8), Behinderungen (§ 6 Abs. 6),
|
||
Anordnungen des Auftraggebers. Das prüft BauIn selbst.
|
||
- **Gliederung:** Projekt → PFA (Planfeststellungsabschnitt, im Pilot PFA 1–4) → Vertrag mit
|
||
einem Auftragnehmer (je PFA mehrere, z. B. Gleisbau, Tunnelbau, Oberleitung) → mehrere LVs
|
||
(im PFA 4 z. B. 28). Ein „Los“ im bisherigen Plan entspricht einem Vertrag.
|
||
- **Suchreihenfolge:** zuerst die LVs des betroffenen Vertrags, dann als Hinweis die anderen PFAs
|
||
desselben Projekts (Fall: Leistung im PFA 3 beauftragt, im PFA 4 vergessen und dort per
|
||
Nachtrag zum doppelten Preis angeboten). Nie projektübergreifend. Ob auch die übrigen Verträge
|
||
im selben PFA durchsucht werden, ist offen.
|
||
- **Daten:** Jedes LV liegt als GAEB (X86 und D86) und als PDF vor, erzeugt aus dem
|
||
Kalkulationsprogramm. Grundlage ist die X86-Datei (strukturiert, ohne Texterkennung); das PDF
|
||
dient der Anzeige mit Sprung zur Fundstelle. OCR über die KI-API braucht es nur noch für
|
||
PDFs ohne GAEB-Datei (Anschreiben, Scans).
|
||
- **Sprachmodell ist vorhanden** (`chat`, `chat-noreasoning`, Kontext laut ITM 128K). Damit ist
|
||
die KI-Beurteilung (Stufe 2) fest eingeplant.
|
||
- **Bewertungsmatrix (Excel der DB) und Stellungnahme (Word) sind Optionen**, nicht Kern von
|
||
Phase 1. Vorlagen kommen von BauIn.
|
||
- **Die Prüfung der Höhe nach ist Phase 2**, das Regelwerk mit Chat Phase 3 (siehe unten).
|
||
- **Zusammenarbeit:** Termine freitags über Teams; nächster Termin am **16.10.2026** mit
|
||
Statusbericht und Kostenrahmen für Phase 1.
|
||
|
||
## Rahmen und Annahmen
|
||
|
||
- **Ziel von Phase 1:** Positionsanalyse dem Grunde nach am Pilotprojekt. Vom hochgeladenen
|
||
Nachtrag bis zur Ergebnisliste je Position mit Fundstellen, Begründung und Entscheidung des
|
||
Bearbeiters, mit Rollen und Rechten, Protokoll und Betrieb auf den Servern von ITM.
|
||
- **Grundhaltung:** Die KI schlägt vor und belegt mit Fundstellen, der Mensch entscheidet.
|
||
Rückmeldungen fließen in ein Confidence-System mit Referenzfällen und Regeln.
|
||
- **Aufwand:** Kern rund 24 Personenwochen (PW), mit Risikopuffer 27–28 PW. Optionen
|
||
zusätzlich (siehe Arbeitspakete).
|
||
- **Team (Annahme):** zwei Entwickler mit KI-Unterstützung.
|
||
- **A** (du): Backend, KI-Anbindung, Suche, Prüflogik
|
||
- **B** (noch zu klären): Oberfläche mit TallStackUI, GAEB-Import, Betrieb
|
||
- Mit nur einem Entwickler verdoppelt sich die Dauer ab KW 44 (siehe Variante unten).
|
||
- **Pause:** KW 52–53 (21.12.2026 – 03.01.2027).
|
||
- **Echte Daten:** Entwickelt wird mit öffentlichen GAEB-Beispieldateien und einem
|
||
anonymisierten Beispielablauf von BauIn. Echte Pilotdaten nur auf den Servern von ITM und
|
||
erst nach Klärung des Datenschutzes.
|
||
- **Abhängigkeit:** Viele Pakete brauchen Zulieferungen von ITM und BauIn. Kommen sie später als
|
||
unten geplant, verschiebt sich der Plan entsprechend.
|
||
|
||
## Meilensteine
|
||
|
||
| | Termin | Ergebnis | Termin mit dem Kunden |
|
||
|---|---|---|---|
|
||
| – | Fr 16.10. | Statusbericht mit Screenshots, Plan, Kostenrahmen, offene Fragen | Termin BauIn |
|
||
| **M1** | Fr 30.10. (KW 44) | Grundgerüst: Login/2FA, Benutzer und Rollen, Projekte mit PFA und Verträgen, Upload, Protokoll; Detailplan steht | Demo (30 min) |
|
||
| **M2** | Fr 20.11. (KW 47) | LVs des Pilot-PFA importiert; **LV-Suche** über alle LVs eines Vertrags, PFA oder Projekts mit Sprung ins PDF nutzbar; Staging bei ITM läuft | Prüftermin (60 min) |
|
||
| **M3** | Fr 18.12. (KW 51) | Erster Nachtrag durchgängig: Vorprüfung aller Positionen, Prüfmaske, Feedback, Regeln, Ergebnisliste | Präsentation (60–90 min) |
|
||
| **M4** | Fr 29.01.2027 (KW 4) | Alle Nachträge des Pilot-PFA durchlaufen, Trefferquote und Zeitersparnis gemessen; Produktion abgesichert | Abschluss, Entscheidung über Optionen und Phase 2 |
|
||
| Puffer | KW 5–6/2027 | für Verzögerungen bei Zulieferungen oder Import | – |
|
||
|
||
Die LV-Suche (M2) nützt BauIn schon vor der KI-Beurteilung: Heute werden bis zu 28 LVs einzeln
|
||
nach Stichworten durchsucht.
|
||
|
||
**Laufend:** Termine mit BauIn freitags, etwa alle zwei Wochen, vorher ein kurzer Statusbericht
|
||
mit Screenshots.
|
||
|
||
## Arbeitspakete und Aufwand
|
||
|
||
| AP | Inhalt | PW | Wer | Wann | Hängt ab von |
|
||
|---|---|---|---|---|---|
|
||
| AP0 | Klärung, Kundentermine, Statusberichte, Dokumentation | 1,0 | A+B | laufend | – |
|
||
| AP1 | Fundament: Umgebung ✓, Laravel/TallStackUI ✓, Mehrsprachigkeit ✓, CI, Datenmodell (Mandant, Land, Projekt, PFA, Vertrag, LV, Dokument, Nachtrag, Nachtragsposition), Rollen/Rechte mit Benutzerverwaltung, privater Upload und Download inkl. Massen-Upload, Protokoll, Länderstruktur | 4,0 (1,0 erledigt) | A+B | KW 40–44 | Rollenmodell (Kunde) |
|
||
| AP2 | Meilisearch-Test: Teil 1 mit erzeugten Vektoren, Teil 2 mit echten Vektoren und Referenzfällen | 0,5 | A | KW 41 / KW 46–47 | Teil 2: API-Schlüssel (ITM), Referenzfälle (BauIn) |
|
||
| AP3 | Anbindung KI-API ITM (API-Werk): Dokumentdienst mit Polling, `embed`, `rerank`, `chat` mit Streaming; Ratenbegrenzung (120/min je Schlüssel), begrenzte Wiederholung ohne Doppel-Einreichung, Verbrauchsprotokoll, Überwachung | 1,5 | A | KW 41 (Test), KW 44 | API-Schlüssel (ITM) |
|
||
| AP4 | Indexierung und Suche: LV-Positionen und Vorbemerkungen aus GAEB, Texte aus PDFs ohne GAEB → Embeddings → MySQL + Meilisearch; hybride LV-Suche mit Pflichtfilter für Rechte und Suchreihenfolge (Vertrag → PFA → Projekt); Neuaufbau des Index | 2,0 | A | KW 45–47 | AP3, AP5 |
|
||
| AP5 | GAEB-Import (X86): Parser, LV-Baum, Vorbemerkungen, LV-Ansicht; PDF-Anzeige (pdf.js lokal) mit Sprung zur Position; Nachtrags-Import (Nachtrags-LV als X86, sonst PDF über OCR) | 2,5 | B | KW 41 (Test), KW 44–46 | Beispieldateien |
|
||
| AP6 | Vorprüfung Stufe 1 (ohne Sprachmodell): je Nachtragsposition Fundstellen mit Reranker, Nachtragsübersicht, Prüfmaske, Feedback je Aspekt, Confidence | 2,5 | A+B | KW 48–49 | AP4, AP5 |
|
||
| AP7 | Vorprüfung Stufe 2 (mit Sprachmodell): „im Vertrag enthalten?“, Bezugsposition und Unterschied bei geänderter Leistung, Begründung mit Quellen, Prüfung der Antwort | 2,0 | A | KW 50–51 | AP6 |
|
||
| AP8 | Regeln, Referenzfälle, einstellbare Freigaben, Versionen | 2,0 | B | KW 50–51 | Freigabe-Variante (Kunde) |
|
||
| AP9 | Nachtragsstatus, Ergebnisliste je Nachtrag, einfacher Excel-Export | 0,5 | B | KW 51 | – |
|
||
| AP10 | Dashboard, Benachrichtigungen, Auswertungen, allgemeine Dokumente (Einstellungen) | 0,75 | B | KW 47, KW 2 | – |
|
||
| AP11 | Betrieb: Staging und Produktion (Nginx, PHP-FPM, systemd, Cron, Meilisearch), Deployment, verschlüsselte Backups, Alarmierung, Restore-Test | 1,5 | B | KW 46–47, KW 3 | Server (ITM), Backup-Ziel |
|
||
| AP12 | Pilot: alle Nachträge des Pilot-PFA durchlaufen, messen, nachschärfen (Prompts, Gewichtung, Quantisierung) | 2,0 | A+B | KW 1–3/2027 | Referenzfälle, Fachexperte |
|
||
| AP13 | Design aus Claude Design als TallStackUI-Designsystem übernehmen | 1,0 | B | KW 42–43 | Designentwurf |
|
||
| | **Summe Kern** | **≈ 23,75** | | | |
|
||
| OP1 | Option: Bewertungsmatrix in der Excel-Vorlage der DB füllen | 1,0 | B | KW 2–3 | Vorlage (BauIn) |
|
||
| OP2 | Option: Stellungnahme BÜW als Word-Datei aus Vorlage | 1,0 | B | nach M4 oder Puffer | Vorlage (BauIn) |
|
||
|
||
Gegenüber dem Stand vom 01.10. entfallen der GAEB-90-Import (D86), der Webhook-Eingang, der
|
||
Vorschlag einer Anspruchsgrundlage und die kuratierte Wissensbasis (wird Phase 3). Dazu kommen
|
||
PDF-Anzeige mit Sprung zur Position, Massen-Upload, Suchreihenfolge über PFAs und die Bezugsposition.
|
||
|
||
## Zeitplan nach Kalenderwochen (2 Entwickler)
|
||
|
||
| KW | Datum | A (Backend, KI, Suche) | B (Oberfläche, Import, Betrieb) | Kunde / gemeinsam |
|
||
|---|---|---|---|---|
|
||
| 40 | 28.09.–04.10. | ✓ Umgebung, Grundgerüst, TallStackUI, Mehrsprachigkeit, Doku | – | ✓ Besprechung BauIn (02.10.) |
|
||
| 41 | 05.–11.10. | Meilisearch-Test Teil 1; Datenmodell Kern; API-Schnelltest, sobald Schlüssel da | CI in Gitea Actions; Benutzerverwaltung beginnen; GAEB-X86-Test mit öffentlichen Beispieldateien | Fragenkatalog raus; Übergabe an Claude Design |
|
||
| 42 | 12.–18.10. | Upload, privater Speicher, Download mit Rechteprüfung, Massen-Upload | Rollen und Rechte, Projekt-Mitglieder; Design-Feedback | Aufwand an ITM (bis 14.10.); **Termin BauIn 16.10.** |
|
||
| 43 | 19.–25.10. | Detailplan und Teilpläne nach den Antworten; Protokoll; Länderstruktur | Designsystem übernehmen (AP13) | – |
|
||
| 44 | 26.10.–01.11. | Client KI-API ITM, Jobs, Ratenbegrenzung | GAEB-Parser: LV-Baum, Vorbemerkungen | **M1 Demo 30.10.** |
|
||
| 45 | 02.–08.11. | Indexierung: Positionen und Vorbemerkungen → Embeddings | LV-Ansicht, PDF-Anzeige mit Sprung zur Position | – |
|
||
| 46 | 09.–15.11. | Hybride LV-Suche mit Rechtefilter und Suchreihenfolge; Meilisearch-Test Teil 2 | Nachtrags-Import; Staging einrichten | – |
|
||
| 47 | 16.–22.11. | Neuaufbau des Index; OCR für PDFs ohne GAEB | Suchoberfläche; Staging fertig, Pilot-PFA importiert | **M2 Prüftermin 20.11.** |
|
||
| 48 | 23.–29.11. | Vorprüfung: Fundstellen + Reranker, Confidence | Nachtragsübersicht, Prüfmaske | – |
|
||
| 49 | 30.11.–06.12. | Feedback-Speicherung, Referenzfälle | Prüfmaske fertig, Feedback-Oberfläche | Demo 04.12. |
|
||
| 50 | 07.–13.12. | Sprachmodell: „enthalten?“, Bezugsposition, strukturierte Antwort | Regeln: Dialog, Freigaben, Einstellungen | – |
|
||
| 51 | 14.–20.12. | Begründung mit Quellen, Prüfung der Antwort | Ergebnisliste, Excel-Export | **M3 Präsentation 18.12.** |
|
||
| 52–53 | 21.12.–03.01. | Pause | Pause | – |
|
||
| 1 | 04.–10.01. | Pilot: alle Nachträge des Pilot-PFA durchlaufen, messen | Pilot begleiten, Fehler beheben | Fachexperte bewertet |
|
||
| 2 | 11.–17.01. | Nachschärfen (Prompts, Gewichtung, Quantisierung) | Dashboard, Auswertungen; Option OP1, falls beauftragt | Demo 15.01. |
|
||
| 3 | 18.–24.01. | Feinschliff, Fehler | Produktion: Backups, Alarmierung, Restore-Test | – |
|
||
| 4 | 25.–31.01. | Auswertung, Übergabe | Doku Betrieb | **M4 Abschluss 29.01.** |
|
||
| 5–6 | 01.–14.02. | Puffer | Puffer | – |
|
||
|
||
**Variante mit einem Entwickler:** M1 Ende KW 45, M2 Ende KW 51, M3 Ende KW 8/2027,
|
||
M4 Ende KW 13/2027 (Anfang April).
|
||
|
||
## Zulieferungen von ITM und BauIn (Soll-Termine)
|
||
|
||
| Bis | Von | Was | Gebraucht für |
|
||
|---|---|---|---|
|
||
| ✓ 02.10. | ITM | API-Dokumentation (API-Werk: Dokumentdienst, `chat`, `chat-noreasoning`, `embed`, `rerank`) | AP3 |
|
||
| KW 41 | ITM | API-Schlüssel für die Entwicklung; Antworten auf die ITM-Fragen; Preise der API für den Kostenrahmen | AP3, Kostenrahmen |
|
||
| KW 41 | BauIn | Antworten auf die ★-Fragen | Detailplan |
|
||
| 16.10. | BauIn | Matrix-Vorlage (leer + 2–3 ausgefüllt), Word-Vorlage Stellungnahme, anonymisierter Beispielablauf (LVs als X86 + PDF, Nachträge mit Nachtrags-LV und Anschreiben) | AP5, AP9, OP1, OP2 |
|
||
| KW 43 | BauIn | Entscheidung Rollenmodell, Freigabe-Variante, Anmeldung (2FA oder Microsoft-Konto) | AP1, AP8 |
|
||
| KW 43 | BauIn, ITM | Freigabe Datenschutz für echte Pilotdaten auf den Servern von ITM und über die KI-API | AP11, M2 |
|
||
| KW 46 | ITM | Staging-Server mit Zugang, Domain und Zertifikat | AP11, M2 |
|
||
| KW 46 | BauIn | Pilotdaten: alle LVs eines PFA als X86 + PDF (nur auf Staging) | M2 |
|
||
| KW 47 | BauIn | 10–20 abgeschlossene Nachträge mit Ergebnis (Referenzfälle) | AP2 Teil 2, AP12 |
|
||
| KW 51 | ITM | Produktions-Server mit Zugang, Domain und Zertifikat | AP11 |
|
||
| KW 51 | offen | Backups: Speicherort, Aufbewahrungsdauer, Zuständigkeit | AP11 |
|
||
|
||
## Risiken
|
||
|
||
| Risiko | Auswirkung | Gegenmaßnahme |
|
||
|---|---|---|
|
||
| Zulieferungen kommen spät | Pakete verschieben sich | Soll-Termine am 16.10. vereinbaren; vorziehen, was unabhängig ist |
|
||
| Kein anonymisierter Beispielablauf, Datenschutz für echte Daten ungeklärt | Kein realistischer Test vor M2 | Öffentliche GAEB-Beispiele; früh anfragen; echte Daten nur auf Staging |
|
||
| X86-Dateien weichen vom Standard ab (Version, Erweiterungen des Kalkulationsprogramms) | GAEB-Import aufwendiger | Beispieldatei früh anfordern; fertige Bibliothek prüfen; D86 als Rückfall |
|
||
| Sprachmodell liefert keine verlässliche strukturierte Antwort | Stufe 2 schwächer | Antwort im Code prüfen; Stufe 1 (Suche + Reranker) ist allein schon nützlich |
|
||
| Meilisearch mit 4.096 Dimensionen zu langsam | Suche muss umgebaut werden | Test in KW 41; Plan B Qdrant |
|
||
| KI-API ausgelastet (120 Anfragen/min je Schlüssel, für alle Nutzer gemeinsam) | Lange Wartezeiten bei Erstindexierung und Suche | Alles asynchron; Stapel-Embeddings; Suchanfragen bevorzugen; ggf. getrennte Schlüssel |
|
||
| Excel-Vorlage der DB enthält Makros | Export kann Makros verlieren (OP1) | Vorlage früh testen; notfalls Werte zum Einfügen exportieren |
|
||
| Fachexperte wenig verfügbar | Kein Feedback, keine Messung | Feste Freitagstermine; Referenzfälle früh anfordern |
|
||
|
||
## Aufgabenliste (nächste zwei Wochen)
|
||
|
||
**Erledigt**
|
||
- [x] Entwicklungsumgebung (WSL2, Docker, Sail), Repo mit gitleaks-Hook
|
||
- [x] Laravel 13, Livewire 4, TallStackUI 4, Fortify (2FA, Passkeys), Spatie
|
||
- [x] Mehrsprachigkeit (Deutsch Standard, Englisch)
|
||
- [x] CLAUDE.md, Tech-Stack-Doku, Projektplan
|
||
- [x] Besprechung mit BauIn (02.10.), API-Dokumentation von ITM erhalten
|
||
|
||
**KW 41**
|
||
- [ ] Fragenkatalog an BauIn (fachlich, IT) und ITM schicken
|
||
- [ ] Übergabe an Claude Design: Prototyp an den neuen Umfang anpassen
|
||
- [ ] API-Schlüssel für die Entwicklung bei ITM anfordern; Schnelltest (Modellverzeichnis,
|
||
Dimension von `embed`, `rerank`, `chat` mit Streaming)
|
||
- [ ] **Meilisearch-Test Teil 1** (erzeugte 4.096-dim. Vektoren, z. B. 50.000 Stück):
|
||
Indexierungszeit, Antwortzeit mit Filtern, RAM und Platte; jeweils ohne und mit binärer Quantisierung
|
||
- [ ] Datenmodell Kern: Mandant, Land, Projekt, PFA, Vertrag, LV, Dokument (Kategorie,
|
||
Vertraulichkeit), Nachtrag, Nachtragsposition, Mitgliedschaften
|
||
- [ ] GAEB-X86-Test mit öffentlichen Beispieldateien, Bibliothek auswählen
|
||
- [ ] CI in Gitea Actions: Tests, Pint, PHPStan
|
||
- [ ] Commits nach Gitea pushen
|
||
|
||
**KW 42**
|
||
- [ ] Aufwand für den Kostenrahmen an ITM (bis 14.10.)
|
||
- [ ] Statusbericht mit Screenshots für den 16.10.
|
||
- [ ] **Termin BauIn 16.10.:** Antworten in Plan und Doku übernehmen, Soll-Termine vereinbaren
|
||
- [ ] Rollen und Rechte (Spatie, ggf. Teams je Projekt), Benutzerverwaltung im Admin-Bereich
|
||
- [ ] Upload, privater Speicher, Download mit Rechteprüfung, Massen-Upload
|
||
- [ ] Design-Feedback an Claude Design
|
||
|
||
**Später im Plan (bereits vorgemerkt)**
|
||
- [ ] Detailplan mit Teilplänen je Arbeitspaket (KW 43)
|
||
- [ ] **Meilisearch-Test Teil 2** (KW 46–47): Trefferquote mit echten API-Vektoren und Referenzfällen,
|
||
ohne/mit binärer Quantisierung, vor und nach dem Reranker
|
||
- [ ] Push-Mirror zum Gitea von ITM einrichten, sobald die Adresse vorliegt
|
||
- [ ] 2FA-Pflicht oder Microsoft-Anmeldung umsetzen, je nach Entscheidung des Kunden
|
||
|
||
## Ausbaustufen nach Phase 1
|
||
|
||
- **Phase 2 – Prüfung der Höhe nach:** Preis der Nachtragsposition gegen Bezugsposition und
|
||
gleiche Leistung in anderen PFAs, Auszüge aus der Urkalkulation, Nachtragskalkulation. Die
|
||
vollständige Urkalkulation liegt versiegelt bei der DB; dort prüft der Einkauf die Höhe.
|
||
- **Phase 3 – Regelwerk:** Richtlinien der DB (Auszug, mit dem BauIn zu rund 80 % arbeitet:
|
||
263 PDF-Dateien, 743 MB, z. B. Ril 821, 824, 836) in die Suche aufnehmen, dazu ein interner
|
||
Chat, der mit PDF, Seite und Stelle zitiert. Phase 1 legt die Grundlagen: Dokumentspeicher,
|
||
Abschnitte mit Seitenbezug, Quellenanzeige im PDF.
|
||
- **Weitere Ideen:** Dokumentenmanagement, E-Mail-Anbindung, Anbindung an das
|
||
Dokumentensystem der DB, Österreich (ÖNORM B 2110/B 2118, ÖNORM A 2063),
|
||
Bauzeitenplan-Analyse, weitere Sprachen.
|
||
|
||
## Nebenprojekt außerhalb des Budgets
|
||
|
||
- **datenschleuse** (lokaler Scanner/Bereiniger, Prompt in `Prompt_Datenschleuse.md`):
|
||
mindestens Phase 1–2 fertig, bevor echte Kundendateien mit Claude bearbeitet werden. Bis dahin
|
||
gehen echte Kundendateien nicht an Claude. Hilft auch beim anonymisierten Beispielablauf.
|