diff --git a/README.md b/README.md index a48eeba..5b8acfd 100644 --- a/README.md +++ b/README.md @@ -49,7 +49,8 @@ It is most useful when work needs reviewable outputs, explicit scope boundaries, 4. Run the first cycle and record outputs using [framework/core/deliverables.md](framework/core/deliverables.md). 5. Keep the work inside the rules in [governance/guardrails.md](governance/guardrails.md). -**For AI systems:** Load [AI_CONTEXT.md](AI_CONTEXT.md) for a compact structured summary. +**For AI systems:** Start with [runtime/AI_BIOS.md](runtime/AI_BIOS.md) and load only the runtime cards required by the current task and profile. +**General summary:** [AI_CONTEXT.md](AI_CONTEXT.md) remains available as a compact repository overview. **For software implementers:** See [docs/software-reference.md](docs/software-reference.md) for interface contracts and schemas. ## Repository structure @@ -59,6 +60,7 @@ It is most useful when work needs reviewable outputs, explicit scope boundaries, - `framework/templates/` — reusable framework templates - `governance/` — operating rules, evidence boundaries, and policies - `governance/policies/` — machine-readable (YAML) forms of governance rules +- `runtime/` — AI runtime loader, profiles, and short execution cards ### Core method @@ -102,7 +104,19 @@ It is most useful when work needs reviewable outputs, explicit scope boundaries, | File | Purpose | | --- | --- | -| [AI_CONTEXT.md](AI_CONTEXT.md) | Compact structured summary for AI systems | +| [docs/presentation/README.md](docs/presentation/README.md) | Curated human-readable package for demos, partner talks, and funding outreach | +| [docs/presentation/architecture-bios.md](docs/presentation/architecture-bios.md) | DAD-M architecture narrative and BIOS model for decision makers | +| [docs/presentation/one-pager-dadm-governance-platform.md](docs/presentation/one-pager-dadm-governance-platform.md) | One-page project summary for advisors, partners, and funders | +| [docs/discovery/discover_funding_landscape_2026_de.md](docs/discovery/discover_funding_landscape_2026_de.md) | Discover artifact: funding options and go-to-market contact paths (DE/EU) | +| [docs/presentation/team-operating-model.md](docs/presentation/team-operating-model.md) | Operating model for a 3-person founder team | +| [docs/presentation/pitch-mail-template.md](docs/presentation/pitch-mail-template.md) | Practical outreach mail template for programs and partners | +| [docs/presentation/outreach-mail-foerderberatung-bund.md](docs/presentation/outreach-mail-foerderberatung-bund.md) | Ready-to-send first outreach mail for federal funding advisory | +| [docs/presentation/pitch-deck-outline.md](docs/presentation/pitch-deck-outline.md) | Presentation structure focused on clarity and evaluability | +| [docs/presentation/pr-description.md](docs/presentation/pr-description.md) | Clean pull request description template for this curation package | +| [docs/presentation/repo-curation-guide.md](docs/presentation/repo-curation-guide.md) | Rules to remove duplication and avoid AI-sounding language | +| [runtime/AI_BIOS.md](runtime/AI_BIOS.md) | Runtime loader entry point for AI systems | +| [runtime/file-registry.yaml](runtime/file-registry.yaml) | Runtime document registry with profiles, routes, and opt-in references | +| [AI_CONTEXT.md](AI_CONTEXT.md) | Compact structured summary for humans and general AI overview | | [docs/overview.md](docs/overview.md) | Concise method overview including design assumption | | [docs/methodology.md](docs/methodology.md) | Methodological positioning, design assumption, comparison table | | [docs/getting-started.md](docs/getting-started.md) | Step-by-step first use (7 steps including scope + approval) | @@ -116,13 +130,14 @@ It is most useful when work needs reviewable outputs, explicit scope boundaries, ## Example usage / workflow -1. Define the project brief, safety boundaries, and scope declaration. -2. Break the work into milestones with clear scope, dependencies, and priority. -3. Obtain approval for the milestone plan before starting M1. -4. Run Discover to collect the facts for milestone M1. -5. Run Apply to design the solution within those facts. -6. Run Deploy to implement only the approved design and capture proofs. -7. Run Monitor to validate the result and prepare the next milestone. +1. Choose a runtime load profile and load only the relevant runtime cards. +2. Define the project brief, safety boundaries, and scope declaration. +3. Break the work into milestones with clear scope, dependencies, and priority. +4. Obtain approval for the milestone plan before starting M1. +5. Run Discover to collect the facts for milestone M1. +6. Run Apply to design the solution within those facts. +7. Run Deploy to implement only the approved design and capture proofs. +8. Run Monitor to validate the result and prepare the next milestone. For a concrete public example, see [docs/examples/rbac-case-example.md](docs/examples/rbac-case-example.md). diff --git a/docs/discovery/README.md b/docs/discovery/README.md new file mode 100644 index 0000000..c0beebb --- /dev/null +++ b/docs/discovery/README.md @@ -0,0 +1,7 @@ +# Discovery Artifacts + +This folder contains Discover phase outputs that support strategic decisions. + +Current entry: + +- [discover_funding_landscape_2026_de.md](discover_funding_landscape_2026_de.md) diff --git a/docs/discovery/discover_funding_landscape_2026_de.md b/docs/discovery/discover_funding_landscape_2026_de.md new file mode 100644 index 0000000..4cf731f --- /dev/null +++ b/docs/discovery/discover_funding_landscape_2026_de.md @@ -0,0 +1,137 @@ +# Discover Output: Funding and Positioning (DE/EU, 2026) + +```yaml +artifact: discover-output +program: dadm-governance-platform +milestone: M21 +phase: discover +status: reviewed-draft +date: 2026-03-27 +scope: + - funding-fit screening for a 3-person team + - outreach channels for public and semi-public support + - pitch packaging requirements for human reviewers +``` + +## Team baseline + +- Team size: 3 +- Roles: + - Adrian Groszewski (Fachinformatiker, Projektmanager) + - Mischelle (Kauffrau) + - Marrt (Sicherheitsbeauftragter) +- Asset state: framework + functional software platform +- Objective: presentable and fundable growth path, not only concept stage + +## Problem statement + +The team needs a clear and realistic funding path that fits a software platform with governance and security focus, while keeping application overhead manageable for a small team. + +## Candidate funding tracks + +### Track A: Beratungs- und Matching-Einstieg (immediately) + +Purpose: identify best-fit programs before writing large applications. + +- Foerderberatung "Forschung und Innovation" des Bundes +- BMWE/BMWK Foerder- und Finanzierungsberatung +- Foerderdatenbank for program filtering + +Fit: very high, low barrier, should be used first. + +### Track B: Nationale F&E-Foerderung fuer KMU + +Purpose: finance technical platform expansion and validated pilot work. + +- ZIM (BMWK/BMWE family, R&D-oriented SME support) +- KMU-innovativ (BMBF thematic calls; software/security themes can fit) + +Fit: high when legal entity and R&D work packages are clear. + +### Track C: Steuerliche Entlastung fuer F&E + +Purpose: reduce effective R&D costs independent of a single call cycle. + +- Forschungszulage (BSFZ + tax workflow) + +Fit: high for ongoing development with documented R&D activities. + +### Track D: Gruendungs- und Wachstumsfinanzierung + +Purpose: liquidity and growth financing for operational scaling. + +- KfW ERP-Gruenderkredit StartGeld / KMU products + +Fit: medium to high, depends on legal entity age and bank path. + +### Track E: EU scale-up path + +Purpose: larger funding tickets and international validation. + +- EIC Accelerator +- Eurostars + +Fit: medium now, high after stronger traction and KPI proof. + +## Eligibility observations (initial) + +- EXIST is usually strongest for science-linked startup teams; fit depends on university/research linkage. +- ZIM/KMU-innovativ generally require robust project definition and legal/fiscal readiness. +- EIC Accelerator expects strong novelty + growth potential + execution evidence. +- For a 3-person team, application load must be staged to avoid delivery freeze. + +## Main risks + +- Application overhead displaces product execution. +- Claims in pitch material exceed provable maturity. +- Governance/security value is communicated too abstractly. + +## Discover recommendations (next 6-10 weeks) + +1. Run 2 advisory calls first (Foerderberatung + KfW orientation) before selecting grant track. +2. Build one reusable evidence pack: + - product architecture one-pager + - current capability list + - roadmap by quarter + - security and compliance baseline + - team role model and ownership map +3. Submit one primary path and one fallback path: + - Primary: R&D support track (ZIM or KMU-innovativ depending on fit) + - Fallback: Forschungszulage + KfW growth financing +4. Keep EU track as stage-2 after measurable traction. + +## Team operating split for funding work + +- Adrian: technical story, architecture proof, roadmap commitments. +- Mischelle: business case, budget logic, financial planning, partner communication. +- Marrt: security evidence, risk matrix, governance controls, compliance mapping. + +## Open questions for Apply phase + +- Which legal entity and accounting setup is active today? +- Which Bundesland-specific programs can be added as co-financing? +- Which KPI baseline (users, pilots, retention, conversion) is presentation-ready now? +- Which one-sentence "problem -> value -> proof" narrative is final? + +## Source links (official or program-near) + +- Foerderdatenbank Beratungsangebote: + https://www.foerderdatenbank.de/FDB/DE/Service/Beratung/beratung.html +- Foerderberatung Forschung und Innovation contact page: + https://www.foerderdatenbank.de/FDB/Content/DE/Kontakt/F/foerderberatung-forschung-und-innovation.html +- ZIM program portal: + https://www.zim.de/ +- ZIM FAQ FuE-Projekte: + https://www.zim.de/ZIM/Redaktion/DE/FAQ/FuE-Projekte/fue-projekte.html +- KfW StartGeld overview: + https://www.kfw.de/%C3%9Cber-die-KfW/Newsroom/Aktuelles/StartGeld.html +- EXIST Gruenderstipendium one-pager (BMWE): + https://exist.de/wp-content/uploads/2025/11/BMWE_Onepager_EXIST-Gruendungsstipendium_2025-DE_web-bf.pdf +- KMU-innovativ IKT (Bundesanzeiger publication entry): + https://www.bundesanzeiger.de/pub/de/amtlicher-teil?edition=BAnz+AT+20.12.2021&year=2021 +- BSFZ/Forschungszulage process guidance: + https://www.bescheinigung-forschungszulage.de/dateien/PDF/20240506_Pruefleitfaden_BSFZ_Mai_2024.pdf +- EIC Accelerator (official program entry): + https://eic.ec.europa.eu/eic-funding-opportunities/eic-accelerator_en +- Eurostars (official program page): + https://www.eurekanetwork.org/programmes/eurostars/ diff --git a/docs/presentation/README.md b/docs/presentation/README.md new file mode 100644 index 0000000..1bcfdac --- /dev/null +++ b/docs/presentation/README.md @@ -0,0 +1,25 @@ +# Praesentationspaket (deutsch) + +Dieser Ordner ist der kuratierte Einstieg fuer Leserinnen und Leser, die DAD-M schnell und klar verstehen sollen. + +## Empfohlene Reihenfolge + +1. [architecture-bios.md](architecture-bios.md) +2. [one-pager-dadm-governance-platform.md](one-pager-dadm-governance-platform.md) +3. [team-operating-model.md](team-operating-model.md) +4. [pitch-deck-outline.md](pitch-deck-outline.md) +5. [pitch-mail-template.md](pitch-mail-template.md) +6. [outreach-mail-foerderberatung-bund.md](outreach-mail-foerderberatung-bund.md) +7. [pr-description.md](pr-description.md) +8. [repo-curation-guide.md](repo-curation-guide.md) + +## Ziel des Pakets + +- klare Sprache statt Buzzwords +- keine doppelten Erklaerungen +- trennscharf zwischen heutigem Stand und Roadmap +- direkte Nutzbarkeit fuer Partner, Foerderstellen und Gremien + +## Zugehoeriges Discover-Artefakt + +- [../discovery/discover_funding_landscape_2026_de.md](../discovery/discover_funding_landscape_2026_de.md) diff --git a/docs/presentation/architecture-bios.md b/docs/presentation/architecture-bios.md new file mode 100644 index 0000000..c01068b --- /dev/null +++ b/docs/presentation/architecture-bios.md @@ -0,0 +1,46 @@ +# DAD-M Architektur und BIOS-Narrativ + +## Ein Satz + +DAD-M ist eine Governance-first Plattform, die KI-gestuetzte Projektarbeit in pruefbare, meilensteinbasierte Umsetzung ueberfuehrt. + +## Architektur in Klartext + +Die Plattform hat fuenf Ebenen: + +1. Methodenebene: Discover, Apply, Deploy, Monitor als klare Zustandswechsel. +2. Governance-Ebene: Regeln, Freigaben und blockierende Kontrollpunkte. +3. Runtime-Ebene: Kontextladung, Profile und Ausfuehrungskarten. +4. Artefakt-Ebene: Meilenstein-Ergebnisse, Entscheidungen und Evidenz. +5. Delivery-Ebene: Softwarebetrieb, Teamprozesse und Nutzerablaeufe. + +## BIOS-Modell fuer Entscheider + +Fuer Praesentationen verwenden wir BIOS als kompaktes Erklaerungsmodell: + +- Business: messbarer Nutzen fuer Teams, Kunden und Partner. +- Integrity: Nachvollziehbarkeit, Reproduzierbarkeit, Verantwortlichkeit. +- Operations: wiederholbare Umsetzung mit klaren Uebergaben. +- Security: Risikogrenzen, Freigabelogik, kontrolliertes Aenderungsverhalten. + +## BIOS-Mapping auf DAD-M + +| BIOS-Bereich | DAD-M-Mechanismen | Evidenzbeispiele | +| --- | --- | --- | +| Business | Meilensteinplanung, Scope-Kontrolle, Akzeptanzkriterien | freigegebene Plaene, Abnahmeprotokolle | +| Integrity | Artefakt-Retention, Entscheidungsprotokolle, Kontrollpunkte | Discover/Apply/Deploy/Monitor-Artefakte | +| Operations | Bootstrap-Protokoll, Module, Runtime-Profile | Bootstrap-Nachweise, Profilzuweisungen | +| Security | Guardrails, Severity-Logik, Eskalation und Rework | Policy-Dateien, Severity-Records | + +## Aktueller Plattformstand (extern kommunizierbar) + +- Oeffentliches Framework-Repository mit nutzbarer Methodenbasis. +- Governance- und Runtime-Artefakte sind verlinkt und einsetzbar. +- Funktionsfaehige Softwareplattform fuer reale Demo-Workflows vorhanden. +- Naechste Phase: Skalierung auf Multi-Tenant-Betrieb und Asset-Lifecycle-Governance. + +## Was wir in Praesentationen vermeiden + +- Keine unbelegten Zertifizierungs- oder Compliance-Aussagen. +- Kein "KI macht alles", sondern kontrollierte Zusammenarbeit. +- Keine Vermischung von heutigem Stand und Zukunfts-Roadmap. diff --git a/docs/presentation/one-pager-dadm-governance-platform.md b/docs/presentation/one-pager-dadm-governance-platform.md new file mode 100644 index 0000000..90a6ba4 --- /dev/null +++ b/docs/presentation/one-pager-dadm-governance-platform.md @@ -0,0 +1,63 @@ +# One-Pager: DAD-M Governance-Plattform + +## Kurzstatement + +DAD-M ist eine Governance-first Softwareplattform fuer KI-gestuetzte Projektumsetzung. Sie ueberfuehrt ad-hoc KI-Arbeit in pruefbare Meilenstein-Umsetzung mit klaren Entscheidungsstellen. + +## Problem + +Teams mit KI-Einsatz in Projekten haben oft dieselben Ausfaelle: + +- Analyse, Design, Umsetzung und Validierung werden vermischt +- Entscheidungen sind im Nachgang schwer nachvollziehbar +- Umfangsdrift erzeugt Liefer- und Sicherheitsrisiken +- Ergebnisse sind unter Review schlecht reproduzierbar + +## Loesung + +DAD-M erzwingt ein Vier-Phasen-Betriebsmodell: + +1. Discover (Fakten) +2. Apply (Design) +3. Deploy (Umsetzung) +4. Monitor (Validierung) + +Dieses Modell wird durch Governance-Kontrollen, Runtime-Profile und Artefakt-Retention getragen. + +## Warum jetzt + +- KI-Adoption steigt schneller als Governance-Reife. +- Auftraggeber und Foerderstellen fordern mehr Nachvollziehbarkeit. +- Security- und Compliance-Anforderungen steigen im Multi-Tenant-Betrieb. + +## Aktueller Stand + +- Oeffentliches Methoden-Repository mit Framework- und Governance-Kern. +- Runtime- und Profilkonzept dokumentiert und einsetzbar. +- Funktionsfaehige Softwareplattform fuer reale Demoablaeufe vorhanden. +- Skalierungsroadmap fuer Multi-Tenant-Governance und Asset-Lifecycle aktiv. + +## BIOS-Wertmodell + +- Business: kuerzerer Weg von Idee zu reviewfaehigem Ergebnis. +- Integrity: nachweisbare Entscheidungen und reproduzierbare Artefakte. +- Operations: strukturierte Uebergaben und Meilensteinsteuerung. +- Security: explizite Guardrails, Severity-Logik und Eskalationspfade. + +## Team + +- Adrian Groszewski: Produktarchitektur und Projektsteuerung +- Mischelle: kaufmaennische Steuerung und Finanzierungskommunikation +- Marrt: Security-Governance und Risikokontrollen + +## Anfrage + +Wir suchen Programmpassungs-Beratung und passende Wachstumsfinanzierung fuer die naechste Plattformphase: + +- primaer: F&E-Foerderpfad fuer technische Skalierungsarbeitspakete +- sekundaer: steuerliche und finanzielle Instrumente fuer Umsetzungsstabilitaet + +## Kontakt + +- Ansprechpartner: Adrian Groszewski +- Repository: https://github.com/AdrianGros/dadm-framework diff --git a/docs/presentation/outreach-mail-foerderberatung-bund.md b/docs/presentation/outreach-mail-foerderberatung-bund.md new file mode 100644 index 0000000..cb36ac2 --- /dev/null +++ b/docs/presentation/outreach-mail-foerderberatung-bund.md @@ -0,0 +1,41 @@ +# Outreach-Mail (zugeschnitten): Foerderberatung "Forschung und Innovation" des Bundes + +## Zielkontakt + +- Institution: Foerderberatung "Forschung und Innovation" des Bundes +- E-Mail: beratung@foerderinfo.bund.de +- Hotline: 0800 26 23 008 +- Lotsendienst Unternehmen: 0800 26 23 009 + +Quelle: +https://www.foerderdatenbank.de/FDB/DE/Service/Beratung/beratung.html + +## Betreff + +Anfrage Foerderfit-Check: DAD-M Governance-Plattform (3er-Team, funktionsfaehige Software) + +## Mailtext + +Sehr geehrtes Team der Foerderberatung "Forschung und Innovation" des Bundes, + +wir sind ein 3-koepfiges Team und entwickeln mit DAD-M eine funktionsfaehige Governance-Plattform fuer KI-assistierte Projektarbeit. Unser Schwerpunkt liegt auf nachvollziehbarer Umsetzung mit klaren Meilensteinen, Entscheidungsprotokollen und Security-Guardrails. + +Team: +- Adrian Groszewski (Fachinformatiker, Projektmanager) +- Mischelle (Kauffrau) +- Marrt (Sicherheitsbeauftragter) + +Wir moechten vor einer Antragstellung einen Foerderfit-Check durchfuehren und die passende Linie fuer unseren naechsten Skalierungsschritt identifizieren (Multi-Tenant-Betrieb, Asset-Lifecycle, Governance-Automation). + +Wenn sinnvoll, senden wir Ihnen vorab: +1. One-Pager (Problem, Loesung, Reifegrad) +2. Architektur- und Sicherheitsuebersicht +3. Roadmap mit Arbeitspaketen + +Koennen wir dafuer einen kurzen Beratungstermin (20-30 Minuten) vereinbaren? + +Vielen Dank und freundliche Gruesse +Adrian Groszewski +fuer das DAD-M Team +[Mail] | [Telefon] +https://github.com/AdrianGros/dadm-framework diff --git a/docs/presentation/pitch-deck-outline.md b/docs/presentation/pitch-deck-outline.md new file mode 100644 index 0000000..6372248 --- /dev/null +++ b/docs/presentation/pitch-deck-outline.md @@ -0,0 +1,38 @@ +# Pitch-Deck-Struktur (10 Folien) + +## Ziel + +Klar zeigen, warum DAD-M relevant ist, was bereits funktioniert und wofuer die Finanzierung konkret eingesetzt wird. + +## Folienstruktur + +1. Problem + - Warum KI-gestuetzte Umsetzung ohne Governance scheitert + - Kosten durch unklare Ownership und fehlende Reproduzierbarkeit +2. Loesung + - DAD-M als Discover/Apply/Deploy/Monitor-Betriebssystem + - Was heute schon produktiv ist, was Roadmap ist +3. Produktdemo-Ablauf + - ein realer Workflow von Eingabe bis Monitor-Ergebnis +4. Architektur und BIOS + - Business, Integrity, Operations, Security in der Praxis +5. Traktion und Nachweise + - Nutzer, Pilotprojekte, Nutzungsdaten, qualitative Evidenz +6. Markt und Zielkunden + - wer zahlt, warum jetzt, warum dieser Ansatz +7. Wettbewerb und Differenzierung + - Alternativen und strukturelle Vorteile von DAD-M +8. Mittelverwendung + - konkrete Arbeitspakete, Budgetbloecke, Meilensteine +9. Team und Umsetzungsfaehigkeit + - Rollen, Ownership, Umsetzungsrhythmus +10. Anfrage und naechster Schritt + - gewuenschte Unterstuetzung, Zeitplan, Terminvorschlag + +## Deck-Qualitaetscheck + +- pro Folie genau eine Kernbotschaft +- keine leeren Buzzwords +- jede Leistungsbehauptung mit Quelle oder Artefakt +- kein Zukunftstext in Folien zum Ist-Stand +- letzte Folie mit klarer Handlungsaufforderung diff --git a/docs/presentation/pitch-mail-template.md b/docs/presentation/pitch-mail-template.md new file mode 100644 index 0000000..0cfa3ef --- /dev/null +++ b/docs/presentation/pitch-mail-template.md @@ -0,0 +1,40 @@ +# Pitch-Mail-Vorlage (Foerderung / Programmkontakt) + +Diese Vorlage ist fuer den Erstkontakt gedacht. Zielumfang: maximal 180 Woerter. + +## Betreffoptionen + +- DAD-M Governance-Plattform - Anfrage zur Programmpassung +- Foerderfit-Check fuer Governance-first KI-Projektumsetzung +- Kurzvorstellung und Terminanfrage (F&E-Foerderung) + +## Vorlage + +Hallo [Name/Team], + +wir sind ein 3-koepfiges Team und entwickeln mit DAD-M eine funktionsfaehige Governance-Plattform fuer KI-assistierte Projektarbeit. Unser Fokus ist nachvollziehbare Umsetzung mit klaren Meilenstein-Phasen, Entscheidungsprotokollen und Security-Guardrails. + +Kurz zu uns: +- Adrian Groszewski: Fachinformatiker, Projektmanagement, Produkt und Architektur +- Mischelle: Kaufmaennische Leitung, Finanzierung und Partnerkommunikation +- Marrt: Sicherheitsbeauftragter, Risiko- und Compliance-Absicherung + +Wir suchen die passende Foerderlinie fuer den naechsten Skalierungsschritt (Multi-Tenant-Betrieb, Asset-Lifecycle, Governance-Automation) und moechten vor Antragstellung einen Fit-Check mit Ihnen durchfuehren. + +Wenn hilfreich, senden wir vorab: +1. One-Pager (Problem, Loesung, Reifegrad) +2. Architektur- und Sicherheitsuebersicht +3. Roadmap mit Ressourcenplanung + +Koennen wir dafuer einen kurzen Termin (20-30 Minuten) vereinbaren? + +Viele Gruesse +[Name] +[Rolle] +[Mail] | [Telefon] | [Repo/Website] + +## Anlagen fuer die Erstantwort + +1. One-Pager (PDF) +2. Pitch-Deck (8-10 Folien) +3. kurzer Demo-Link diff --git a/docs/presentation/pr-description.md b/docs/presentation/pr-description.md new file mode 100644 index 0000000..8df412a --- /dev/null +++ b/docs/presentation/pr-description.md @@ -0,0 +1,39 @@ +# PR-Beschreibung (fertig zum Einfuegen) + +## Titel + +Praesentationspaket kuratiert: Architektur-Narrativ, One-Pager und Foerder-Outreach + +## Ziel + +Das Repository brauchte einen klaren, deutschsprachigen Einstieg fuer externe Pruefende (Foerderstellen, Partner, nicht-technische Stakeholder). Die Methodenbasis war bereits stark, aber Praesentationsinhalte waren noch nicht als zusammenhaengendes Paket aufbereitet. + +## Aenderungen + +1. Klares Praesentationspaket unter `docs/presentation/` ergaenzt: + - Architektur- und BIOS-Narrativ + - Team-Betriebsmodell fuer ein 3er-Team + - Pitch-Deck-Struktur + - praktische Pitch-Mail-Vorlage + - Kurationsleitfaden ohne Wiederholungen und Buzzwords +2. Discover-Artefakt zur Foerderfaehigkeitsanalyse eingebunden: + - `docs/discovery/discover_funding_landscape_2026_de.md` + - mit gestuftem DE/EU-Pfad, Risiken und naechsten Schritten +3. `README.md`-Index aktualisiert, damit diese Inhalte direkt auffindbar sind. + +## Umfang und Abgrenzung + +- Im Umfang: Dokumentationskurierung, Foerder-Discover-Aufbereitung, externe Kommunikationsbausteine. +- Nicht im Umfang: Methodenlogik, Policies, Runtime-Verhalten, Softwareimplementierung. + +## Review-Checkliste + +1. Ist der neue Praesentationspfad in unter 10 Minuten verstaendlich? +2. Sind Ist-Stand und Roadmap klar getrennt? +3. Sind die Foerderempfehlungen fuer ein 3er-Team realistisch? +4. Gibt es noch doppelte Aussagen, die durch Verweise ersetzt werden sollten? + +## Risiko-Hinweise + +- Programmpassung kann sich aendern; Quellen vor Einreichungsfenstern erneut pruefen. +- Einzelne Foerderpfade haengen von Rechtsform und Buchhaltungsstatus ab; diese Punkte sind bewusst als offen markiert. diff --git a/docs/presentation/repo-curation-guide.md b/docs/presentation/repo-curation-guide.md new file mode 100644 index 0000000..4656178 --- /dev/null +++ b/docs/presentation/repo-curation-guide.md @@ -0,0 +1,47 @@ +# Repo-Kurationsleitfaden (keine Wiederholungen, kein KI-Sprech) + +## Ziel + +Das Repository soll fuer menschliche Pruefende in unter 10 Minuten vertrauenswuerdig und verstaendlich sein. + +## Kurationsregeln + +1. Ein Konzept, eine kanonische Datei. +2. Verlinken statt mehrfach erklaeren. +3. Vage Begriffe durch Evidenz ersetzen. +4. Aussagen pruefbar und zeitlich einordnen. +5. Strikt unterscheiden: + - aktueller Leistungsstand + - validierter naechster Schritt + - offene Fragestellung + +## Schreibmuster, die wir vermeiden + +- "State of the Art" ohne Vergleich +- "End-to-End" ohne Systemgrenze +- "AI-native" ohne operativen Gehalt +- doppelte Zusammenfassungen in README, Overview und Zusatzseiten + +## Sprachstandard + +- kurze Absaetze (maximal 4 Zeilen) +- aktive Verben +- konkrete Zahlen, wo moeglich +- pro Thema eine Tabelle, nicht pro Absatz +- ein Glossarbegriff pro Konzept + +## Struktur-Checkliste + +- README verweist auf genau einen Haupteinstieg. +- Jeder Ordner hat ein kurzes `README.md` mit Zweck und Einstieg. +- Entscheidungsprotokolle liegen in `docs/decisions/`. +- Praesentationsunterlagen liegen in `docs/presentation/`. +- Discover-Artefakte liegen in `docs/discovery/`. + +## Release-Check fuer externe Nutzung + +1. Doppelte Inhaltsseiten entfernen oder in Verweise umwandeln. +2. Alle externen Links und Kontakte pruefen. +3. Keine vertraulichen Daten in Beispielen veroeffentlichen. +4. Abschnitt "Was wir heute nachweisen koennen" in README oder Deck pflegen. +5. Eine Lesbarkeitspruefung durch eine fachfremde Person einholen. diff --git a/docs/presentation/team-operating-model.md b/docs/presentation/team-operating-model.md new file mode 100644 index 0000000..39ed6f3 --- /dev/null +++ b/docs/presentation/team-operating-model.md @@ -0,0 +1,38 @@ +# Team-Betriebsmodell (3 Personen) + +## Prinzip + +Kleines Team bedeutet maximale Klarheit: ein Owner pro Ergebnis, keine unklaren Zustaendigkeiten. + +## Rollen und Ownership + +| Bereich | Primaer | Backup | Ergebnis | +| --- | --- | --- | --- | +| Produktarchitektur und Techniknarrativ | Adrian | Marrt | Architekturblatt, Roadmap, Demo-Skript | +| Kaufmaennische Logik und Antragsaufbereitung | Mischelle | Adrian | Budget, Business Case, Partnerkommunikation | +| Security- und Governance-Evidenz | Marrt | Adrian | Risikomatrix, Kontrollnachweise, Compliance-Mapping | + +## Wochenrhythmus + +1. Montag (45 Min): Prioritaeten, Foerderpfad, Blocker. +2. Mittwoch (30 Min): Stand der Antragsbausteine und Evidenzluecken. +3. Freitag (45 Min): Review gegen Einreichungs-Checkliste. + +## RACI fuer Foerderworkflow + +| Aufgabe | Adrian | Mischelle | Marrt | +| --- | --- | --- | --- | +| Programmauswahl | C | A/R | C | +| Technische Arbeitspakete | A/R | C | C | +| Budget- und Finanzteil | C | A/R | I | +| Security-/Compliance-Kapitel | C | I | A/R | +| Finale Einreichung | A | A/R | R | +| Externer Pitch-Termin | A/R | A/R | C | + +Legende: R = Responsible, A = Accountable, C = Consulted, I = Informed + +## Entscheidungsregeln + +- Kein Versand ohne klaren Owner je Kapitel. +- Keine Behauptung ohne belegbares Artefakt. +- Kein Roadmap-Versprechen ohne Umsetzungsverantwortung.