AssessIQ Counsel — Prototype

County calibration rules

Every county's math is different — Ohio runs a statutory 35% ratio calibrated on Board of Revision (BOR) outcomes, Pennsylvania runs per-county common level ratios that move annually, Illinois runs township multipliers. The rules are data, visible here, and editable with a name attached: an edit is recorded with full provenance and applied at the next onboarding build, never silently mid-cycle.

Valuation — first pass

A median of a few decided cases is triage, not an opinion of value: it ranks which parcels deserve an appraisal first, and the pools deepen as the firm's own decided outcomes are imported.

confidence: high = grounded in the parcel's own financials · medium = calibration pool of 4+ decided cases · low = smaller pool

Case Builder

Draft appeal cases assembled from the county record — one per parcel where the first-pass delta is material. On the resident build, a detected change regenerates the affected parcel's draft automatically; each draft cites the parcel record, its own case docket, and the calibration outcomes.

Appeals Library

Every Board of Revision case across the watch-list, from the county's own case system. The decided owner-side outcomes here ARE the calibration pool behind the first-pass values; school-board increase complaints are tracked separately as increase risk (see the "Filed by" column). Filed paperwork opens in-app.

Import firm documents

Drop an appraisal, complaint, decision letter, or evidence packet. The same deterministic extractor that processed the county's BOR paperwork reads it locally — nothing leaves the machine. The system proposes a parcel; nothing attaches until you confirm, and nothing touches the book until an analyst approves.

Samples to try the flow (all clearly synthetic): appraisal ↗ · decision letter ↗ · income & expense statement ↗

Calibration model

The learning loop: approved decision letters extend the per-bucket calibration pools. Extensions are recorded immediately; the book's first-pass values only move through the explicit, named recompute below.

Document library

Every uploaded document with the fields it produced and where each field came from.

Onboard the book — clients anonymized at the door

The split happens the moment the book enters: each client+parcel pair is separated into an opaque reference and a key. The tool keeps only parcels and references, on your own servers. AssessIQ never receives any of it: not the names, not the nicknames, not even which parcels are on the book. The key linking references back to clients exists once, in the response handed to you below — download it, it is yours, it is never stored. Not a promise not to look: there is nothing on the tool's side that can name a client.

Worked example synthetic names, nothing stored

A static illustration — no upload, no server call. These names and refs never touch the tool; they're here so the split above reads as concrete before you paste your own book.

Onboarded parcels

What stays on your servers: parcel, county, reference. No names, because none were kept, and none of this reaches AssessIQ.

History

The audit trail: county scans and detected changes, firm uploads, parcel confirmations, and analyst approvals, newest first. A read-only view over the underlying records — nothing here can be edited, which is the point.

Alerts Phase 2 design

Detection without notification is a change nobody saw. Phase 2 delivers the alert layer, entirely inside the firm's network: a daily digest per domain owner (deadlines to Julie's queue, national-group changes to Brendan's), urgency tiers keyed to the days remaining on each window, and an escalation rule when a watched parcel's value moves inside an open filing window. Every alert links back to this History feed — the alert is a pointer to the record, never a copy of the data.