Privylaw case study
Secure, attorney-supervised AI for privileged communication.
In roughly six weeks, we built Privylaw: a matter-scoped collaboration platform that keeps AI assistance inside attorney-controlled workflows instead of public AI chats.
- Timeline
- Roughly six weeks
- System
- Next.js, Fastify, BullMQ, PostgreSQL, Redis
- AI path
- Amazon Bedrock through a Qwen provider layer
- Core pattern
- Matter-scoped AI with attorney review
The risk
Clients were already taking legal questions to public AI tools.
Legal clients want fast answers. Public AI tools make those answers feel instantly available, but they are not designed around attorney supervision, matter context, confidentiality controls, source discipline, or durable audit records.
Privylaw was built around a different premise: if clients want fast AI-assisted help, give them a secure place to ask inside the attorney-controlled matter workflow.
Product insight
The unit of work was not chat. It was the legal matter.
Every important object in Privylaw belongs to a matter: users, roles, rooms, messages, files, AI interactions, review decisions, audit events, retention state, and legal-hold state.
That boundary lets AI behavior follow the same operating rules as the rest of the product. Privy, the assistant inside Privylaw, does not operate as a separate open-ended agent. It operates inside the matter workflow, with the server deciding what context exists, what the requester can access, and whether the answer can be returned or must be reviewed.
What we built
A real product surface, not a prototype wrapper.
- Next.js web app for workspace, matter, thread, review, admin, and settings surfaces.
- Fastify API and WebSocket server for auth, tenancy, messaging, files, AI, notifications, audit, and admin routes.
- BullMQ worker for notifications, retention, export, scan, verification, context ingestion, and async AI processing.
- PostgreSQL tenancy with Row-Level Security, Redis queue/realtime infrastructure, and shared TypeScript contracts.
- Deployment, migration, encryption, retention, eDiscovery, and cloud-readiness runbooks.
Technical depth
The work went below the interface.
This is where the engagement became more than an AI feature. The work included deciding how a legal matter should move through a system: who can see it, what context the model can use, which responses need review, what gets recorded, and what the operations team needs when something fails.
The architecture stayed conventional where conventional was useful. The important part was not novelty; it was using known production patterns to keep the AI workflow bounded, inspectable, and supportable.
Attorney, staff, client
Next.js workspace and matter UI
Fastify routes and WebSocket server
PostgreSQL tenancy with Row-Level Security
Redis, BullMQ, notifications, scans, AI jobs
Amazon Bedrock through a Qwen provider layer
Security and governance
The matter boundary shaped the product and the AI.
Privylaw was designed around tenant and matter boundaries from the beginning. That let AI behavior sit on top of the same access model as messaging, files, notifications, audit, and administration instead of becoming a separate ungoverned tool.
- Application requests establish tenant and user context before tenant-scoped work runs.
- Role-aware routes control access to matter, room, message, file, workspace, and admin surfaces.
- Authentication, CSRF protection, production startup checks, and unsafe-configuration guards were part of the build.
- Encryption paths, KMS-ready key wrapping, retention, legal hold, audit events, and guarded migration runbooks were treated as product requirements.
Model integration
The hard part was not calling a model.
Amazon Bedrock was integrated as a controlled model provider inside a larger product system. The API kept orchestration, retrieval, policy enforcement, audit, and persistence in the application boundary while Bedrock handled the model runtime.
That provider layer matters because the product behavior is not shaped by raw model output alone. It is shaped by context assembly, review policy, trace metadata, token budgets, output limits, and usage guardrails.
Review loop
Human judgment stayed in the product, not outside it.
Client-visible AI responses can be held for attorney review before they are delivered. Internal-only interactions can follow different routing rules. That distinction matters because the product has to support both speed for the legal team and supervision for client-facing output.
Privylaw does not ask firms to trust a model by itself. It keeps professional judgment in the loop and makes that review path visible in the system.
Source discipline
The system records what the model had, and what it did not.
AI interactions can include selected file IDs, recent conversation context, matter metadata, jurisdiction or firm guidance, and structured context logs. When selected files are missing, unavailable, excluded, or pruned by budget, the system preserves those reasons as context metadata.
That makes the final answer inspectable: what context was available, what evidence was missing, whether policy required review, and whether the response relied on retrieved evidence, inference, or both.
Delivery discipline
The process had to be as engineered as the product.
The underlying build included more implementation evidence than a public page needs to show in full: migration guardrails, smoke tests, runbooks, operational scripts, typecheck and lint paths, API probes, web checks, deployment packaging, and production migration procedures.
That is the point. Serious AI work is not just prompt design. It is requirements, threat modeling, data boundaries, model routing, exception handling, cost control, deployment readiness, and a maintenance path the client team can actually operate.
SQL migration files
API smoke-test files
tracked runbook files
Six-week build
The work moved from matter model to cloud readiness.
The build did not happen as a single AI sprint followed by cleanup. Product, backend, security, model routing, review policy, deployment, and verification moved together because each layer changed what the others needed to support.
- Week 1 Scope the system around tenants, users, roles, matters, rooms, messages, files, and audit events.
- Week 2 Build the collaboration surface: rooms, invitations, realtime behavior, file lifecycle, workspace screens, and matter navigation.
- Week 3 Add Privy inside the matter context, including bounded context assembly, selected-file handling, source metadata, and review routing.
- Week 4 Harden authentication, tenancy, encryption, retention, legal hold, audit, admin policy, and operational controls.
- Week 5 Integrate the Qwen path through Amazon Bedrock and prepare AWS deployment, ECS packaging, guarded migrations, and cloud readiness.
- Week 6 Stabilize deploy blockers, mobile behavior, context edge cases, missing-source handling, smoke coverage, and readiness checks.
What this proves
A repeatable pattern for serious AI workflows.
Privylaw demonstrates the kind of AI work sammartin.ai is built for: document-heavy review, expert approval loops, sensitive data, multi-system workflows, operational monitoring, and AI that must be useful without being uncontrolled.
This is a software and product case study. It is not legal advice and does not claim that any software system guarantees attorney-client privilege, compliance, or legal outcomes.