2026-06-02 09:42:12 +02:00

12 KiB

Raw Blame History

Lawyer Feature (Mandatsvorbereitung + Dashboards)

Beschreibung und Kontext

Im Sales-Meeting mit David Vasella (WalderWyss) am 13.05.2026 hat sich ein klares Bild ergeben: Anwaltskanzleien arbeiten mit grossen Mengen nicht human-readable Daten (PDFs, E-Mails, frühere Mandate, Konflikt-Checks, KYC/AML, Buchungen). Zwischen internen Prozessen und der Mandantsbesprechung entsteht ein Overhead, den Copilot nicht löst. Existierende Branchen-Tools (Harvey.ai ~500 USD p/m/user, Legora, ClientFlex) sind teuer und decken die Anforderungen nicht voll ab. WW hat kein CRM.

PORTA hat bereits alle Bausteine: Workspace, Knowledge/RAG, Konnektoren, Neutralisierung, Private LLM. Das lawyer-Feature bündelt diese Bausteine zu einem opinionated UI für Anwälte: ein Feature-Modul mit zwei Hauptseiten – Dashboards (HR / Business-Client / IT) und Matter Preparation (Mandatsvorbereitung in 5 Minuten).

Business-Treiber:

WW konkretes Sales-Asset (HTML-Präsentation und später Live-Demo).
Eigene Use Cases für Homepage (www.poweron.swiss) – Sales-Story «echtes Produkt».
Investor-Pitch (Founderful via Dominic + Philipp) braucht klare vertikale Geschichte.
Wiederverwendbar für jede Anwaltskanzlei und mit Anpassung für Treuhand/Audit/Steuerberatung.

Fokus und kritische Details

Berufsgeheimnis (StGB Art. 321) – Mandantsdaten dürfen den Mandanten-Tenant nicht verlassen. Neutralisierung + Private LLM zwingend für jeden Pfad, der LLM nutzt (wiki/b-reference/platform/neutralization.md).
RBAC korrekt: feature-instance roles, NICHT mit mandate roles vermischen (.cursor/rules/rbac-role-separation.mdc).
Daten kommen aus heterogenen Quellen: Document Management System (DMS), E-Mail-Archiv, Zeiterfassung, Buchhaltung, KYC/AML, Konflikt-Check-DB. Konnektor-Pflege ist der harte Teil, nicht das UI.
Mockup-Daten in der WW-Präsentation müssen klar als synthetic markiert sein.

Ziel und Nicht-Ziele

Ziel: Feature-Modul lawyer mit:
- Dashboard-Seite mit Tabs pro Funktion (HR, Business/Client, IT, optional Finance).
- Matter-Preparation-Seite: Anwalt definiert Kontext (Mandant, Matter, Meeting-Ziel, Datum), System aggregiert Quellen, AI-Agent generiert Briefing (Kerndaten, Risiken, Deadlines, offene Punkte, Agenda-Vorschlag).
Ziel: Wiederverwendung der bestehenden PORTA-Bausteine (Workspace, Knowledge, Konnektoren, Neutralisierung, Private LLM).
Ziel: Standard-Konnektoren für DMS (SharePoint, iManage), E-Mail (Outlook/Exchange), KYC-/Konflikt-Datenquellen, Buchhaltung (im ersten Schritt einer pro Kategorie).
Explizit NICHT: vollständiges Practice-Management-System ersetzen (kein Time-Tracking-Replacement, kein Billing-System).
Explizit NICHT: generische Vertragsanalyse / Drafting (das machen Harvey/Legora besser, wir sind komplementär).
Explizit NICHT: eigene KYC/AML-Datenquelle aufbauen – wir konsumieren bestehende.

Betroffene Module

Gateway:
- Neues Feature-Modul platform-core/modules/features/lawyer/ mit mainLawyer.py, datamodelLawyer.py, interfaceLawyer.py, routeFeatureLawyer*.py.
- Workflow-Method platform-core/modules/workflows/methods/methodLawyer/ für lawyer.prepareMatter, lawyer.queryData.
- Konnektoren: prüfen, welche bestehen (platform-core/modules/connectors/), welche neu (DMS, KYC).
Frontend:
- Neue Komponenten ui-nyla/src/components/Lawyer/.
- Dashboard-View mit Tabs.
- Matter-Preparation-View (analog Workspace, opinionated).
DB-Migration: ja – neue Tabellen LawyerMatter, LawyerPreparation, LawyerDashboardSnapshot, LawyerKpi.
Andere Komponenten: Knowledge/RAG (bestehend), Neutralisierung (bestehend), Private LLM (bestehend), Workspace-Agent-Tools (Erweiterung).

