Inside the Engine

Public accountability does not happen by magic. It happens by movement.

Seattle A.R.E. is not a dashboard glued to a spreadsheet. It is a working accountability engine built from specialized parts designed to collect, verify, classify, package, audit, and measure public enforcement records with precision and traceability.

"Together, these systems form the A.R.E. Movement: the internal mechanism STLCA built to transform fragmented public records into structured, auditable accountability data."

Every module
has a job
·
Every run
has rules
·
Every field
has provenance
·
Every output
must survive QA

Eight modules. One movement.

Each module is a specialized component of the accountability pipeline. Together they create a reproducible public evidence system with no silent failures and no uninspected outputs.

🚗
The Driver
Orchestration and execution control

The Driver initiates extraction runs, controls execution order, manages district sequencing, and ensures the system follows locked operational rules from start to finish.

Without the Driver, the movement does not begin.

🌾
The Harvester
Public record collection and extraction

The Harvester enters the public portal, retrieves complaint records, downloads attachments, accesses related enforcement data, and gathers the raw evidence required to reconstruct accountability outcomes.

This is where fragmented public records become recoverable.

🔒
The Gatekeeper
Validation and structural integrity

The Gatekeeper rejects malformed records, invalid structures, duplicate rows, and schema violations before they contaminate downstream outputs.

Dirty data does not pass. Failed runs stop here.

📡
The Signal
Pattern recognition and accountability analysis

The Signal identifies relationships, enforcement patterns, concern flags, inspection visibility gaps, and measurable indicators that help explain how systems behave over time.

This is where records begin to speak.

📒
The Ledger
Structured accountability reporting

The Ledger converts extracted records into searchable datasets, public review tables, district summaries, and accountability-ready reporting structures.

This is where evidence becomes navigable.

🔍
The Auditor
QA enforcement and manifest verification

The Auditor validates counts, uniqueness, district metrics, manifests, extraction integrity, and output consistency.

If the evidence cannot survive audit, it does not become public release data. Trust is the product.

The Dispatch
Batch movement and hard-stop enforcement

The Dispatch controls run sequencing, district movement, fail states, and execution boundaries. No fix-forward patching. No silent corrections. No partial-release improvisation.

The movement either passes or stops.

⚖️
The Reckoning
Enforcement exposure and accountability calculation

The Reckoning calculates NOV duration, enforcement exposure, fee gaps, unresolved timelines, and measurable accountability indicators tied to enforcement outcomes.

This is where measurable public consequence becomes visible.

If the public record does not show it, the dataset does not pretend it exists.

Every field inside the Accountability Record Engine must trace back to a public source category. No invented dates. No guessed outcomes. No undocumented assumptions.

Only traceable public accountability data.

  • Portal records
  • Timeline / status history
  • Related enforcement records
  • Public attachments and PDFs
  • Findings text
  • Run manifests
  • Documented absence from the public record

Fields without a verifiable source are left empty and tagged as absent — not estimated.

Locked operational rules

The pipeline follows strict rules with zero tolerance for deviation. Hard-stop QA enforcement is intentional — if integrity fails, the run fails.

  • One final pipeline version across all districts
  • One record_number = one output row
  • No duplicate JSONL rows
  • No manual patching
  • Stop immediately on QA failure
  • Fresh run folder per execution
  • No reuse of partial outputs
  • No packaging failed runs
  • No fix-forward patching
  • No silent corrections

Platform File Manifest

The A.R.E. codebase is organized into a city-agnostic architecture, allowing deployment across multiple cities without rebuilding core infrastructure.

File Source Status
config.py New — city abstraction layer ✓ Complete
extractor.py Refactored — city-agnostic ✓ City-agnostic
classifier.py Copied from production ✓ No changes needed
aggregator.py Updated — uses config ✓ Uses config
schema.py Copied from production ✓ No changes needed
run_extraction.py Updated — --city flag added ✓ --city flag added
run_requests_extraction.py Updated — --city flag added ✓ --city flag added
summarize_district_complaint_metrics.py Copied from production version ✓ Complete
STRICT_PARSING_RULES.md Copied from production ✓ Complete
setup.py New — bootstrap script for new cities ✓ Complete
README.md New — city-agnostic documentation ✓ Complete
requirements.txt Copied from production ✓ Complete

Seattle has dashboards. What it has been missing is a reliable public accountability record.

Seattle has no shortage of housing policy, dashboards, programs, task forces, ordinances, or public statements. What has been missing is a reliable public accountability record capable of measuring what happened after a complaint entered the system.

Seattle A.R.E. was built to help close that gap — not by replacing City records, but by making them measurable.

"Public records should produce public accountability."

— STLCA

STLCA created Seattle A.R.E. as a public accountability infrastructure framework designed to help researchers, policymakers, journalists, advocates, and the public evaluate housing and code enforcement systems using documented outcomes, inspection visibility, enforcement records, and measurable evidence.

View Dataset Dashboard Read Methodology