A signed contract waited six months to go live.
Most of that time went on retyping PDF forms.

The quick version of this is one prompt that turns a PDF into configuration. We built a pipeline combining Amazon Textract and Amazon Bedrock instead, with a separate job for each stage, so each stage can be checked on its own:

• Extract the source content. Textract reads the text and form content from PDFs. The pipeline accepts PDF and web forms as the starting point.
• Map fields to the product. The pipeline identifies text inputs, dates, radio buttons and signatures, and writes them in the JSON schema the existing form builder already expects.
• Carry the rules through. Bedrock reads the annotations and surrounding text to infer required conditions, field dependencies and conditional branches, and those rules go into the generated JSON alongside the fields.
• Generate the starter workflow. The same metadata and field logic produce a checklist, so the form and its first workflow configuration come out together. Two manual steps that used to run one after the other become one pass.

Writing into the product's own JSON schema means the output lands in the tool the team already uses.

Generated configuration for a government workflow can't go live on a model's say-so. The implementation team checks the generated schema against the source document and the customer's operating rules, in a Streamlit admin interface:

• A reviewer can inspect the JSON, edit individual fields and approve the configuration before it goes live.
• The system records what it generated and what a person then changed, which shows exactly which parts of the output still need a person.
• Amazon DynamoDB holds JSON states and mapping templates, and AWS Lambda coordinates processing.

In validation, 80–90% of the form-onboarding effort was automated. The remaining 10–20% is the edit-and-approve step, kept on purpose so a person signs off every output. The validation covered form extraction, JSON generation and human editing and approval. A full customer implementation will measure how long a whole rollout takes, and what it costs.

For the data, we built conversational analytics over what the platform already held. A member of staff types a question in plain English, gets the result and can inspect the records behind it.

A model can't write accurate SQL for a schema it hasn't seen, and guessing column names is where text-to-SQL goes wrong. So the pipeline starts from the database itself:

• Establish the schema. A dictionary extractor inspects each tenant database and produces sanitized YAML with table names, column names and business descriptions.
• Retrieve the relevant definitions. Amazon OpenSearch supplies the schema context for each question, so the model works from actual database definitions.
• Generate the query. Amazon Nova Pro and Claude 3.5 Sonnet, through Amazon Bedrock, handle natural-language-to-SQL generation and result summarization. Generated queries are parameterized.
• Validate before execution. A separate step checks the generated SQL against access restrictions and execution limits.
• Run and explain the result. Amazon Athena queries the data in Amazon S3, and the interface returns the results with charts and a plain-language summary.

LangChain handles LLM orchestration and conversation memory. React and AWS Amplify connect it to the portal.

Telling the model to write only safe queries isn't enough, because a model can ignore an instruction, so the execution layer enforces the rules on its own, whatever the model produces:

• Read-only queries are allowed, and DDL and DML operations are blocked.
• User roles map to permitted data sources, with IAM Identity Center and Amazon Cognito handling sign-on and role mapping.
• Row limits bound how much data comes back.
• A 10-second timeout bounds execution.
• Amazon API Gateway is the query sandbox's entry point.

Repeated identical queries can come back from an Amazon ElastiCache Redis cache for 30 minutes, which cuts repeat processing and model cost, with cached answers subject to that freshness window. CloudWatch logs every query and result, and sensitive columns can be redacted or hashed according to role.

Why: an instruction in a prompt can be ignored, so the limits that protect the data live where the query runs.

Compliance risks don't go away after one answer. They come back as new records arrive. So we added a rule builder that turns any query into a scheduled monitor:

• Amazon EventBridge triggers the checks.
• Amazon SNS and configured Slack or email channels deliver an alert when a condition matches.
• The alert includes the rows that triggered it, so the team has records to investigate rather than a number.
• Ten pre-built templates cover high-risk billing scenarios, including overlapping visits, unrealistic travel distances and duplicate billing codes (CPT codes) on the same day.

The platform handles protected health information for government clients, so the deployment was designed around that:

• Processing stays inside the customer's AWS account under a HIPAA business associate agreement (BAA), with encryption at rest and in transit.
• Source documents in S3 have a 72-hour retention window, after which they're purged.
• Role-based access and query audit records go with the analytics workflow.

The deployment design puts Amazon ECS and Fargate application containers in private subnets across two Availability Zones, behind a load balancer, with Amazon OpenSearch in a private subnet too and Auto Scaling on the application tier. GitHub connects to AWS CodePipeline, with AWS CodeBuild, Amazon Elastic Container Registry and AWS CodeDeploy handling build, image and deployment. Terraform defines the infrastructure.