Jurisk.io

01. Context & Specifications

Jurisk.io is a premium contract analysis SaaS engineered to dissect legal files (PDF, DOCX) to isolate hidden liabilities, indemnification traps, and obligations. Built using a dark glassmorphic design system, it implements a highly flexible, credit-based usage ledger (recurring monthly free tier tokens combined with permanent premium credit packs) to charge users programmatically per execution rather than imposing rigid flat subscriptions.

02. Architecture Pipeline

Unit modeling of the processing and isolation cycle of business data for this project:

[Client Contract Upload] ──> [Next.js Server Action] ──> [Prisma Context Hydration]
                                                                        │
 [PostgreSQL Ledger] <── [Zod Strict Object Type Parsing] <── [OpenAI JSON Output Gate]
         │
 [Credit Token Balance Verification] ──> [Immersive Premium Risk Analytics UI]

03. Structured JSON Output Enforcement & Prisma Data Layer

To bypass processing timeouts during deep contract multi-pass reads, the parsing pipeline uses Next.js server actions wrapped around an OpenAI native JSON schema lock. The output format is explicitly verified at the compiler layer using Zod, ensuring that risk scores, clause references, and severity rankings map perfectly to relational entities without risking a runtime error.

import { z } from "zod";

// Definition of the strict JSON format expected from the LLM Layer
export const LegalRiskSchema = z.object({
  contractId: z.string().uuid(),
  riskScore: z.number().min(0).max(100),
  criticalClauses: z.array(z.object({
    clauseNumber: z.string(),
    severity: z.enum(["LOW", "MEDIUM", "HIGH"]),
    remediationSuggestion: z.string()
  })),
  complianceStatus: z.boolean()
});

export type LegalRiskAnalysis = z.infer<typeof LegalRiskSchema>;

04. Retrospective & Limitations

>_ Post-deployment engineering notes:Utilizing structured native JSON constraints brought parsing errors down to <0.6% in staging. However, processing legacy scanned documents requires an heavy OCR parsing loop. Parallelizing execution across separate multi-page segments is currently being added to keep execution speeds within acceptable brackets.