Legal
Challenges
- Legal work spans complex, evolving rules across jurisdictions and documents.
- Manual review is slow, inconsistent, and prone to missed dependencies.
- Obligations and deadlines are difficult to trace through changing matters.
- Policy changes create uncertainty for established compliance decisions.
Problems We Solve
- Formal Rule Representation Encode definitions, conditions, and exceptions precisely.
- Obligation Checking Track duties, triggers, deadlines, and required evidence.
- Policy Simulation Model outcomes before a rule or interpretation changes.
- Consistency Validation Surface conflicts, gaps, and ambiguous dependencies.
- Explainable Recommendations Present traceable guidance with its supporting rationale.
Domain portfolio
Application patterns
Compare two formal-assurance approaches, then explore the domain workflows as interactive state machines.
01 Contract obligation and notice-control workbench Explore pattern
System/use case
Operational setting
Decision/claim boundary
Candidate checked statements
Illustrative controlled-English propositions for a future setup could include:
- “For every covered service interruption, if timely notice is recorded, the supplier has a cure obligation.”
- “If the cure period expires and the breach remains unresolved, the matter is eligible for termination review.”
- “Every renewal decision must be approved before the applicable notice deadline.”
These are candidate formulations, not statements that the current readback vocabulary already implements or that the underlying contract facts are true.
Example architecture
Where verified readback fits
Potential benefits
Limits/adoption considerations
02 Regulatory applicability and obligation register Explore pattern
System/use case
Operational setting
Decision/claim boundary
Candidate checked statements
Illustrative candidates include:
- “For every entity, if the entity conducts a covered activity in the selected jurisdiction and no approved exclusion applies, the entity has an assessment obligation.”
- “If a reporting obligation applies and the required evidence is incomplete, the filing control is not ready for closure.”
- “Every applicable obligation must have an accountable control owner.”
Example architecture
Where verified readback fits
Potential benefits
Limits/adoption considerations
03 Litigation elements and procedural-readiness assistant Explore pattern
System/use case
Operational setting
Decision/claim boundary
Candidate checked statements
Possible controlled-English candidates are:
- “For every asserted claim, if a required element lacks a linked evidentiary basis, the claim requires attorney review.”
- “If service is confirmed and the response deadline is approved, the response task has a scheduling obligation.”
- “Every dispositive-motion recommendation requires an approved issue statement and a supporting record reference.”
Example architecture
Where verified readback fits
Potential benefits
Limits/adoption considerations
04 Legal change-impact and interpretation comparison service Explore pattern
System/use case
Operational setting
Decision/claim boundary
Candidate checked statements
Illustrative comparison candidates include:
- “Under the proposed rule version, every newly covered service has a documentation obligation.”
- “If the revised definition applies to an existing matter, that matter requires applicability reassessment.”
- “If two approved rules assign incompatible dispositions to the same classified case, the case requires legal escalation.”
Example architecture
Where verified readback fits
Potential benefits
Limits/adoption considerations
Applicability frame
MLTTDB is most plausible here as a controlled boundary between a lawyer-owned formal model and changing, reviewable source-language records. Row types and :T: table declarations remain in Agda, Lean, or Rocq source; the SQLite term store retains ordered records, UUIDs, projections, language metadata, and table metadata. The proof assistant—not the store—performs semantic checking, whether invoked by a project pipeline or orchestrated by the store. Agda currently supports finite UUID lookup between eligible stored rows; Lean and Rocq preprocessors validate generated definitions but do not provide that lookup. Matter intake, document extraction, authority research, identity and access, source-system reconciliation, workflow, runtime controls, provenance, and formalization approval are separate production responsibilities.
Current data mode checks fetched rows as separate definitions; it does not expose a table to application proofs as an enumerable, first-class collection. Whenever an example below claims whole-snapshot coverage, uniqueness, or graph acyclicity, the architecture therefore assumes either a finite domain declared in proof source or an external snapshot compiler that emits a reconciled aggregate manifest/certificate term. The proof assistant checks that aggregate term, while external reconciliation establishes that it represents the table export supplied for legal review.
01 Contract obligation lifecycle assurance Explore pattern
Operational context
Why MLTTDB fits
Example architecture
executed contracts -> extraction/reconciliation -> lawyer review workbench
|
proof model repo -> CI ----> MLTTDB SQLite <-------+ curated typed records
fetch/orchestrate verify -> Agda/Lean/Rocq -> evidence bundle
The repository owns types, declarations, contract-family modules, and propositions. An external extraction service proposes clause spans and source coordinates; the workbench requires a lawyer to accept or correct them and writes only normalized, source-language records to MLTTDB. Verification runs against a pinned model revision. A separate obligation-management platform consumes only approved exports and executes reminders, assignments, and escalations.
Representative typed artifacts
triggerPatterns :T: TriggerPattern, noticePatterns :T: NoticePattern, and obligationTemplates :T: ObligationTemplate. Types distinguish calendar from business-day periods, one-off from recurring duties, and conditions precedent from post-trigger duties. A proposition such as wellFormedObligation checks that the selected action is available to the actor role, required evidence matches the action, and any referenced notice or cure pattern is compatible. External metadata links each UUID to agreement, clause span, reviewer, and approval record; those links are not proof of the contract text’s truth.Checks and evidence
Potential benefits
Deployment boundary
02 Litigation and regulatory deadline rule regression Explore pattern
Operational context
Why MLTTDB fits
DeadlineRuleManifest aggregate term. Proofs can then establish properties such as “a computed due date is not earlier than its trigger” under the modeled calendar assumptions, or that every mandatory event class enumerated by the manifest maps to exactly one applicable rule in a selected profile. Ordered records make regression suites stable, and UUIDs give reviewers durable handles across revisions.Example architecture
authority monitoring -> counsel-authored rule proposal -> rule-model branch
authoritative calendars -> scenario builder -> MLTTDB scenario/rule records
model and records -> proof-assistant validation -> evidence review -> release gate
Legal researchers monitor authorities in an external service. Counsel translates approved changes into a model branch and curated records. A calendar adapter snapshots the holidays and closure assumptions used for testing. Each regression scenario carries a counsel-reviewed declared DeadlineResult and witness under the selected rule-pack model. MLTTDB supplies those rows to the proof-assistant validation path. A release-gate service compares the checked declarations with the previous approved pack and routes material differences to docketing counsel before a separate deployment mechanism updates the operational engine; generic data-mode output is not treated as a computed calendar-result API.
Representative typed artifacts
forumProfiles :T: ForumProfile, deadlineRules :T: DeadlineRule, and regressionScenarios :T: DeadlineScenario. DeadlineRule can require an effective interval, event kind, duration, day-count basis, service adjustment, and precedence class. DeadlineScenario includes the reviewed inputs, a declared DeadlineResult, and a witness that the selected model relates those inputs to that result. The model can represent an explicit AuthorityRef as a typed identifier with review status, while leaving the authoritative text in the legal research system. In Agda, a scenario could refer by UUID to an earlier rule or forum row; Lean/Rocq deployments should materialize an equivalent generated definition structure without assuming that lookup feature.Checks and evidence
Potential benefits
Deployment boundary
03 Data-processing and transfer clause pre-decision review Explore pattern
Operational context
Why MLTTDB fits
Example architecture
vendor intake and contract -> extraction/classification -> privacy review UI
approved clause library ----> formal-model mapping -----> MLTTDB records
model repo and records -> proof-assistant verification -> approval workflow
The intake platform owns vendor identity, processing facts, attachments, and source text. Extraction proposes mappings with confidence and text spans. A privacy professional confirms those facts and chooses approved clause patterns in the review UI. An adapter renders the reviewed selections as source-language records. Store-orchestrated or CI verification invokes Agda, Lean, or Rocq; a findings service translates checker output into reviewer-facing language and sends dispositions to the existing third-party risk workflow.
Representative typed artifacts
processingProfiles :T: ProcessingProfile, clauseAssessments :T: ClauseAssessment, and deviationApprovals :T: DeviationApproval. Sum types prevent conflating controller/processor role claims with transfer-role claims. A ClauseAssessment carries a clause-family identifier, applicability rationale category, reviewer-confirmed source span reference, and disposition. A reconciled ClauseCoverageManifest aggregate term enumerates counsel-designated categories, accepted patterns, deviations, and assessment UUIDs; proof obligations can require every category represented there to be satisfied by an accepted pattern or an authorized deviation. Agda lookup can connect an assessment to earlier approved pattern rows; the other current backends need self-contained or generated references.Checks and evidence
Potential benefits
Deployment boundary
04 Insurance-claims coverage and denial-reason packet assurance Explore pattern
Operational context
Why MLTTDB fits
Example architecture
policy administration + claims/evidence system
|
adjuster-confirmed findings and form reconciliation
v
MLTTDB typed coverage-position packet
|
Agda/Lean/Rocq validation status and diagnostics
v
coverage counsel review -> correspondence workflow -> claim file
Policy administration and claims platforms remain the systems of record. A projection service resolves the in-force form and endorsement identifiers, preserves source references, and reports reconciliation gaps. The term store holds a minimal, preferably pseudonymized packet under a pinned legal-model revision. The proof assistant validates its typed declarations; a project-owned adapter maps native diagnostics and UUIDs into the counsel workbench. Authorized reviewers record their interpretation and approve any communication through the existing claims workflow.
Representative typed artifacts
formProfiles :T: PolicyFormProfile,
coveragePackets :T: CoveragePositionPacket, and
communicationReasons :T: CoverageReason. A PolicyFormProfile identifies
the reviewed declarations, base form, endorsements, and effective interval
without storing the authoritative documents. CoveragePositionPacket
separates reported assertions, investigator-confirmed findings, disputed
facts, unresolved coverage questions, proposed disposition, and escalation
state. A reason artifact relates one reviewed provision and finding category
to a proposed explanation; it does not assert that the provision controls as
a matter of law. Agda lookup may connect a packet to an earlier form-profile
row, while a portable design uses self-contained or ordinarily generated
associations.Checks and evidence
Potential benefits
Deployment boundary
These read-only, pan-and-zoom models expose three abstraction levels for each workflow. They are explanatory examples, not live operational or decision systems.
Public-Benefit Adjudication and Appeal
About this workflow
This example represents a public-benefit case from application through an appealable, reasoned determination. It is deliberately program-neutral: the controlling definitions, thresholds, exclusions, filing rules, and review rights can be supplied for a particular benefit and jurisdiction. The model’s concern is procedural integrity—using the right rule version, building a complete record, explaining the result, and preserving a genuine route for review.
The ordinary case begins by recording the benefit sought, filing jurisdiction, application date, and applicant identity. Evidence review maps the submitted record to required categories, requests missing or stale material, and tracks response deadlines and authorized extensions. Once the record is sufficiently complete, eligibility determination applies the definitions and criteria effective for the case, considers thresholds, exclusions, and stated exceptions, and records the rule path for each finding. A separate decision review checks the proposed outcome, reasons, and citations before accountable approval. The issued notice communicates the outcome, reasons, effective date, and applicable appeal window. If no appeal is filed in time, the operative outcome is closed and retained.
The return paths protect both the claimant and the deciding authority. Invalid intake can be corrected without silently losing the original filing context. Missing evidence sends the matter back to evidence development. Inconsistent reasoning is remanded before a decision is issued. A timely appeal reopens contested findings and permits supplemental evidence; the reviewer may affirm, revise, or remand. A remand can return to evidence collection, while an appeal outcome is reissued with a renewed operative decision. These controls matter because eligibility is not merely a yes-or-no calculation: jurisdiction, effective dates, notice, deadlines, review authority, and an auditable explanation can determine whether a legally correct result was reached through a fair process.
Layer 1 — Adjudication stages
Layer 2 — Eligibility and appeal procedures
Layer 3 — Caseworker actions
Multi-Jurisdiction Contract Obligations
About this workflow
This example models obligation management for a contract whose duties are distributed across the main agreement, schedules, amendments, and jurisdiction-specific overlays. It treats a contract as an active network of defined terms, triggering events, responsible parties, notice mechanics, deadlines, exceptions, and remedies—not as a static signed PDF.
The workflow starts by identifying the operative document set, incorporated materials, governing law, parties, and effective dates. Clause mapping normalizes defined terms, resolves document precedence, extracts conditions and exceptions, and assigns each obligation to a responsible party. Once activated, monitoring watches for events such as delivery milestones, renewals, consent requests, volume thresholds, or termination dates, then recalculates the relevant windows. A triggered obligation becomes due: the responsible party is notified, evidence of payment, delivery, consent, or notice is collected, and performance is tested for timeliness and contractual sufficiency. Satisfied performance returns the contract to active monitoring. At term, surviving duties and final notices are resolved before closure.
The machine also preserves the legal response when performance is incomplete or disputed. An incorrect document set returns to intake because downstream conclusions cannot safely rest on missing amendments. An unmet obligation moves into breach and cure, where the duty, available remedy, required notice, cure period, corrective action, and reservation of rights are tracked. A completed cure can restore monitoring; a disputed cure reopens the obligation for evaluation; an uncured material breach may close the relationship through the authorized termination path. These controls matter to contract managers and counsel because missed dependencies often arise from cross-references and changing dates, while an otherwise valid remedy can be lost through defective notice or failure to preserve rights.
Layer 1 — Contract lifecycle
Layer 2 — Obligation management procedures
Layer 3 — Clause-level actions
Regulatory Matter and Deadline Management
About this workflow
This example represents the controlled response to a regulator, supervisory authority, or other rule-bound legal request. It covers preservation and collection, privilege and responsiveness review, preparation of an approved response, filing, follow-up, remediation, and closure. The model is intentionally neutral about the authority so its procedures can be adapted to an information request, examination, notice, subpoena, or similar matter.
Opening the matter establishes the issuing authority, jurisdiction, request scope, and the deadlines for response, preservation, and internal escalation. Scoped holds and collection instructions then identify custodians and sources, track completeness, and escalate unavailable or altered records. Privilege review classifies responsive material, records the applicable privilege grounds, applies redactions or withholding, and produces the supporting privilege record. Response preparation maps each requested item to produced material or a reasoned explanation, addresses missing items and exceptions, and obtains responsible legal approval. Filing uses the required channel, confirms receipt, and tracks follow-up, correction, extension, and remediation dates until all obligations are fulfilled.
Several loops prevent a superficially complete response from becoming an unreliable filing. Privilege review can return an incomplete collection for additional records. Response preparation can reopen collection when an evidentiary gap appears. A missed deadline, rejected submission, or scope dispute enters a matter exception rather than being handled informally. The corrective path may seek an extension, repair and resubmit the filing, reopen substantive preparation, or escalate for accountable approval. Closure occurs only after final obligations and holds have been resolved and the record of decisions, productions, filings, and evidence is preserved. These controls matter because defensibility depends on chain of custody, consistent privilege treatment, timely action, approval, and proof of receipt as much as on the prose of the response.