ERPRFC005 — Legal Vertical Engine (Lex backend)

• *tatus:*Stub
• *ate:*20260412
• *uthor:*Koder Team
• *epends on:*erp-RFC-000-architecture-overview.md, kompass-RFC-001-identity-and-org-unification.md, erp-RFC-002-bpm-workflow-engine.md
• *hase:*7 (Legal vertical engine and Lex consolidation)
• *locked by:*kompass-RFC-001 (identity), ideally erp-RFC-002 (BPM for tramitação)
• *elated:*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 crosscutting question raised in `erpRFC000: **is there reuse between platform/edictus` (licitação) and this engine?*Both deal with public administration and formal documents; both need ICPBrasil, tramitação, prazo tracking. The answer leans yes but is scoped in the RFC when promoted.

Name decision

*ecided: iuris.*Date: 20260412.

Following the engine+product pattern, the engine is platform/iuris and the product stays Lex (apps/lex, lex.koder.dev). Same split already used by platform/kompass / apps/mosaic and platform/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 (ptBR and enUS). 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: platform/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/platform/iuris

Scope

In scope

Core legal concepts

• *atter / 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).
• *ourt integration*— read-side integration with Brazilian court electronic filing systems:
  • *Je*(Processo Judicial eletrônico, CNJ-standard) — federal and state courts use it
  • *SAJ*(São Paulo state courts, some others)
  • *rojudi*(Paraná, some others)
  • *EI*(administrative processes at federal agencies)
  • *ACER*(United States federal courts) — only if tenants need it
  • Scraping patterns mirror platform/edictus's three-path redundancy; the same tools and adapters are candidates for reuse.
• *egal 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)
• *ocument automation*— templated legal documents (petitions, motions, contracts) with clause libraries, merge fields from matter and party data, version control, redlining.
• *onflict 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.
• *EDES billing*— legal-specific time billing in the LEDES 1998B and UTBMS standard formats for insurance and corporate clients.
• *rust accounting*— separate client trust account ledger with strict operational rules (no comingling, zerobalance per client, reconciliation). Owned by this engine, not by the generic billing engine, because the rules are non-trivial.
• *OLTA compliance*(US tenants) — interest on lawyer trust accounts, bar-association reporting.
• *I legal assistant*— integrations with platform/ai for case summarization, precedent matching, motion drafting assistance.
• *atter 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 platform/drive.
• E-signature via platform/sign for internal approvals and external client signatures.
• ICP-Brasil for filings that require it.
• Full-text search via platform/kdb vector index.

Multi-tenancy

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

Out of scope (this engine)

• *nhouse 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 inhouse better.
• *ure legal research databases*(like Westlaw, Jusbrasil Pro) — Koder does not build a case law database; it integrates with existing ones.
• *ebt collection workflows*specific to collections firms.
• *otary services*(cartórios).
• *egulatory filings beyond court*— these overlap with platform/edictus for public sector and are out of scope here.

Dependencies

Relationship to platform/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 platform/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 platform/edictus and platform/iuris have a common parent for the BRspecific concepts they share (ICPBrasil, 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 platform/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 BRfirst or internationalfirst 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 antipattern `erpRFC000` tries to avoid with the 90day 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

*tub.*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.