Built by Hannah Levinson • more at hrlevinson.com
An evidence-aggregation engine for algorithmic tenant-screening denials. It turns the adverse-action notices and screening reports that tenants receive when they are denied housing into structured, consented evidence that partner attorneys, organizers, and regulators can act on. This repository is a synthetic-data research prototype. No real claimant data passes through it.
When a landlord or property manager denies a rental application based on a tenant-screening report, federal law requires an adverse-action notice that names the screening company and gives the applicant the right to a free copy of the report. Millions are generated every year. Each one is a born-digital record of an automated decision, and most are read once and discarded.
Tessera aggregates those records across many denied applicants, structures them, and finds patterns no single denial reveals: a screening agency that reports eviction filings as judgments they never became, a criminal-record match on a mismatched birthdate, a scoring threshold that falls hardest on one group. The harmed individual is not the user. The user is the movement lawyer, the fair-housing organization, the tenant union, or the journalist trying to change the practice, not win one appeal.
The approach models Louis v. SafeRent, the 2024 settlement in which voucher-holders challenged a screening algorithm. The legal spine is the Fair Credit Reporting Act, which is privately enforced in court and does not depend on any federal regulator, alongside Fair Housing Act disparate impact and state source-of-income protections.
This repository is the engine, built and verified end to end on synthetic data. It does not hold, and in this phase cannot accept, real claimant data. Real data waits behind a separate legal and security review.
The pipeline:
- Intake. A denied applicant's adverse-action notice and screening report enter the system, by direct submission or through a partner organization. Fields the document does not carry, voucher status and optional protected-class identification, are captured at intake under consent.
- Consent. Four layered, revocable grants govern every record: store the documents, use de-identified data for pattern detection, be contacted to join a campaign, and share identified data with a named attorney under privilege. De-identified detection is the default. Nothing identified moves without the explicit grant.
- Extraction. A vision-capable model reads each document, whatever its format, and populates a structured record with a confidence on every field. Extraction is scored against ground truth and never sees the answer key.
- Detection. Statistical detectors run over a de-identified view: disparity testing by group and by voucher status per screening agency, accuracy auditing of the cited records, and clustering by agency and reason code. Every finding carries a confidence interval and a cohort size.
- Gated output. Validated patterns become a draft litigation package for a partner attorney or an aggregate-only publication artifact. Neither is produced without passing the human gates.
Five human gates sit across the pipeline, each one enforced state with a logged transition and no automatic promotion:
- Intake verification, where a human confirms the submission and the load-bearing fields.
- Pattern validation, where an analyst confirms a detected pattern.
- Legal sufficiency, where a partner attorney decides whether a pattern supports a claim. This is the line between assembling evidence and practicing law. The system does the first and never the second.
- Publication, where exports are aggregate-only by construction and small cohorts are suppressed so no one can be re-identified.
- Revocation, which always succeeds and deletes a person's data everywhere it lives, including the extraction store and cache.
The data layer is the single owner of the database, and it writes an audit entry on every access. The audit log is append-only and hash-chained: each entry carries a hash of the entry before it, so a later edit or deletion breaks the chain and is detectable. The keyless chain detects naive tampering. Full tamper-proofing with a managed key and external anchoring is part of the real-data security review, not this phase.
Fields carry one of three provenances, and the system keeps them apart. Document-derived fields come from extraction. External-truth fields, like the true disposition of an eviction, come from an independent source such as a court record, because the screening report is the thing being checked. Self-reported fields, like voucher status, come from the applicant at intake. The distinction matters: an accuracy claim that a dismissed eviction was reported as a judgment requires the court record, not the screening report alone.
The synthetic corpus is a pool of 1,000 applications rendered as documents across four screening-vendor layouts and four file types: native-text PDF, image-only PDF, phone-photo JPEG with skew and glare, and portal screenshot. Every document is watermarked SYNTHETIC. Two disparities and two accuracy defects are seeded at known, subtle effect sizes and recorded in a ground-truth manifest the detectors never read. The corpus is reproducible from a pinned seed.
Extraction. On the synthetic corpus, a vision model read the documents at 96.8 to 100 percent accuracy per field and per file type, with no collapse on the degraded phone photos. The lowest cell was the screening-agency name on phone photos, where glare over the vendor header caused a handful of misreads. These numbers are a ceiling on documents the project generated, not a production figure. Real intake will be messier, and the real-world number is unknown until real documents run.
The confidence signal is loose. A low-confidence flag was about twenty-two times more likely to mark a real error, but it caught under half of all errors, so more than half came back confident and wrong. The system does not let that flag decide what a human reviews. The fields that carry a case are verified regardless of confidence.
The denominator finding. The most important result is a limit. A selection-rate disparity is a rate, denials over all applicants by group. Adverse-action documents exist only for adverse outcomes, so a corpus built from tenant-submitted documents contains denials and not the approved applicants who form the denominator. The disparity cannot be computed from documents alone. This is not a flaw in the extraction. It is the shape of the evidence.
The consequence sets the architecture. The document pipeline is an accuracy engine. Accuracy claims are per-person, need no denominator, are race-neutral and privately enforced, and aggregate into a clear pattern of which agency reports inaccurate records and how often. That is the native output. Disparity detection needs an applicant-pool denominator from a partner who sees approvals and denials, such as a housing authority for the voucher claim, or from discovery once a case is filed.
The build runs in phases, each verified before the next.
- Phase 0. Schema, the audited data layer, and the tamper-evident audit chain.
- Phase 1. The synthetic data generator and the seeded corpus.
- Phase 2. Document ingestion and extraction, verified on a live run.
- Phase 3. The five gates, the four-grant consent model, the de-identification boundary, and the revocation cascade.
- Phase 4. The detectors and the clean-versus-extracted viability comparison.
- Phase 5. Output packaging, the draft pattern memo and the gated, aggregate-only publication artifact.
Real claimant data, encryption at rest, and a separated identity store are out of scope by design and blocked until a legal and security review.
- Python 3.11 or newer.
- uv for dependency management.
- An Anthropic API key for the extraction phase only (see https://console.anthropic.com). The other phases need no key.
git clone <repository-url>
cd tessera-screening-engine
uv sync
Create a .env file in the project root:
ANTHROPIC_API_KEY=
The .env file is git-ignored and must never be committed.
make generate
This builds the synthetic applications, documents, and ground-truth manifest from the pinned seed.
make test # the full test suite, all phases, offline
make detect # run the detectors over the corpus
make viability # the clean-versus-extracted comparison report
Extraction calls the Anthropic API, so confirm it on a few documents before a full run:
uv run python -m tessera.extract --sample 3 --mode sync
uv run python -m tessera.score --run-id latest
A full corpus run uses the batch API at half price and costs a few dollars:
uv run python -m tessera.extract --all --mode batch
uv run python -m tessera.score --run-id latest
This is a research prototype on synthetic data. Three limits are load-bearing and stated plainly so no result is oversold.
The corpus proves the detectors recover patterns that were planted through mechanisms that were chosen. A passing run shows the math works on known-shape signals, not that it catches a real disparity arising through an unanticipated channel. Validating against one documented real-world case is the next credibility step.
Real cohorts are small, and a point ratio is weak on its own. The detectors report confidence intervals, and small cohorts are reported as suggestive and underpowered rather than asserted, because that is what survives an opposing attorney.
The document corpus cannot compute a disparity on its own, for the denominator reason above. The accuracy engine is the minimum viable product. The disparity track depends on a denominator partner or on discovery.
Real-data readiness is the work that follows: a partner attorney relationship, a fiscal sponsor, encryption at rest, a separated identity store, and a real consent and intake flow.
Tessera assembles evidence and refers it to attorneys. It does not give legal advice to any individual. Patterns reach an external party only after an analyst and a partner attorney have both signed off. Published output is aggregate-only, with small cohorts suppressed so no person can be re-identified, and the corpus is never re-exposed at the record level. The design is consent-first and revocable by construction. In this phase it runs only on synthetic data.