Protective order software should fail closed

Filing for a protective order in Texas is hard, and it is hard even for people who work in this field and understand the system. The paperwork asks you to be exact about the most frightening parts of your life at the moment exactness is most out of reach. It is not a single form. It is a chain of decisions where an early shortcut can create real risk later, and the steps that come after filing are a maze of their own. None of this is news to anyone who has spent time around these cases. What stayed with me was the mismatch. The stakes could not be higher, and most of the tooling treated the whole thing as generic document work.

Protectly is an independent Prosocial Coding LLC project, separate from my day job, and it is what I built to close that gap. It is a working system that I have built and am still hardening, and it is not yet a live filing service. This article is the story of what it is, how it is built, and where it is going.

The stakes are also why the whole thing is built to fail closed. When software handles information that can expose someone's location, identity, history, and risk, the default cannot be to do the convenient thing and hope. It has to be to stop. So the rule I designed around is simple: whenever convenience conflicts with privacy or safety, convenience loses. That single decision shaped almost every part of the architecture, and most of what follows is that principle made concrete.

What it does

Protectly is a React, Vite, TypeScript, and FastAPI application for Texas protective order materials. It uses Firebase for auth and storage, Google Gemini through a backend proxy, Google Maps for geocoding, and standard libraries for PDF and Word export. The person using it does not start with a blank page. The app walks them through a guided intake, step by step: who they are, who they are filing against, the relationship, who needs protection, what happened, and what they are asking the court to prohibit, and so on through firearms, temporary orders, the affidavit, review, and e-filing prep. The structure is the point. It keeps the key facts organized instead of buried in one long narrative that a court then has to untangle.

Who it is for

I designed for two people. The first is a self-represented Texas filer trying to put together protective order materials without having to understand every form concept at once. The second is an advocate or a lawyer reviewing a case before it is filed. The code reflects that split. The public side is the survivor intake. The professional side is an Advocate Workbench with assigned cases, review steps, an approval status, and a confirm-and-file action, plus an admin path for managing users and activity. That separation matters. The serious judgment in these cases belongs with people trained for it, so the tool routes case review and the final filing action to advocates and lawyers rather than leaving them to a first-time filer alone.

The tool does a few concrete things. It keeps intake structured. It maps the application into an ECF envelope for e-filing workflows. It can generate documents, safety planning content, stalking packets, plain summaries, ex parte justification language, and suggestions for which prohibitions to request. It can run a court simulator so someone can practice answering questions before they are in front of a judge for real. Every one of those AI features is an optional assistant, not the authority. The source of truth stays the structured form data and the human review around it. The model helps with language and organization. It does not decide anything that matters.

The safety work

This is where I was most careful, and it took the real design effort, so it is the part to walk through.

Protectly validates data at several layers. The TypeScript schema defines the shape of an application, the required fields for each person, incidents, protected persons, prohibitions, confidentiality requests, and the venue basis. The FastAPI backend adds its own checks for names, dates of birth, physical identifiers, contact details, document size, county information, and the e-filing payload. The advocate filing path checks the TCIC fields, the criminal-history information the state requires, before it will let anyone confirm a filing.

The AI path is fenced off from raw sensitive data on purpose. Before any application content goes toward Gemini, a privacy pipeline redacts it. It builds a token dictionary for names, addresses, dates of birth, emails, phone numbers, zip codes, license numbers, and Social Security fields, and it catches unknown identifiers with pattern matching as a backstop. After the model responds, the system swaps the real values back in locally. The model works on structure and language and never sees the identifiers it does not need.

There is a second stop gate behind that. Free-text prompts that look like they contain sensitive personal information are blocked before they reach the model at all. A moderation step checks for prompt injection, adversarial intent, and PII, and the default is closed: if moderation fails, the request does not go through. The system strips common injection phrases and caps input length. Generated output is validated before it is used anywhere. HTML with script tags or event handlers is rejected outright. Ex parte justification text has to reference danger or harm or a threat to safety, and it is rejected if it suggests confrontation or weapons. Structured output is checked against schemas with safe fallbacks.

Storage is treated as a risk boundary, not a convenience. Draft data is encrypted by default, and the app refuses to save protective-order data at all if encryption is turned off or the key is missing. It uses AES-GCM through the Web Crypto API, with non-extractable keys for device encryption and passphrase-derived keys for the rest. Cloud sync only ever stores encrypted payloads, with identity checks on the backend and hashed user IDs in the logs. The project keeps a zero-tracking posture: no analytics, and vendor keys stay on the backend rather than in the browser.

Filing itself is deliberately gated. The app has dry-run and submit endpoints, and the repository is explicit about what is proven and what is not. Simulation mode is the default and returns mock envelopes. Live filing requires real Tyler credentials and external verification, and the code will not pretend a live filing happened when it did not. The advocate path is two steps, submit for review and then confirm and file, and once a case is filed the system locks it into that state. None of that is exciting to build. All of it is the difference between a tool that is careful and a tool that looks careful.

What it does not prove

Pretending the work is finished would violate the entire premise of the thing, so here is what is not done. Protectly has not yet been through production filing with Tyler, formal legal review, an environment certification, independent penetration testing, or a formal AI safety evaluation. Those are real pieces of work. They are also known, scoped pieces of work, and I built the system from the start to expect them, so none of it means tearing down what already works. The foundation that is hard to build well, a protective order system designed to fail closed by someone who understands the domain, is the part that exists today. The remaining path is defined.

The next priorities are survivor-informed UX testing, an accessibility review, Spanish-language support, external legal review, a written incident-response process, clearer data-retention controls, and independent security and AI safety testing before any broad public launch.

My hope for Protectly is simple. I want it finished and in the hands of the people who need it, completed to the standard the stakes deserve, by whoever is best placed to do that work well. Software in this space should never tell someone they are safe when they are not. It should never invent a legal fact. It should never rush a filing because a button exists. The goal was always narrower and more useful than "an app for protective orders." Organize the record, protect the data, show the next step, and leave room for human judgment everywhere the stakes demand it. That is what is built, and I would like to see it through.