ERP-RFC-005 — Legal Vertical Engine (Lex backend)

• Status: Stub
• Date: 2026-04-12
• Author: Koder Team
• Depends on: erp-RFC-000-architecture-overview.md, kompass-RFC-001-identity-and-org-unification.md, erp-RFC-002-bpm-workflow-engine.md
• Phase: 7 (Legal vertical engine and Lex consolidation)
• Blocked by: kompass-RFC-001 (identity), ideally erp-RFC-002 (BPM for tramitação)
• Related: apps/lex (current Flutter frontend at lex.koder.dev)

---

Summary

A vertical engine owning legal practice management: mattercase management, court tracking, legal deadlines with jurisdiction-aware calendars, document automation with clause libraries, LEDES billing, trust accounting, IOLTA compliance, conflict check, AI legal assistant, tramitação of documents between lawyers and units. This is the backend that `appslex was marketed as having in its landing page (lex.koder.dev`) but does not actually exist yet — the Flutter app today is a standalone shell with local sqflite storage and no server-side domain logic.

The legal engine sits below apps/lex and above Kompass in the dependency graph. It reuses the horizontal engines already built for the rest of the ERP track (BPM, form, sign, billing, kdb) and adds the legal-vertical concepts that do not belong in any horizontal engine: matter, court, filing, statute of limitations, LEDES, trust account, conflict, precedent.

This RFC also closes a cross-cutting question raised in erp-RFC-000: is there reuse between products/vertical/edictus (licitação) and this engine? Both deal with public administration and formal documents; both need ICP-Brasil, tramitação, prazo tracking. The answer leans yes but is scoped in the RFC when promoted.

Name decision

Decided: iuris. Date: 2026-04-12.

Following the engine+product pattern, the engine is products/vertical/iuris and the product stays Lex (apps/lex, lex.koder.dev). Same split already used by services/foundation/kompass / apps/mosaic and products/vertical/edictus / (future Lex frontend integration).

Candidates evaluated

Selection rule applied

Top two by Brand (forens 84, iuris 83) differ by 1 point — within measurement noise for the Mem and Pron penalties. Tiebreaker: semantic cleanliness in both target locales (pt-BR and en-US). iuris wins because forens primes "forensics" (crime-scene work), which misrepresents the engine's scope (matter management, billing, tramitação, deadlines). All other candidates fall below the Brand ≥ 60 filter or have hard disqualifiers.

Naming consequences

• Engine package: products/vertical/iuris/
• Engine service binary: iurisd
• Engine HTTP base: iuris.koder.dev (API); lex.koder.dev stays as the product landing/app host
• Config namespace: KODER_IURIS_*
• Database role / DB name: iuris / koder_iuris (when deployed)
• Go module: flow.koder.dev/Koder/koder/products/vertical/iuris

Scope

In scope

Core legal concepts

• Matter / Case management — each legal matter has an intake, a client, a court (if applicable), a jurisdiction, a type (civil, criminal, labor, corporate, administrative, family, etc.), assigned attorneys, billing rules, and a lifecycle (intake → active → on-hold → closed → archived).
• Court integration — read-side integration with Brazilian court electronic filing systems:
  • PJe (Processo Judicial eletrônico, CNJ-standard) — federal and state courts use it
  • eSAJ (São Paulo state courts, some others)
  • Projudi (Paraná, some others)
  • SEI (administrative processes at federal agencies)
  • PACER (United States federal courts) — only if tenants need it
  • Scraping patterns mirror products/vertical/edictus's three-path redundancy; the same tools and adapters are candidates for reuse.
• Legal deadlines engine — jurisdiction-aware calendars:
  • Business days vs calendar days
  • Forensic holidays per tribunal
  • Tolling and extensions
  • Statute of limitations
  • Filing deadlines with warning chains (7 days, 3 days, 1 day, overdue)
• Document automation — templated legal documents (petitions, motions, contracts) with clause libraries, merge fields from matter and party data, version control, redlining.
• Conflict check — before accepting a new client, verify no conflict with existing clients or past clients within a configurable window. Conflict is a tenant-wide concept, so it queries across all active matters in the same Kompass tenant.
• LEDES billing — legal-specific time billing in the LEDES 1998B and UTBMS standard formats for insurance and corporate clients.
• Trust accounting — separate client trust account ledger with strict operational rules (no co-mingling, zero-balance per client, reconciliation). Owned by this engine, not by the generic billing engine, because the rules are non-trivial.
• IOLTA compliance (US tenants) — interest on lawyer trust accounts, bar-association reporting.
• AI legal assistant — integrations with platform/ai for case summarization, precedent matching, motion drafting assistance.
• Matter tramitação — the matter moves between the attorney, paralegal, senior partner for approval, etc. Modeled as BPMN processes on top of erp-RFC-002.

