County-Level Public Records Acquisition, Normalization & QA Capability

Rather than running fragile, evasive scrapers that trigger Cloudflare anti-bot blocks or violate computer use policies, Chrisian interfaces directly with official county-sanctioned bulk extract channels:

• Direct Court Extraction: Automated, on-demand requests today (daily scheduling is a configuration change, not new engineering) to Harris County's unauthenticated Justice Courts Public Data Extract Service (/PublicExtracts/GetExtractData) capturing civil eviction and debt dockets across all 16 Justice of the Peace courts.
• Pristine Snapshot Landing (Pre-Parsing Integrity): Before parsing or database normalization, the raw upstream payload lands in immutable storage (storage/snapshots/tx_harris_odyssey/YYYY-MM-DD/) and is assigned a cryptographic SHA-256 checksum registered in PostgreSQL alongside byte size and network latency.
• Legal & CFAA Integrity: Sourced under Texas Rule of Judicial Administration 12 from dedicated US infrastructure, with zero residential proxies, zero CAPTCHA bypasses, and zero session impersonation.

Raw court exports are passed through a deterministic normalization engine adhering strictly to Harris County's official file specification (CivilFileSpec.pdf, revised February 24, 2025):

• Party Decomposition (operational): Safely separates "LAST, FIRST MIDDLE" and "FIRST MIDDLE LAST" strings into discrete first, middle, and last fields.
• Financial Precision in Integer Cents (operational): Claim amounts and judgments are stored as integer cents ($1,450.00 → 145000), avoiding floating-point rounding errors.
• Case-Type Classification (operational): Keyword-matches the raw case type into a canonical EVICTION / CIVIL_JUDGMENT / TAX_LIEN record type, and formats dates to ISO 8601 (YYYY-MM-DD).
• Address splitting into street/unit components, and court-code-to-name lookup tables, are not yet built — today the address and court name are carried through as the strings the county extract already provides. Both are straightforward additions once the aggregator's target schema is defined.

Across the operational POC's ingestion of 9,600 filings from Harris County JP Courts:

Why Texas JP Courts Require a Calibrated 0.85 Threshold: Texas Justice Courts do not collect Date of Birth (DOB) or SSNs on civil dockets. Straight-through automation must therefore be strictly governed by exact surname matching, first name string distance, and normalized address components to prevent false positive merges.

Identity matching is a separate, optional layer: source acquisition and 70-column normalization do not depend on entity resolution succeeding. If the aggregator's use case only requires normalized, source-verified court records — not person-level identity clustering — that layer can be omitted entirely, which removes the 6.4% / 93.6% split above as a consideration altogether.

To prevent incorrect merges into downstream credit or identity profiles, the system enforces automated exception routing (status = NEEDS_REVIEW). Two conditions are coded and running today; three more describe scenarios the pipeline does not yet detect, included to show where review logic would extend next:

What is operational today: every sub-threshold match is flagged NEEDS_REVIEW and automatically withheld from the Screening API's reportableRecords response — confirmed live, not an API response fabricated for this brief. What is a proposed design, not yet built: a staffed triage console, a service-level commitment, and a dual-control approval workflow for resolving those flags. The mockup below illustrates the intended design for that console; it does not reflect a tool or a review team operating today.

Proposed, for an agreed engagement — none of this is staffed or running today:

• Dual-Control ("Four-Eyes") Review: High-risk merges involving common surnames without DOB would require counter-approval by a second reviewer.
• Immutable QA Audit Log: Every manual action would log reviewer ID, timestamp, prior state, new state, and a justification code.
• Review SLA: A specific turnaround commitment (e.g. 24 hours) would be set per engagement; until resolved, the existing NEEDS_REVIEW suppression already keeps the record out of screening results.

Chrisian is designing toward two enterprise delivery modalities. Both exist today in a working but simpler form than full production delivery; the gap between what runs now and what's proposed is specific and listed below each one.

{
  "caseNumber": "261100386606",
  "court": {
    "courtId": "305",
    "courtName": "Harris County Justice of the Peace Court Precinct 1, Place 1",
    "county": "Harris",
    "state": "TX"
  },
  "docketType": "EVICTION",
  "filingDate": "2026-09-01",
  "disposition": {
    "status": "DEFAULT_JUDGMENT_PLAINTIFF",
    "date": "2026-09-21",
    "rawText": "Default Judgment for Plaintiff"
  },
  "financials": {
    "claimAmountCents": 145000,
    "judgmentAmountCents": 145000,
    "currency": "USD"
  },
  "parties": {
    "defendant": {
      "fullName": "Marentetti, Deborah",
      "firstName": "Deborah",
      "middleName": null,
      "lastName": "Marentetti",
      "addressLine1": "3804 Brandt St",
      "addressLine2": "Apt 4",
      "city": "Houston",
      "state": "TX",
      "postalCode": "77006"
    },
    "plaintiff": {
      "name": "Littlepage Properties, LLC",
      "address": "1912 W. Main St., Houston, TX 77098"
    }
  },
  "compliance": {
    "isFcraReportable": true,
    "statutoryCutoffDate": "2033-09-21",
    "hasActiveDispute": false
  },
  "provenance": {
    "snapshotSha256": "48a2477ee0868a2f597ea90aefb0997c9afe5d148658e09970a4fb35fcab3c13",
    "lastVerifiedAt": "2026-09-14T10:51:48.342Z",
    "sourceSystem": "HARRIS_TX_JCIS_EXTRACT"
  }
}

County civil cases are dynamic procedural lifecycles that unfold over multiple weeks. The diagram below illustrates the lifecycle a production change-detection system would need to track; it is a design target, not a feature running today.

Operational today:

• Upsert by Case Number: Every record is deduplicated on a unique case_number; re-ingesting the same case updates the existing row in place rather than creating a duplicate.

Not yet built — proposed:

• Change-Event Emission (Delta Engine): Diffing a re-ingested record against its prior state and emitting a discrete event (NEW_RECORD, PROCEDURAL_UPDATE, TERMINAL_DISPOSITION, VACATED_OR_DISMISSED) to downstream subscribers, rather than silently overwriting it.
• Automatic FCRA Tombstone Push: Automatically flagging a vacated or dismissed judgment as non-reportable and pushing that change to downstream aggregators, instead of requiring a fresh query to see the update.

Chrisian's canonical schema is designed to serve as a normalized Intermediate Representation (IR). The mapping below is illustrative guidance for two representative target shapes, not a built adapter — a real target mapping would be defined against the aggregator's own schema:

Custom Declarative Mappings: For proprietary back-office systems, our pipeline supports declarative JSON Schema / JQ transformation templates to adapt date formats (YYYYMMDD vs ISO 8601), case number formatting, and custom enum dictionaries on demand.