⚖

Clerk of the Circuit Court — Technology Notes

caernarvon.net

Building Helper Apps for the Clerk of Court

Small, focused, container-based tools that make day-to-day Clerk of Court work — document review, case audits, records handling — faster and more consistent, without the overhead of a monolithic case management system.

Why these apps exist

Purpose-built tools, not another giant system

Clerk of Court offices already run large case management systems. What's often missing are small, well-scoped tools for specific recurring tasks — redacting sensitive information from a scanned filing, auditing a batch of guardianship cases, tracking who reviewed what and when. This site collects a few of those helper apps, built as independent, containerized services rather than bolted onto an existing platform. Each one is scoped to a single job, deployable on its own, and disposable if it stops being useful.

Live examples

Apps running on this domain

The Redaction Reviewer and Guardianship Audit below are early-stage prototypes running on synthetic, made-up case data — not real court records — while the workflows and access controls are being worked out. Probate Guardian is a standalone client-side tool with no backend of its own, so it isn't part of that same synthetic-data staging process.

Prototype · Synthetic data

Redaction Reviewer

Walks a reviewer through a filing before it goes on the public record, applying different redaction standards depending on case type — standard financial-identifier redaction, or a heightened standard for sexual-offense and child-abuse cases. Includes an admin panel for managing reviewers and the underlying redaction rule sets.

Frontend: Azure Static Web Apps  •  API: FastAPI on Azure Container Apps  •  Auth: Microsoft Entra ID

Open app.caernarvon.net →
Prototype · Synthetic data

Guardianship Audit

A workflow tool for auditing guardianship case files: creating audits, assigning them to reviewers, uploading supporting documents, and tracking status — including take-over and unlock actions when an audit needs to be reassigned. Every view and status change is logged for accountability.

Frontend: Azure Static Web Apps  •  API: FastAPI on Azure Container Apps  •  Auth: Microsoft Entra ID

Open gaapp.caernarvon.net →
Standalone · Runs offline

Probate Guardian

A guardianship accounting and reporting tool that runs entirely in the browser — no backend, no account, no data ever leaving the device. Walks a guardian through initial inventories, annual accountings, and guardianship plans, then exports directly to the Clerk's official PDF and Excel forms. Case data is stored locally, optionally behind AES-256 password encryption.

Client-side only  •  Installable PWA  •  Local encrypted storage, no server

Open Probate Guardian →

Development

How these apps get built

Each helper app is two small services — a browser frontend and a backend API — both packaged as Docker containers from day one, even during local development, so "it works on my machine" also means "it works in the cloud." Probate Guardian is the exception: it's a single static, client-side app with no backend or API of its own, so it skips the container/auth pipeline below entirely and ships as plain files.

1

Scope narrowly

One app, one job — e.g. "review and redact a filing," not "manage every case."

2

Build in containers

API and frontend each get a Dockerfile; a docker-compose file runs the whole stack locally.

3

Use synthetic data

Development and demo environments run on fake case data — never real filings.

4

Layer in auth

Single sign-on (Entra ID / OIDC) is added early, not bolted on before launch.

Testing

Testing before anything touches real records

Because these tools eventually sit near sensitive court records, testing leans conservative:

1

Unit tests

Redaction rules, audit-state transitions, and permission checks are tested in isolation.

2

Integration tests

The containerized API and a test database run together in CI, exercising real HTTP calls.

3

Container scanning

Every image is scanned for known vulnerabilities before it's allowed to deploy.

4

Staging with fake data

A staging deployment, identical to production, runs on synthetic cases for sign-off.

Deployment

Container-based deployment, cloud-agnostic by design

Because everything ships as a Docker container, the same image can run on any major cloud with only configuration changes — no rewrite. The apps above currently run on Azure; the table shows the equivalent building blocks on AWS and Google Cloud if a future app needs to land elsewhere. Probate Guardian isn't part of this table — as a static client-side app it's just files served alongside this site, with nothing to containerize or run server-side.

Building block Microsoft Azure Amazon Web Services Google Cloud
Run the container Azure Container Apps ECS on Fargate / App Runner Cloud Run
Host the static frontend Azure Static Web Apps Amplify Hosting / S3 + CloudFront Firebase Hosting / Cloud Storage + CDN
Store container images Azure Container Registry Elastic Container Registry (ECR) Artifact Registry
Sign-in / identity Microsoft Entra ID Amazon Cognito Identity Platform
App database Azure Database for PostgreSQL RDS for PostgreSQL / Aurora Cloud SQL for PostgreSQL
Secrets Azure Key Vault Secrets Manager Secret Manager
CI/CD pipeline GitHub Actions → ACR → Container Apps GitHub Actions → ECR → ECS/App Runner GitHub Actions → Artifact Registry → Cloud Run
In practice, a release means: build the Docker image in CI, run the automated test suite against it, push the image to the cloud's container registry, then point the container service at the new image tag. Rolling the app back is just pointing the service at the previous tag — no server to patch, no manual redeploy steps.