DivorceParty is built across three engines — forms, evidence, and workflow — with jurisdiction encoded as a first-class input at every layer. Below is a capability-level description of each.
The forms engine treats jurisdiction, procedural posture, and conditional logic as structured data rather than copy. Uncontested-divorce workflows are first-class citizens: each filing path is modelled as a sequence with explicit prerequisites, defect conditions, and downstream dependencies.
Each form encodes its own conditional fields and cross-form dependencies. Filling Form A in Ontario propagates the entered values into Form B's relevant fields and disables Form C if A makes it inapplicable, rather than re-prompting or producing inconsistent packets.
The 63-jurisdiction model is not a dropdown. Each jurisdiction carries structured metadata for property regime (community property, equitable distribution, equalization of net family property, partnership of acquests), residency thresholds, waiting periods, support formulas, and court-rule variations.
Common registrar-rejection causes — missing affidavits, unsigned schedules, date inconsistencies, jurisdictional venue mismatches — are surfaced before the packet leaves the user's hands. The goal is to reduce the failure-to-file cycle that drives much of the access-to-justice cost in uncontested matters.
Every form is accompanied by guidance that explains what is being asked, why the court needs it, and what a typical defect looks like — written for a self-represented litigant and reviewed against the actual rules of the originating jurisdiction.
The evidence engine ingests communications, calendar data, and document evidence, extracts entities and relationships, and stores them as a typed graph alongside the source corpus. Retrieval combines vector search over the source text with graph traversal over the extracted structure.
People, organizations, locations, monetary amounts, dates, and the relationships between them are extracted from each source and reconciled across the corpus. Same-as resolution is applied across communication channels.
The engine compares assertions across sources and flags candidates for contradiction with the surrounding context attached. Output is reviewed before it ever appears in client- or counsel-facing UI.
Every retrieved fact is anchored to its original source with a citation. The system does not generate evidentiary claims without an underlying document to point at.
All ingestion is initiated by the data subject from their own accounts and devices. The platform does not request, accept, or process credentials or data belonging to non-consenting third parties.
Family law work spans a wide spectrum of reversibility. The platform's automation is organized into three tiers so the user (practitioner or individual) knows what the system is permitted to do at any moment, and so each capability can be enabled or disabled independently per matter.
The system reads, watches, and surfaces. No outbound action is taken without user direction. Used for deadline detection, contradiction flagging, and pattern surfacing.
The system prepares drafts — correspondence, form responses, summaries — and presents them for review. Nothing is sent, filed, or transmitted without explicit human approval.
Reserved for narrowly scoped, reversible tasks under explicit user authorization. Every action is logged, attributable, and bounded by the authorization scope.
The platform is hosted on Canadian infrastructure and operates under PIPEDA, with Law 25 considerations for Quebec deployments and CASL governing electronic outreach. U.S. data flows are evaluated against the applicable state privacy regime on a deployment basis.
The system collects only what is required to perform the requested task. Connector scopes are requested at the lowest level the function permits, and tokens are stored encrypted at rest with rotation supported.
No ingestion path requires the user to share another party's credentials or data. Text-message analysis runs against the user's own device export. Email and calendar ingestion uses the user's own OAuth-scoped tokens.
Every retrieval, generation, and outbound action is logged with attribution. The audit log is queryable by the matter owner and exportable for compliance review.
Account-level and matter-level deletion paths are available at any time. Backups are retained according to a documented schedule and purged on cycle.
Beyond the public platform, DivorceParty supports configured deployments for institutional partners — law schools, courts, legal-aid organizations, and clinic environments — with jurisdiction scoping, branded surfaces, and integration with partner systems where applicable.
Deployments can be scoped to one or a defined set of jurisdictions, so the forms and procedural guidance available to end users match the deploying organization's mandate.
The workflow surfaces — intake, paperwork, deadline tracking — can be configured for the specific procedural patterns of a clinic, court program, or partner organization.
Partner systems can integrate via REST endpoints. Where applicable, deployments support handoff to existing practice management or case management infrastructure.
Next.js application layer on Vercel, Postgres data layer on Supabase with row-level security, OAuth-scoped third-party connectors, and a typed graph store for the evidence engine. The architecture is documented and reviewable by institutional partners under NDA where required.
We work with practitioners, courts, law schools, and access-to-justice organizations. Tell us about your context and we will respond within five business days.