Document management

• Versioned document store per matter, via products/horizontal/drive.
• E-signature via products/horizontal/sign for internal approvals and external client signatures.
• ICP-Brasil for filings that require it.
• Full-text search via infra/data/kdb vector index.

Multi-tenancy

• Each law firm is a Kompass tenant.
• Lawyers, paralegals, admin staff are members with roles.
• Clients are stored in services/foundation/crm as the customer entity (a law firm's CRM is its client database).
• Matters cross-reference services/foundation/crm clients.

Out of scope (this engine)

• In-house counsel needs (a company's internal legal department managing its own contracts, compliance, disputes). Overlaps with this engine but has different priorities. A lightweight "legal" module as part of a future platform/hr/compliance extension may suit in-house better.
• Pure legal research databases (like Westlaw, Jusbrasil Pro) — Koder does not build a case law database; it integrates with existing ones.
• Debt collection workflows specific to collections firms.
• Notary services (cartórios).
• Regulatory filings beyond court — these overlap with products/vertical/edictus for public sector and are out of scope here.

Dependencies

Relationship to products/vertical/edictus

Both engines touch:

• Brazilian public administration (courts / órgãos públicos)
• ICP-Brasil signing
• Tramitação as an idiom
• Prazo tracking (judicial / administrativo)
• PDF-heavy document workflows
• Scraping as an integration technique

The RFC when promoted will decide:

1. Whether the court scraping paths (PJe, eSAJ, Projudi, SEI) live in products/vertical/iuris/scrapers/ or in a shared platform/br-scrapers/ subpackage that both engines consume. Leaning toward: dedicated scrapers per engine, sharing only a common HTTPbrowser base via `platformpipe` or a new primitive.
2. Whether products/vertical/edictus and products/vertical/iuris have a common parent for the BR-specific concepts they share (ICP-Brasil, prazo judicial/administrativo, tramitação). Probably no — a shared library is sufficient, not a parent engine.

Consolidation with the current apps/lex

The apps/lex frontend that exists today is a standalone Flutter shell. Its landing page (lex.koder.dev) markets features that imply a backend, but no backend exists. This RFC proposes:

1. apps/lex becomes the frontend of products/vertical/iuris. The sqflite-based local storage is replaced with API calls to iuris backed by kdb.
2. The landing page is updated to honestly reflect what exists and what is planned. Feature parity with the landing page is part of the MVP exit criteria.
3. apps/lex's existing pubspec.yaml dependencies (provider, http, flchart, cachednetwork_image) stay; database-facing dependencies (sqflite, path) are dropped as the backend assumes that role.

Open questions

• Decide whether this engine is BR-first or international-first at launch. Crescer/Vivver have no direct legal services business; the closest internal customer is none. If no internal tenant exists, the engine is built against synthetic demand, which is the anti-pattern erp-RFC-000 tries to avoid with the 90-day dogfooding rule.
• Should the engine start by serving internal legal concerns (contract review, LGPD, labor disputes) as a submodule of something else, and only grow into a full legal practice management engine ifwhen Koder lands a real law firm tenant? This is the honest path but collides with the `appslex` marketing.
• Court integrations are the single highest-risk part of the scope because the court portals are even more adversarial than PNCP. Start with PJe (CNJ standard) only; expand later.

Non-goals

• This stub does not commit to a delivery timeline.
• This stub does not scope AI features beyond noting that they depend on platform/ai.
• This stub does not decide whether apps/lex's landing page is rewritten before the engine ships (arguably it should be, regardless — see erp-RFC-000's dogfooding rule).

Status

Stub. This is the last phase of the ERP track and the one most likely to be reprioritized based on whether Koder lands a real law firm tenant. Without one, the engine risks being built without a real user and should probably be deprioritized relative to erp-RFC-001 (licitação, has real users) and erp-RFC-004 (fiscal, mandatory compliance). The stub reserves the RFC number so that when a law firm tenant appears the design can start immediately.