psd401/psd401-prr

Custom-built Public Records Act request management for Peninsula School
District No. 401 (WA), replacing commercial tools like NextRequest/GovQA.
Governing law: RCW 42.56 (Washington PRA) and FERPA. Compliance is
the product: deadline math, exemption handling, and the audit trail are
legal artifacts, so they live in code where they can be enforced at the
database level and proven by tests.
Owner: Kris Hagel (@krishagel), CIO. Tier A (production) under the
district's development standards.
Status (verified 2026-08-02): Phase 1, the React staff workspace, direct
Google Workspace OIDC, group-mapped staff roles, the staff/agent API, and both
MCP transports are implemented. Hosted /mcp adds exactly five personal-token
draft/proposal tools; standalone stdio and the dedicated nonstaff MCP identity
remain read-only. Durable requester correspondence now owns drafting, approval,
queueing, delivery evidence, reconciliation, inbound MIME/DSN matching, and the
day-5 safety net. Outbound correspondence sends in-process through a lease-safe
Celery Gmail worker, and the disabled-by-default in-process Gmail poller feeds
replies into the same durable inbound pipeline. The former integration-specific
HTTP intake and correspondence routes and their tokens have been removed.
The anonymous, write-only public intake API accepts the complete legacy
requester-information set and malware-scanned file attachments through the
compliance pipeline. Least-privilege staff intake logs phone, paper, and
in-person requests through that same path. Phase 2 is implemented in the
repository: integrity storage and scoped releases, resumable Vault ingest,
human review/redaction and raster burn-in, exemption/production packages,
JLARC reporting, governed fees, safe migration, advisory AI, and accountable
no-records closure. Production credentials, approvals, representative-data
rehearsals, and cutover remain explicit external handoffs. See
docs/project-status.md for the kickoff
ledger and docs/development.md for the current developer
starting point.
## Why a custom build
The 2026 build/buy/FOSS analysis (docs/build-vs-buy.md)
surveyed the commercial market (NextRequest ~$1k–5k/month, GovQA and
FOIAXpress at enterprise pricing) and the FOSS field (ArkCase CE is the only
credible agency-side option, and it is a heavyweight Java/Alfresco stack with
no Google Vault integration). The district's records live in Google
Workspace, its engineering capacity is in-house, and the statutory logic has
to be testable. A purpose-built Django system with FOSS components (OCR,
redaction, storage) won on all three, and the avoided license cost funds the
build.
A general ticketing platform (Freshservice, etc.) can hold a queue, but the
properties below become conventions there: fields someone can skip, rules an
admin can edit. Here they are constraints.
## Compliance guarantees
Enforced by the schema and the test suite, not by policy:
| Guarantee | Mechanism |
| 5-business-day response clock (RCW 42.56.520) | apps/records/deadlines.py: WA holidays (incl. Juneteenth), district closures, after-hours receipt rollover, day-after-receipt counting, clarification tolling. Tested against real calendar dates. |