Entscheidungen

Datum	Entscheidung	Begründung
2026-05-14	Feature-Code `lawyer` (analog `trustee`, `realEstate`)	Konsistenz mit bestehenden Feature-Modulen
2026-05-14	Template-Rollen `lawyer-admin`, `lawyer-user`, `lawyer-viewer`	RBAC-Regel: feature-instance roles, mandate-getrennt
2026-05-14	Matter-Preparation nutzt bestehenden Workspace-Agent + neue opinionated Tool-Chain	Wiederverwendung statt Neubau
2026-05-14	Dashboards starten als read-only Aggregations-Views auf Konnektor-Daten	Schneller Time-to-Demo, Schreibpfad später
2026-05-14	Sprache UI primär Englisch	WW-Audience Management Board, Investor-tauglich; DE-Lokalisierung Phase 2

Use Cases (User Stories)

UC-1: Matter Preparation in 5 Minutes

Given ein Anwalt hat morgen ein Klienten-Meeting für Matter M-2024-0042 (M&A-Transaktion). When er auf der Matter-Preparation-Seite den Matter und das Meeting-Ziel eingibt ("Statusbesprechung Due Diligence, offene Punkte"), Then sammelt das System innerhalb von ~60 Sekunden aus DMS (alle Dokumente zu M-2024-0042), E-Mails (letzte 30 Tage), Zeiterfassung (WIP + Deadlines), KYC/AML (Aktueller Status), Konflikt-Check. And generiert ein strukturiertes Briefing:

Kerndaten Mandant + Matter
Stand Due Diligence (Dokumente, offene Punkte)
Risiken & Deadlines
Offene Aktionen seit letzter Besprechung
Vorschlag Agenda
Quellenliste (jeder Punkt mit Link zur Quelle) And alle Mandantsdaten werden neutralisiert, bevor sie das LLM erreichen.

UC-2: Partner-Dashboard

Given ein Partner möchte vor der Wochensitzung den Stand seines Teams sehen. When er die Dashboard-Seite öffnet, Then sieht er HR-KPIs (Billable Hours, Utilization, Realization) für sein Team, Top-3-Risk-Matters, AR Aging. And kann pro KPI in die Detailansicht drillen (Drilldown via Konnektor-Live-Query).

UC-3: IT/Compliance-Dashboard

Given der IT-Leiter braucht für ein Audit-Meeting den Compliance-Status. When er den IT-Tab öffnet, Then sieht er Uptime, Security-Incidents (letzte 90 Tage), Patch-Status, KYC/AML-Backlog, Conflict-Check-SLAs.

Datenmodell-Skizze

Modell	Felder (Kern)	Kommentar
`LawyerMatter`	id, featureInstanceId, mandateCode, clientName, matterType, openedAt, status, leadLawyerUserId	Mandate spiegeln, nicht zweimal halten
`LawyerPreparation`	id, matterId, requestedBy, meetingGoal, createdAt, briefingJson, sourceRefs	Persistiert das generierte Briefing für Audit + Wiederverwendung
`LawyerDashboardSnapshot`	id, featureInstanceId, dashboardType, periodStart, periodEnd, dataJson, generatedAt	Cache für Dashboard-Daten, Refresh periodisch
`LawyerKpi`	id, featureInstanceId, kpiCode, label, formula, lastValue, lastValueAt, dashboardType	Konfigurierbare KPI-Definitionen pro Tenant
`LawyerSourceMap`	id, featureInstanceId, sourceType, connectorRef, mappingJson	Welcher Konnektor liefert welche Daten in welche KPI

Actions (Workflow-Method)

Action	Eingabe	Output	Zweck
`lawyer.prepareMatter`	featureInstanceId, matterId, meetingGoal, lookbackDays	LawyerPreparation (briefingJson + sourceRefs)	Sammelt aus Quellen, neutralisiert, generiert Briefing via Workspace-Agent
`lawyer.refreshDashboard`	featureInstanceId, dashboardType, periodStart, periodEnd	LawyerDashboardSnapshot	Re-aggregiert KPI-Werte aus Konnektoren
`lawyer.queryData`	featureInstanceId, freie Filter	ActionResult mit Query-Resultat	Read-only Zugriff für AI-Agent (analog `trustee.queryData`)

UI-Skizze

/lawyer/<featureInstanceId>/
  ├── dashboards/
  │   ├── hr            (Tab)
  │   ├── business      (Tab)
  │   ├── it            (Tab)
  │   └── finance       (Tab, optional)
  └── matter-preparation/
      ├── <list of recent matters>
      └── <matterId>/
          ├── briefing       (generated)
          ├── sources        (drilldown)
          └── agenda-export  (PDF/Markdown)

