ProcLeg Procurement and Legal AI Assistant

Problem

What this project is solving

Legal and procurement teams spend significant time moving across approved knowledge sources, templates, supplier data, RFP history, uploaded files, and internal process guidance. The problem is not only answering questions; users need guided workflows that help them draft agreements, create RFPs, analyze suppliers, review proposals, and generate downloadable business documents without restarting context every turn.

Positioning

From question to completed business workflow

ProcLeg is an enterprise AI copilot for legal and procurement teams. It reduces manual effort, improves consistency, and accelerates document-heavy workflows by turning approved internal knowledge, templates, supplier data, and historical documents into guided AI workflows.

Core Workflow

How the platform moves users through work

Case Study

System Overview

ProcLeg is organized across three main codebases: a UI app for chat and navigation, a FastAPI backend exposing REST/SSE endpoints, and a core library containing domain models, application services, agents, persistence, document generation, retrieval, and infrastructure integrations.

• rdu-ai-genio-legal-assistant-ui for chat, uploads, history, help, and module navigation
• rdu-ai-genio-legal-assistant-api for FastAPI REST and streaming endpoints
• rdu-ai-genio-legal-assistant-lib for domain, application, agents, repositories, and integrations
• Legal / Ally module for legal Q&A and HCP agreement generation
• Procurement module for Q&A, RFP creation, supplier intelligence, proposal scoring, and SoW review

Case Study

Layered Architecture

The project follows a hexagonal / ports-and-adapters style. Domain models and interfaces stay independent from DSPy, LangGraph, AWS, SQL, or FastAPI. Application services orchestrate workflows, while infrastructure adapters handle persistence, retrieval, document generation, and cloud integrations.

• Domain layer defines conversation models, request/response models, workflow state, agent interfaces, repository interfaces, and document contracts
• Application layer orchestrates LegalQAService and ProcurementService workflows
• Infrastructure layer connects to DynamoDB, S3, Postgres/RDS, Bedrock Knowledge Base, Azure OpenAI, and document generation utilities
• Shared agent interfaces allow multiple frameworks such as DSPy and LangGraph to coexist cleanly

Case Study

Legal Q&A Module

The legal Q&A path uses a DSPy multi-hop RAG agent to answer legal, compliance, and policy questions from approved internal knowledge sources. Responses are constrained to retrieved context and include answer, sources, limitations, confidence assessment, and follow-up questions.

• Intent and entity extraction before retrieval
• First-hop and second-hop retrieval from AWS Bedrock Knowledge Base
• Scenario analysis and step extraction before final response generation
• Grounded answer generation through the generic AgentBase interface

Case Study

HCP Agreement Generation

The HCP path is a guided document-generation workflow. The system detects agreement creation intent, extracts country, looks up the right template, analyzes placeholders and choices, collects required values over multiple turns, previews drafts, supports refinement, generates DOCX output, uploads it to S3, and returns a download URL.

• HCPGenerationService controls the state machine
• LLMDocumentGenerator handles country extraction, placeholder analysis, field extraction, workflow action detection, refinement detection, rephrasing, and translation
• RDSTemplateRepository finds templates through RDS and S3
• docx_merge.py fills DOCX templates deterministically

Case Study

Procurement Multi-Agent System

The procurement module uses LangGraph as a multi-agent workflow system. A supervisor routes each query to one specialized node, allowing the platform to support procurement Q&A, RFP drafting, supplier intelligence, vendor proposal assessment, and SoW review through a single conversational experience.

• Procurement Q&A node rewrites follow-ups into standalone retrieval queries and retrieves knowledge from Bedrock KB
• RFP creation node reads templates and guidance from S3, accepts uploaded files, uses historical RFP metadata, and generates DOCX output
• Supplier intelligence node queries Postgres supplier tables through guarded safe SQL tooling
• Vendor / SoW scoring node analyzes uploaded proposals or statements of work using internal guidance and Azure OpenAI

Case Study

Persistence and Integrations

ProcLeg uses a split persistence strategy based on data shape and access pattern. DynamoDB handles conversation metadata and module state, S3 handles large chat payloads and documents, and Postgres/RDS stores prompt repositories, supplier data, file metadata, HCP template lookup, historical RFP metadata, and ETL job state.

• DynamoDB for conversation metadata, message history references, and module state
• S3 for uploaded/generated documents, templates, guidance files, metadata JSON files, and large payloads
• Postgres/RDS for prompts, supplier intelligence, file metadata, templates, historical RFP metadata, and ETL audit records
• LangGraph memory saver and Postgres checkpointing for graph and sub-agent continuity

Case Study

ETL v4 Ingestion and Knowledge Sync

