A Storytelling Interface for Intervention in DV Cases

Inspiration

Domestic violence survivors often face a painful paradox: the evidence of their abuse is everywhere—texts, journal entries, photos, police reports—but scattered and unstructured. This fragmentation erodes credibility and delays justice. We were inspired by the idea that technology can quietly protect. We wanted to build something that looks ordinary, feels safe, but is powerful enough to help survivors tell their stories clearly and securely.

What it does

Our project, A Storytelling Interface for Intervention in Domestic Violence (DV) Cases, provides a discreet chatbot that helps survivors safely record, organize, and transform fragmented evidence—texts, journals, voice notes, and police interactions—into a coherent, evidence-ready narrative. It uses natural language processing to detect patterns, timestamps, and key entities while maintaining user anonymity and encryption at every step. The interface is designed to appear harmless in high-risk environments, prioritizing privacy, safety, and control for survivors seeking legal or advocacy support.

How we built it

We developed a full-stack web application designed as a secure and supportive tool for domestic violence victims.

Frontend: We built the user interface using React, creating separate components for login, registration, the main chat interface, user profiles, and a private journal. We used react-router-dom for navigation and standard fetch API calls to communicate with the backend. Styling was done with CSS to create a supportive and user-friendly theme.

Backend: A Node.js server using Express and TypeScript forms the core of our backend API. It handles user authentication, data storage, and communication with AI services.

Authentication: We implemented a secure user authentication system using bcryptjs for password hashing and JSON Web Tokens (JWT) for managing user sessions. User credentials are stored separately in a dedicated DynamoDB table (ChatbotCredentials).

Database: We chose Amazon DynamoDB, a NoSQL database, for its scalability and flexibility. We designed separate tables for user credentials (ChatbotCredentials), user profiles (UserProfiles), chat history (ChatbotUsers), and journal entries (JournalEntries), ensuring data separation and security. All tables were primarily located in the us-west-1 region.

AI Chatbot & Analysis: The core AI functionality is powered by AWS Bedrock, specifically using the Amazon Titan Text G1 - Express model hosted in the us-west-2 region. The backend communicates with Bedrock via the AWS SDK to generate chat responses and perform analysis on uploaded documents.

File Handling: We used the multer library in the backend to handle file uploads securely, enabling the document analysis feature.

Analytics Pipeline: To enable data visualization in Tableau Cloud, we set up a pipeline using Amazon Athena. An Athena DynamoDB Connector (deployed as an AWS Lambda function via the Serverless Application Repository) allows Athena to query the DynamoDB tables using SQL. AWS Lake Formation manages permissions for this data access, and query results are staged in an S3 bucket.

Visualization: Tableau Cloud connects to Amazon Athena to visualize the data collected in the DynamoDB tables, providing insights into usage patterns or aggregated, anonymized user data.

Challenges we ran into

Building this application involved overcoming several technical hurdles, primarily related to AWS configuration and service integration:

AWS IAM Permissions: Consistently ensuring the correct IAM permissions were granted to the backend user (bedrock-chatbot-user) was a recurring challenge. Errors like "Operation not allowed" or resources not appearing often stemmed from missing permissions for services like Bedrock (bedrock:InvokeModel), Lambda (lambda:ListFunctions), or specific DynamoDB actions, especially after adding new features or tables. We also had to configure permissions within AWS Lake Formation separately to allow Athena and Tableau to access the data catalog.

AWS Region Mismatches: A significant challenge was realizing that AWS Bedrock (using us-west-2) and our DynamoDB tables (us-west-1) were in different regions. This required explicitly configuring the AWS SDK clients in the backend code for each service to target the correct region, rather than relying on a single default region.

Bedrock Model Access Changes: We initially followed the older procedure for requesting model access in Bedrock, only to discover that AWS had recently retired the "Model access" page and switched to automatic enablement. This required adjusting our understanding and focusing troubleshooting on region availability and IAM permissions instead. Errors like "Invalid model identifier" were ultimately traced back to the region mismatch.

DynamoDB & Athena Integration: Setting up the connection between DynamoDB (NoSQL) and Athena (SQL) required deploying the Lambda connector and configuring the data source correctly. Debugging issues where the data source or database didn't appear in Athena or Lake Formation involved verifying successful deployment, checking Glue Data Catalog entries, and ensuring Lake Formation permissions were granted correctly on the database level.

Backend Configuration (Node.js/TypeScript): We encountered several environment-specific issues, such as Node.js module resolution errors (.js extension requirements, ESM vs. CommonJS conflicts) requiring adjustments to tsconfig.json and package.json ("type": "module"), and switching from ts-node-dev to tsx for better ESM support.

Frontend State Management: Ensuring the chat history refreshed correctly after data entry required manually updating the conversation state in DynamoDB at the end of the data entry flow to prevent the chat from appearing to "reset."

CLI and API Syntax: We ran into minor issues with correct command-line syntax (e.g., providing JSON bodies to the AWS CLI invoke-model command) and ensuring API request/response structures matched what each service (Bedrock, DynamoDB, frontend fetch) expected.

Accomplishments that we're proud of

Building a fully functional chatbot prototype that can synthesize fragmented data into structured narratives. Creating a design system centered on safety and invisibility, minimizing the risk of exposure. Implementing an automated summarization workflow that generates clear, evidence-ready reports for advocates. Establishing ethical data-handling guidelines that could serve as a model for trauma-informed AI design. Providing an interface to document events in the form of journal entries for future evidence based advocacy.

What we learned

What's next for A Storytelling Interface for Intervention in DV Cases

Next, we plan to:

Collaborate with advocacy organizations and legal aid networks for field testing and co-design. Expand multimodal input, including voice and image evidence analysis with Amazon Recognition and Transcribe. Deploy a pilot program in partnership with legal clinics to evaluate real-world impact and usability.