Add AI Workdeck - Open-Source AI Workspace for Legal Teams

[zeweihan]

Hi! I'd like to suggest adding AI Workdeck to this list.

AI Workdeck is an open-source AI-native IDE workspace built specifically for legal and document-heavy workflows. Think "VS Code for lawyers."

Key features:

• MCP agent orchestration for multi-step legal workflows
• OCR & document analysis with support for Chinese and English legal documents
• Due diligence plugin with automated risk flagging
• Evidence chain management for litigation support
• WPS WebOffice integration for seamless document editing
• Smart Clipboard and Auto Work Log for productivity

Tech stack: Java/Spring Boot + Vue + Electron + Docker, licensed under AGPLv3.

It addresses a gap in the list — most entries are chatbots or narrow tools, while AI Workdeck provides a full IDE-like workspace paradigm for legal professionals.

Would be happy to submit a PR if this seems like a good fit!

Repo: https://github.com/zeweihan/aiworkdeck
Website: https://www.aiworkdeck.com

[sophymarine]

The “VS Code for lawyers” description helps, but for an awesome‑legaltech entry the tricky bit is how the workspace deals with evidence and compliance. The README mentions evidence chain management and due‑diligence risk flags. Both touch real practice constraints.

One thing I’d look for in the repo: how provenance actually gets written down. Is each document hashed? Are timestamps stored somewhere durable? Is there an audit trail when a file changes?

Same with processing. Does analysis run locally, or are documents sent to outside services?

AGPLv3 also deserves a clear note. Firms often run internal extensions, and the network‑use clause can matter. A short section on data location plus plugin security would make review much easier.

[zeweihan]

Thanks for the thorough review — these are exactly the right questions for this space. Let me address each one.

Evidence-chain provenance

Full disclosure: the Community Edition does not yet implement cryptographic document hashing, Merkle chains, or tamper-evident audit trails. What currently exists:

• Timestamps: ProjectFile stores createdAt/updatedAt in PostgreSQL; UserActivityLog auto-timestamps every action (LOGIN, OPEN_FILE, PAGE_VIEW, etc.) with duration and metadata via Hibernate @CreationTimestamp.
• Due-diligence tracking: DdItem records state transitions (PENDING → UPLOADED → APPROVED/REJECTED) with uploadedAt and uploadedBy.
• Conversation file changes: ConversationFileChange logs ADDED/MODIFIED per session.

These are basic relational audit logs — useful, but not cryptographic provenance. The repo roadmap explicitly calls out "More auditable work records: version history, diff, citations, and review logs" and "evidence timelines" as upcoming work.

This is a genuine gap and we are not pretending otherwise. The architecture is designed so that these features slot into the existing plugin surface, but they are not shipping yet.

Data processing: local vs. external

The answer is configurable — the default setup mixes local and external:

Component	Default	Configurable to local?
AI inference (chat/agent)	Ollama (localhost)	✅ Yes, local by default
RAG / embeddings	Apache Tika + InMemoryEmbeddingStore	✅ Local
Document parsing (MinerU)	Docker container (localhost)	✅ Local
PPTX generation	Docker container (localhost)	✅ Local
Sensitive data masking	Regex-based, local	✅ Local
OCR	Alibaba Cloud Aliyun API	⚠️ External, no local fallback yet
TTS	ElevenLabs API	⚠️ External, no local fallback yet
Company data lookups	Qichacha / Tushare APIs	⚠️ External by design
Storage	Local filesystem	✅ Configurable (local / OSS / S3)

For law firms requiring air-gapped deployment: Ollama + local storage + MinerU + PPTX service keeps documents entirely on-premise. OCR, TTS, and external data APIs would need to be disabled or replaced. The sensitive-data masking service (SensitiveService) processes documents locally using regex patterns for Chinese PII — no external call.

A clearer breakdown of data-flow boundaries in the README would help — we will add that.

AGPLv3 and law-firm use

Fair point that this deserves explicit treatment:

• Internal firm use (self-hosted, no redistribution) generally does not trigger AGPLv3 disclosure obligations. Firms can run and modify the code internally without publishing changes.
• Plugins and extensions: The current architecture runs plugins in-process, which means AGPLv3 copyleft could extend to proprietary plugins. Firms building proprietary workflows should consider the commercial license, which covers closed-source SaaS, proprietary on-premise delivery, and commercial product integration.
• Network-use clause: If a firm hosts a modified version as a service accessible to external users (e.g., a client portal), AGPLv3 requires offering the source. The commercial license removes this obligation.

We will add a dedicated "Data Location & Licensing for Law Firms" section to the README that makes these boundaries clear.

Summary

The reviewer's instincts are right: the provenance story is still a roadmap item, not a shipped feature. The data-processing boundaries are configurable but should be documented more explicitly. And the AGPLv3 implications deserve a clearer write-up for the legal-tech audience.

I will update the README with a data-flow diagram, a law-firm licensing FAQ, and honest provenance status before submitting a PR. Happy to iterate if there are more questions.