ParcelClear, described for machines.

Read the statute pages. Each one covers a path a Texas closing takes: the affidavit and the three underwriter paths, entity and trust buyers, leases of twelve months or more, mineral and royalty interests, and OFAC screening at a closing.

Read the sample record. It is a watermarked PDF of a finished record with no potential matches, so its hits and dispositions section reads "No hits recorded" rather than showing the columns a matched file would. It shows the sections a real one carries. It is not a record and it cannot be verified.

Read the plain-text index and the full text of every page if parsing HTML is not worth it. Both are generated from the copy these pages render, so they say the same thing this page does.

Send a human to the pricing page to buy a record with a card. There is no API and no agent checkout today. No endpoint on this site accepts an order or returns a record, and there is no MCP server.

There is no API to build against, but if you are building something that would use one, say so at support@parcelclear.com. That address is where the request gets counted; nothing here promises anything back.

The questionnaire answers, as the party attested them.

The party list, with the role and the party type of each one.

The control-person tree for an entity or trust buyer: every control person by name and role, the control tests each one meets, and the statement by the reviewer that the tree is complete from the documents in the file.

The screen result for every name against the OFAC SDN and Consolidated lists, with the list version id and the date that list was fetched.

The rule set id and version that evaluated the answers.

The result the rule set returned, and the id and reason of every rule that fired.

The disposition a reviewer recorded on each potential match, with the written reason.

The SHA-256 of the evidence pack PDF, and the public verification URL for that hash.

These are the words a record uses for its outcome. They are read from the active rule set rather than restated here, so a version bump moves them.

Missing facts, a list older than seven days, or a screen that does not complete produce HOLD. A record never returns a passing result when it could not finish the work.

The rules are data with a version, not code. Every record is pinned to the version that evaluated it, and a finalized record keeps that version after a newer one ships.

Rule-set hashes from tx-sb17 1.0.4 forward are computed over canonical JSON, with object keys sorted and whitespace removed, so the same rule set hashes the same after reformatting or a database round trip, and the value can be recomputed from the stored rule set with scripts/verify-rules.ts.

The rule set is published in full below. Every rule id a record prints, every reason string, and every control-person test id resolves in that file, and the hash above is the canonical hash of it.

The fields the questionnaire collects, their types, and the two a record cannot be created without, as JSON Schema draft 2020-12. It is generated from the same field list the form renders, so a field added to the rule set appears in both.