- Local firstNo cloud requirement, no telemetry, no per-seat pricing. Records stay on the city's machine.
- One useful systemA single MSI installs Core, Records, Notice, Access, and the local runtime together. No Docker, WSL, terminal, or per-module shopping.
- Honest about statusThe candidate is not published until unsigned lifecycle, merge, signing, and signed clean-machine evidence all pass.
Status · 2026-08-20
Where the project is today
Current build: Townlight Records 1.1.0-beta.1 release candidate · not yet published.
What "release candidate" means. Product behavior is under final integration. The combined MSI must still pass its unsigned lifecycle, merge to main, sign as CN=Scott Converse, and pass the full signed clean-machine Records journey before Scott decides whether to publish it.
The Records product profile
Four capabilities, one public-records system
The installer ships the complete Records outcome, not an isolated module. Fresh setup selects Core, Records, Notice, and Access. Meetings and Code stay in the catalog for later releases.
Shared platform: identity, audit, retention, the local task queue/worker, and document ingestion. Every module depends on it; it depends on none.
Public-records / FOIA request intake, search, and AI-assisted response drafting.
Public-notice creation and publishing workflow.
Accessibility workflows and records-ready export: plain-language rewrites, translations, and WCAG review support.
Townlight Meetings and Townlight Code are subsequent headline releases and are not installed by the Records beta profile. The wider catalog remains roadmap work, not a current product claim.
The first public product
A complete request-to-release journey
Townlight Records is organized around the outcome a municipality needs, with Notice and Access included as supporting capabilities rather than sold as isolated tools.
Intake and deadlines
Receive a trackable request, calculate its deadline, preserve the basis, assign it, and keep a tamper-evident timeline.
Cited search and review
Record searched locations and exact citations, then save a human exemption decision with its source and basis.
Approved public release
Review accessibility, require human approval, build and export the release package, fulfill the request, and expose only the public projection.
Humans decide. Townlight does not auto-deny, auto-redact, or publish an AI draft. Deterministic checks and optional local drafting support the operator; a named human records the legal/exemption decision and explicitly approves the response before release.
Two ways to read this
For the people who run it
For clerks & decision-makers
Townlight installs the way a Windows program does, then runs on that computer. No hosted account, no monthly subscription, and no required vendor cloud.
- Your data stays yours. Records, minutes, notices, and requests live on your own computer — no cloud service to go dark, change price, or be subpoenaed out from under you.
- No recurring bill. No per-seat licensing and no per-user fees; it runs on hardware you already own.
- Works offline after setup. The local model is explicitly downloaded and checksum-verified during setup — not called through a paid API — so day-to-day work can continue without internet.
- AI that stays in its lane. It drafts and suggests; a person always reviews and decides.
Recommended hardware: 32 GB of RAM (16 GB is a workable minimum), about 15 GB free disk, and 64-bit Windows 10 or 11 with WebView2. Most office desktops bought in the last few years qualify.
For IT & technical evaluators
A single Tauri/WebView2 desktop app that bundles its full runtime — no external service dependency, no container runtime, no developer tooling on the target machine. Everything runs as local processes supervised by the shell.
- Database: portable PostgreSQL 17 with
pgvector— fully bundled; first-run setup completes on a factory-fresh Windows PC with no prerequisites. - Services: embedded CPython city services with a PostgreSQL-backed local task queue and worker (the Windows-local profile, replacing the server-profile Redis/Celery stack).
- Local AI: Ollama serving a pinned local Gemma model, registered through an explicit download / checksum / runtime step on first run — on-device inference, no API.
- Trust path: verify the published MSI SHA-256, exact module commit pins, Authenticode status, timestamp, and signer
CN=Scott Converse(provenance, signing policy).
Architecture
Everything runs on one machine
- 1. Townlight desktopTauri and WebView2 provide the user interface and the current Records domain path.
- 2. Supervised local runtimesThe desktop starts and monitors embedded CPython, PostgreSQL, and the local task queue.
- 3. Versioned local persistenceRecords state has an explicit schema version and verified backup/rollback behavior.
- 4. Optional local AIOllama serves a pinned Gemma model that is explicitly downloaded and SHA-verified.
Where to go next