Senior n8n / PostgreSQL Automation Developer — AI-Native Legal Operations Platform

# Senior n8n / PostgreSQL Automation Developer — AI-Native Legal Operations Platform We are a personal injury law firm operating across California, Washington, and Texas with approximately 400 active cases. We are building a production-grade AI-native legal operations system and need a senior automation developer to own the implementation. This is not a simple CRM integration or a few Zapier workflows. It is a multi-system automation platform for legal risk detection, case operations, document intelligence, medical billing reconciliation, and settlement/disbursement controls. The architecture documentation is complete. The data model is defined. The tech stack is locked. n8n is already self-hosted and deployed. We need someone to build the workflows, PostgreSQL schema, integrations, error handling, and production operating layer. --- ## Tech Stack - Automation engine: n8n, self-hosted on Hetzner via Docker Compose - Database: PostgreSQL on the same server - Case management: CasePeer REST API with OAuth 2.0 - AI layer: Anthropic Claude API and OpenAI API, including GPT and Whisper - Operations layer: Airtable REST API - Document storage: Dropbox API - Communications: Slack API for alerts, approvals, escalations, and case channels - E-signatures: DocuSeal webhooks - Intake CRM: GoHighLevel - Post-retainer intake: Jotform webhooks - Phone/transcription: RingCentral Call Log API and OpenAI Whisper - Physical mail: Lob API - Email: Google Workspace / Gmail API --- ## What You Will Build The system is a legal risk intelligence and operational reconciliation engine. Its purpose is proactive risk detection — catching missing providers, unresolved liens, ERISA exposure, UM/UIM preservation failures, coverage gaps, overtreatment, loan liability, and settlement/disbursement problems before they become malpractice events or lost recovery. Core workflows include: 1. **New case setup** — triggered by DocuSeal webhook after retainer signature, coordinated across GHL, Jotform, CasePeer, Airtable, and Slack 2. **Daily malpractice red flag monitor** — scheduled polling of all active cases, 30+ flag types across Severity 1/2/3, routed to staff through Slack with escalation and approval logic 3. **Document intake pipeline** — email/fax ingestion, PDF/text extraction, OCR using Tesseract with AWS Textract fallback, SHA-256 hash deduplication, AI classification and extraction, CPT/HCPCS/ICD code extraction and validation, service-line-level medical bill reconciliation, verified-fact creation, and red flag triggering 4. **Call transcript processing** — RingCentral call retrieval, MP3 download, OpenAI Whisper transcription, structured analysis, CasePeer note write-back, Slack escalation if flagged 5. **Demand letter drafting** — pulls from verified PostgreSQL service lines and diagnosis facts, sends structured prompts to Claude API, routes drafts for attorney review before use 6. **Settlement and disbursement gates** — three sequential hard-stop gates (pre-demand, pre-settlement acceptance, pre-disbursement) with tiered override authority, lien tracking, and net-to-client floor enforcement 7. **UM/UIM preservation workflow** — parallel claim tracking from day one, state-specific notice gates for CA/WA/TX, consent-to-settle hard block before any third-party limits demand 8. **ERISA detection and viability workflow** — suspicion detection at intake, viability ratio calculation, attorney go/no-go gate, pre-negotiation tracking 9. **Pre-settlement loan tracking** — compound interest projections, owner-only authorization gate, disbursement ledger integration 10. **Case economics dashboard** — real-time net-to-client projection, one-third floor enforcement, overtreatment monitoring, injury severity classification --- ## PostgreSQL Role and Schema Requirements PostgreSQL is not merely the n8n backend. It is the durable structured data layer for extracted and reconciled case facts. PostgreSQL will store: - Medical billing service lines - Diagnosis facts - CPT, HCPCS, and ICD-10 reference/validation tables - Document hash registry for SHA-256 deduplication - Document metadata - Audit logs - Future pgvector search data **Core principle: provider totals are downstream outputs; service lines are the source data.** Everything — medical specials, lien reductions, demand letters, net-to-client projections — must be built from reconciled service lines, not bill-document totals. Required tables include at minimum: service_lines, diagnosis_facts, document_hashes, document_metadata, cpt_reference, hcpcs_reference, icd10_reference, audit_log, and supporting reference tables. Schema design, constraints, and indexes must be submitted for review before implementation. service_lines will require composite indexes around case, provider, date of service, codes, billed amount, source document, and document hash. --- ## Airtable Role Airtable is the human-facing review and operations layer, not the raw data store. It holds case operational metadata, CM review queues, red flags, verified fact summaries, coverage log, lien registry, loan registry, incident groups, case economics dashboard, provider reconciliation status, and readiness scores. Airtable is the operations dashboard. PostgreSQL is the structured source of truth for service-line, diagnosis, validation, deduplication, and audit data. --- ## Required Qualifications Production experience with: - **n8n**: complex multi-branch workflows, Code nodes, error handling, retry logic, scheduled polling, webhooks - **PostgreSQL**: schema design, indexes, migrations, constraints, reconciliation queries - **REST APIs**: OAuth 2.0, token refresh, pagination, rate limits, credential management - **AI APIs**: Anthropic Claude API and/or OpenAI API in production - **Structured AI extraction**: JSON output parsing, validation, confidence scoring, human review routing - **Document processing**: PDF text extraction, OCR pipelines, structured extraction from unstructured documents - **Airtable API**: reads, writes, linked records, formulas, operational dashboards - **Slack API**: message posting, interactive approvals/buttons, thread management, escalation alerts - **Production discipline**: env vars, secrets handling, audit logging, backup verification, error alerting --- ## Nice to Have - Legal, medical, insurance, or personal injury workflow experience - Medical billing knowledge: CPT, HCPCS, ICD-10 code structures - Whisper transcription pipelines - Lob API or physical mail API experience - pgvector or vector search experience - CasePeer, GoHighLevel, RingCentral, DocuSeal, Dropbox, or Google Workspace API experience --- ## Initial Phase The first phase will include: 1. Review the architecture documentation and confirm implementation plan 2. Review and finalize the PostgreSQL schema, constraints, indexes, and migration approach 3. Build the first production workflows: - CasePeer OAuth/API validation - Airtable sync foundation - Document hash/deduplication foundation - Service-line extraction storage foundation - Slack alert/error handling foundation 4. Document deployment, secrets, logs, backup assumptions, and maintenance procedure We prefer to begin with a paid discovery and schema review milestone before committing to the larger build. --- ## Screening Questions Please answer these directly and concisely: 1. Describe a production n8n workflow you built involving multi-branch logic, Code nodes, and multiple API integrations. What was the most complex part? 2. Have you designed a PostgreSQL schema where data from multiple sources had to be reconciled at the record level, not just the document level? Describe your approach. 3. Have you built document processing pipelines involving OCR, AI extraction, and structured database storage? What tools did you use? 4. Have you used Anthropic Claude API or OpenAI API to extract structured data from documents? How did you handle validation, JSON parsing, confidence scoring, and bad outputs? 5. What is your preferred approach to rolling or cumulative records where each new submission may repeat prior data while adding new data? 6. Have you implemented OAuth 2.0 integrations in n8n or a similar automation platform? How did you handle token refresh, credential security, and API failures? 7. Are you comfortable working with sensitive legal and medical client data under strict confidentiality expectations? --- ## Engagement This is an ongoing part-time contractor engagement. Work is delivered in phases, reviewed against a detailed specification, and compensated per phase or hourly depending on scope. Shortlisted candidates will be invited to a brief call and will receive full architecture documentation for review under a mutual NDA before any commitment is made. The documentation is detailed and specific — it will give you a clear picture of the scope and let you assess fit accurately before proceeding. We are looking for someone senior enough to own implementation details, identify technical risks, and build production-grade workflows — and comfortable working from a detailed architecture rather than redesigning the system from scratch. This system will handle sensitive legal and medical client data. Confidentiality, security discipline, careful logging, and professional judgment are non-negotiable. If you have built production automation systems and can work from a detailed technical specification, we want to hear from you.