RBAC-Mapping

Template-Rollen (Feature-Code lawyer, mandateId=NULL, isSystemRole=False):
- lawyer-admin – Feature-Instance-Admin, Konnektor-Konfig, KPI-Definition.
- lawyer-user – Anwalt, Matter-Preparation, Dashboard read.
- lawyer-viewer – Read-only, z. B. Management Board.
Nutzung: FeatureAccessRole mit featureCode=lawyer, featureInstanceId=<id>, mandateId=<id>, roleId=<>.
Strikt getrennt von Mandate-Rollen (admin, user, viewer).

Umsetzungs-Checkliste

Datenmodell (datamodelLawyer.py) – 5 Modelle + PowerOnModel-Basis
Migration: Auto-Schema reicht? (analog trustee)
Feature-Modul (mainLawyer.py) inkl. Template-Rollen-Definition
Workflow-Method methodLawyer/ mit 3 Actions
Konnektoren-Inventur: was haben wir, was fehlt
- DMS-Konnektor (SharePoint vorhanden, iManage neu?)
- E-Mail-Konnektor (Outlook/Exchange vorhanden?)
- Zeiterfassung (mandantenabhängig, Anbindung über generisches Schema)
- KYC/AML (extern, API-Anbindung mandantenspezifisch)
- Konflikt-Check (intern WW-System – API klären)
Routes (routeFeatureLawyer.py)
Frontend-Komponenten (Lawyer/Dashboard, Lawyer/MatterPreparation)
RBAC: Template-Rollen registrieren (siehe .cursor/rules/rbac-role-separation.mdc)
Neutralisierung: prepareMatter-Action zwingend mit PrivateLLM-Pfad für sensitive Daten
Navigation (Gateway → Frontend) – Feature-Eintrag
Billing-Impact: prüfen (analog andere Features – pro Feature-Instance, Subscription-Capacity)
Mockup-Daten-Set (synthetic) für WW-Präsentation + Demo
Demo-Login-Mandant einrichten (für Live-Demo nach Präsentation)

Akzeptanzkriterien

#	Kriterium (Given-When-Then)	Prio
1	Given Anwalt mit `lawyer-user`-Rolle, When er Matter-Preparation für offenen Matter triggert, Then erhält er in <90s strukturiertes Briefing mit ≥3 Quellen	must
2	Given sensitive Mandantsdaten (Namen, Beträge), When `lawyer.prepareMatter` läuft, Then werden alle PII vor LLM-Call neutralisiert (Audit-Trail in Neutralization-Log)	must
3	Given User mit `lawyer-viewer`, When er Dashboard öffnet, Then sieht er KPIs read-only ohne Schreib-Buttons	must
4	Given User mit Mandate-Rolle `admin` aber ohne `lawyer-*`, When er Lawyer-Feature öffnet, Then Access Denied	must
5	Given Dashboard-Konnektor offline, When `refreshDashboard` läuft, Then Snapshot zeigt Fehlerstatus, Frontend zeigt klare Meldung statt leerer Werte	should
6	Given Briefing generiert, When Anwalt es exportiert, Then PDF/Markdown mit Quellenliste und «synthetic data» Wasserzeichen (im Demo-Mandanten)	should

Testplan

ID	AC	Art	Automatisiert	Repo-Pfad	Status
T1	1	api	ja	platform-core/tests/test_lawyer_prepare_matter.py	pending
T2	2	integration	ja	platform-core/tests/test_lawyer_neutralization.py	pending
T3	3,4	api	ja	platform-core/tests/test_lawyer_rbac.py	pending
T4	5	integration	ja	platform-core/tests/test_lawyer_dashboard_refresh.py	pending
T5	1,6	e2e	manuell	–	pending

Demo-Asset Plan (für WW-Präsentation)

Synthetic Matter M-DEMO-001 (M&A) mit fiktiven Dokumenten, E-Mails, Zeiteinträgen.
Briefing-Output statisch generiert und in 30-presentation/src/data/matter-preparation.json ablegen, damit die HTML-Präsentation ohne Backend funktioniert.
Wenn David Live-Demo will: gleichen Demo-Mandanten im PORTA-Demo-Tenant live verfügbar machen.

Abschluss

b-reference/platform-core/features/lawyer.md als neue Kanon-Seite anlegen
TOPICS.md Eintrag für Lawyer-Feature
Dieses Dokument → 2-build/ → 3-validate/ → 4-done/
Eintrag in c-work/_CHANGELOG.md pro Phase

12 KiB Raw Blame History Unescape Escape