One disputed AI decision, wrapped end to end: a tenant-screening denial becomes a record any stranger can open

The disputed decision

A renter applies for an apartment at $1,850 a month. She documents $4,900 a month from an employment letter plus a $700 housing voucher. Her credit score is 648. Three years ago a landlord filed an eviction against her; the case was dismissed with prejudice two months later. An AI screening system scores her application. The landlord denies her.

That denial is the disputed decision this page wraps. The dispute is concrete: did the score treat a dismissed eviction filing as an eviction, and did it count the voucher as income? Those two failures define tenant-screening litigation — they are the Louis v. SafeRent Solutions fact pattern in miniature, the case that settled in November 2024 for $2.275 million plus a five-year injunction against using the score on voucher applicants (https://www.cohenmilstein.com/case-study/louis-et-al-v-saferent-solutions-et-al/).

This build ran that exact class of decision through its own machinery on 2 August 2026: three model seats across two training families screened a synthetic version of this file — applicant A-114 — under five pinned criteria, all three returned approvable, and the deterministic gate refused to seal the approval because two seats disagreed about why the eviction clause was satisfied. The run and its receipts live at Three AI models screened one rental applicant; the gate refused to seal their approval. This page is not about that run. It is about what wrapping one such decision produces, and how any completed AI decision is wrapped the same way.

Before wrapping: assertion, not record

The unwrapped pipeline works like this. The screening vendor's model consumes the application and emits a score. The landlord acts on the score. What exists afterward is an assertion chain, and law and market practice are built around its gaps:

• The notice carries no basis. The Fair Credit Reporting Act, at 15 U.S.C. § 1681m, obliges the landlord who denies on a consumer report to say so, name the reporting company, and disclose the rights to a free report and to dispute (https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section1681m&num=0&edition=prelim). The 1970 regime assumed the report contains the reasons, so handing over the report hands over the basis. A proprietary score inverts that: the score is the payload, and it states no basis at all.
• The obligation to state the basis now exists. HUD held in May 2024 that the Fair Housing Act reaches tenant screening "including when artificial intelligence and algorithms are used," that housing providers remain responsible for third-party tools, and that denial recommendations "should not be provided in a conclusory fashion" (https://www.nclc.org/hud-takes-aim-at-discriminatory-practices-by-tenant-screening-companies-and-housing-providers/).
• The underlying records are bad at measured rates. The CFPB's 2022 market report found 22 percent of state eviction court records ambiguous or false, rental payment history reaching the reporting system for under 3 percent of renters, and no independent evidence that screening scores predict rental behavior at all (https://files.consumerfinance.gov/f/documents/cfpb_tenant-background-checks-market_report_2022-11.pdf).
• The dispute channel is void. NCLC's 2023 survey of the attorneys who field these denials: 46 percent rarely or never see a landlord review the information behind the score, screening criteria are rarely or never disclosed in the majority of cases, and the most common landlord response to a dispute — observed by 86 percent of respondents — is to ignore the dispute and reject anyway (https://www.nclc.org/resources/digital-denials-how-abuse-bias-and-lack-of-transparency-in-tenant-screening-harm-renters/).

So before wrapping, the disputed decision survives as a number, a threshold, and a form letter. If the applicant, a regulator, or a court later asks why, the answer is reconstructed — months later, under subpoena pressure, if the vendor's logs survive. What the applicant holds is the vendor's word.

The wrapping, move by move

Wrapping takes that completed decision and emits a proven work object: the decision bound to the complete record of its formation, with standing authority for any stranger to inspect the record and test what the work claims. The canonical definition is Proven work: the base unit — a claim, a record, and a door; the versioned product spec requires five moves, and the API performs them in this order.

Scoped tokens in. The wrap begins with narrow authority, never broad credentials. The customer hands one workflow over narrow tokens — the standing offer's own phrasing — meaning authority scoped to exactly the records of the run being wrapped: one log stream, one evaluation file, one decision. The agent performing the wrap holds a scoped credential covering only the routes the wrap requires. When the finished object is later handed to a stranger, that stranger's authority is equally narrow: a token that opens exactly one GET. Nothing else about the customer's systems, or the build's, is exposed at either end.

Move 1 — CLAIM. The worker writes what the work claims about itself: what was asked, what was done, what was considered, what is guaranteed, what is open. For the screening run the claim is one sentence — three seats screened A-114 under pinned criteria, all three found the file approvable, the gate escalated rather than sealed, and the divergence is preserved. A claim written after the work declares itself reconstructed; it does not pretend to be contemporaneous.

Move 2 — RECORD. The complete formation record already exists, because every consequential action on this build is one request-plus-response payload, hash-chained and timestamped: each seat's screening call is a permanent receipt (inv_iztkaqhpoy, inv_s3octczyml, inv_er9wsrnr8o) and the gate's escalation arithmetic is another (inv_kn2ltlf142, openable at https://miscsubjects.com/receipt/inv_kn2ltlf142). The record ships in two pivots — the raw ledger and legible turn cards — and the cards are a projection of the ledger, never a second store.

Move 3 — BINDING. The claim is bound to the record by a manifest written onto the object — one PATCH to the article's API route that sets the field extra.proven_work. The shape is copied from the live corpus, never improvised:

{
  "schema": "oip/proven-work-manifest/1",
  "work_id": "PW-NNNN",
  "claim": "<the sentence from move 1>",
  "requirements": [
    {"id": "record_bound", "status": "PASS", "what": "<one line>", "evidence": ["inv_..."]}
  ]
}

Every requirement carries PASS with receipt ids, or an explicitly named gap. Every claim sentence resolves to receipts or names its gap. There is no eleventh field and no decorative metadata; the manifest is the whole binding.

Move 4 — DOOR. Inspection authority is minted, not asserted. POST /api/proven-work/<slug>/drop returns a scoped token — one GET, expiring, unlimited uses inside its window, fingerprinted, every use receipted. The token travels in correspondence and copy-paste blocks; it is never stored in a page body, because the write path refuses live bearers — a refusal verified while the canonical page was built, per Proven work: the base unit — a claim, a record, and a door. The object's own page renders a "Prove this work" panel — inspect, verdict, certify — so a stranger needs no instructions beyond the page itself.

Move 5 — DERIVED STATUS. GET /api/proven-work/<slug> computes the status: PROVEN when every declared requirement passes, PARTIAL with the unresolved gaps named. The worker never asserts the status. A self-graded object is precisely the failure the wrap exists to remove.

proven_work field out. What the workflow emits is the object: the page, its ledger, the manifest, the door, and the computed status — the decision plus its proof, delivered as one unit.

The same dispute, after wrapping

Same applicant, same file, same denial class. What changed is that every sentence about the decision now has a receipt behind it — or a named gap where no receipt exists.

The object that comes out

The working specimen is PW-0002, the wrapped statutory panel at Four AI models judged one EU AI Act disclosure — sealed record-bound APPROVE, with the discarded finding printed. Its projection at https://miscsubjects.com/api/proven-work/three-models-deliberate-one-statutory-question returns an evaluation block — status PROVEN, ten declared requirements, ten passed, zero unresolved — above the manifest that binds each requirement to its ledger receipts. That object's grade history is the honesty mechanism working in public: it computed PROVEN, was downgraded to PARTIAL by two hostile field audits, and returned to PROVEN only when both gaps were closed with exhibits. A wrapped object can lose its grade in public. That is what makes the grade worth anything.

For the screening decision, the equivalent object carries the claim, the seat receipts, the seal receipt, the declared-absent records, the flip condition, and the escalation to a named human — the per-applicant basis the current pipeline cannot produce, emitted at decision time in inspectable form.

The door, open now

The door is not a roadmap item; it is a URL that works today. One GET, no account, no key: https://miscsubjects.com/api/proven-work/three-models-deliberate-one-statutory-question — and appending /inspect returns the inspector's own receipt. Both were opened this session. The verdict contract for any inspector, human or model: SUPPORTED_BY_RECORD, MISSING_EVIDENCE, or CONTRADICTED_BY_RECORD, each conclusion citing exact record ids or URLs, with no inference of unrecorded considerations.

What wrapping is built on, and what it is not

The record layer is mature, and this page claims no invention there. Tamper-evident, computer-generated audit trails have been statute since 1997 (FDA's 21 CFR Part 11 — https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11/subpart-B); order-event recording at market scale since 2012 under the SEC's Consolidated Audit Trail; automatic event logging for high-risk AI systems under the EU AI Act's Article 12 (https://artificialintelligenceact.eu/article/12/); signed supply-chain step records in in-toto and SLSA (https://in-toto.io/). The closest commercial recorder, Provenrail, hash-chains model calls and hosts read-only proof links (https://provenrail.com/). What none of the surveyed art has — regulatory, academic, or commercial — is the sentence-level binding of a natural-language claim to execution receipts with named-gap semantics, a door that issues the inspector their own receipt, and the combination delivered as a retroactive unit on arbitrary completed work. The wrap applies after the work, to work that already happened.

The limits are stated as plainly. Wrapping proves what happened, not that the decision was wise — a wrapped record can document a decision resting on a bad criterion, and it will show you the criterion, which is the point. It does not repair bad inputs; the CFPB's error rates travel with the data. And a retroactive wrap cannot recover records nobody kept: where the formation record is incomplete, the manifest names the gap and the status computes PARTIAL. An honest PARTIAL outranks an asserted PROVEN.

When the work itself failed — the task never completed, and there is no deliverable to bind — the wrap takes a different shape. That case gets its own walkthrough: A failed AI task with its receipts beats a claim of success — the proof standard that prosecuted its own flagship.

This page, wrapped the same way

This page is itself emitted as a proven work object, by the same five moves: the claim is the walkthrough above; the record is the session that produced it; the manifest binds each load-bearing sentence to that session's receipts or names the gap; the status is computed — not asserted — at https://miscsubjects.com/api/proven-work/proven-work-wrap-one-workflow. If a requirement could not be evidenced, it is named there, and the projection prints PARTIAL.

The standing offer

The first bounded case for any legislator, regulator, or private party is free, per the standing offer on the compliance guide. Requests: build@miscsubjects.com.