ETL v4 is the ingestion and synchronization backbone of ProcLeg. It keeps legal and procurement knowledge sources current by syncing curated SharePoint document libraries into S3, exporting metadata tags, converting files to PDF when needed, triggering Bedrock Knowledge Base syncs, and loading supplier intelligence data into RDS.

• Discovers files recursively from configured SharePoint sites, drives, and folders
• Writes discovered file metadata into Postgres with source URI, site ID, drive ID, item ID, path, content hash, size, tags, geography, descriptions, and source modified time
• Uses content hash comparison to detect new, updated, unchanged, re-discovered, and deleted files incrementally
• Handles deletion using both source URI and drive/item ID comparison to reduce false deletion events
• Uploads source files, converted PDFs, metadata JSON files, legal templates, procurement reference files, and ETL run logs to S3
• Triggers Legal and Procurement Bedrock Knowledge Base syncs only after upload/delete jobs complete successfully

Case Study

ETL Job Orchestration and Auditability

File processing is handled asynchronously through Celery workers. Each task is persisted before execution, giving the system task-level traceability, batch-level job IDs, retry counts, Celery task IDs, payload history, result history, errors, and timestamps.

• Celery tasks include upload_to_s3_kb, delete_from_s3, and dump_tags_to_s3 style operations
• file_metadata acts as the source-of-truth catalog for discovered enterprise files and per-task processing state
• etl_jobs_v4 records project ID, file metadata ID, batch job ID, task type, status, redacted payload, result, error message, execution metadata, retry count, and timestamps
• Retry and recovery APIs support worker checks, job submission, polling, failed-task retry, and cleanup
• Retries re-inject SharePoint credentials because persisted payloads intentionally redact secrets

Case Study

Supplier Intelligence ETL

Procurement has a dedicated supplier intelligence ingestion path. ETL v4 scans procurement Excel files from S3, parses supplier profile data, and upserts structured records into RDS tables that are later used by the Supplier Intelligence agent through guarded SQL access.

• Parses supplier profile data from procurement Excel files in S3
• Populates supplier_info, capabilities_map, therapeutic_areas, local_presence, and roles_and_rates tables
• Supports supplier questions such as capability, geography, therapeutic area, local presence, and role/rate analysis
• Keeps supplier data separate from document retrieval so structured supplier intelligence can be queried deterministically

Case Study

Observability, LangSmith, and Evaluation

ProcLeg separates operational observability from AI observability. ETL v4 tracks jobs, files, retries, failures, and durable run logs through RDS, S3, Celery, and structured logging, while LangSmith is used across chat and agent workflows for LLM and agent traces.

• ETL v4 uses structured Loguru logging, run-scoped logs, Celery status polling, RDS job tables, file-level status columns, retry summaries, and S3-uploaded run logs
• LangSmith traces chat and agent execution through traceable/OpenInference utilities in the AI application layer
• A traceable chain can connect SharePoint document, file_metadata row, ETL job, S3 object, Bedrock KB sync, user question, LangSmith trace, answer, and sources
• LLM-as-judge evaluation can run after ingestion to assess groundedness, citation correctness, retrieval relevance, completeness, hallucination risk, policy compliance, document version usage, and metadata filtering
• Feedback reports can summarize discovered files, new/updated/deleted files, S3 uploads, PDF conversions, metadata JSON uploads, KB sync status, failed files, retries, supplier rows, judge scores, failed queries, and recommendations

Case Study

Prompt and LLM Management

Prompts are loaded dynamically from Postgres where possible, allowing behavior to be tuned without redeploying code. The system uses Azure OpenAI through the enterprise gateway, LiteLLM for async completions in workflow utilities, LangChain AzureChatOpenAI for procurement nodes, DSPy LM wrappers for legal Q&A, and AWS Bedrock Knowledge Base for retrieval.

• Runtime prompt tuning for procurement Q&A, supervisor routing, supplier intelligence, proposal assessment, HCP extraction, and legal intent classification
• Structured service boundaries keep model usage behind workflow-aware application logic
• Retrieval is grounded in approved internal sources instead of unbounded model memory

Case Study

End-to-End User Journeys

The system is designed around completing work, not just answering questions. Users can ask legal questions, generate HCP agreements, create RFP documents, query supplier intelligence, or assess proposals while the platform preserves conversation and workflow state across turns.

• Legal Q&A: ask a policy question, retrieve approved guidance, generate grounded answer, persist conversation
• HCP agreement: detect country and template, collect fields, preview draft, refine values, generate DOCX, return download URL
• Procurement RFP: route to RFP node, use templates/guidance/uploads/history, draft RFP, generate downloadable document
• Supplier intelligence: safely query supplier tables and refine raw SQL-agent output into readable answers