search_judgments

shallow

com.courtdelta/court-delta · Verify this server

Search North Carolina (NC) money judgments and criminal sentences by party name. This is the JUDGMENT index, NOT the case index. A judgment is what a court ENTERED on a case — a money judgment against someone, or a criminal sentence. Use this for "does X have a judgment against them", "how much do they owe on it", "is it still active", "find liens/judgments before I lend or rent". For the case itself — charges, hearings, next court date, parties, service — use `search_cases_by_party` (by name) or `lookup_court_case` (by number). Every row carries `case_number`: that is the handoff key into `lookup_court_case` when the user wants the underlying case. IT CARRIES REAL PROPERTY LIENS, WHICH IS NOT OBVIOUS. NC files these as "Civil Misc. Judgment" records on the judgment docket, so this index — not the case search — is where they live. `cause_of_action` on each row says which kind, and the values seen in production include: CV - Claim of Lien (G.S. 44A claim of lien on real property) CV - Federal Tax Lien CV - NC Certificate of Tax Liability CV - Lien CV - Employment Security Comm Lien CV - Institutional Lien (Hospitals) CV - Lis Pendens (pending action against the property) CV - Transcript of Judgment (a judgment docketed from another county) CV - Summary Ejectment, CV - Money Owed, CV - Possession, CV - Collection on Account, CV - Other, FAM - Divorce, ... So "are there any liens against this person?" is answerable HERE, and answerable well: this index has no 200-cap, so a clean search really does mean none found. DO NOT FILTER TO "lien" TO ANSWER "ARE THERE ANY LIENS?" — that under-reports badly. A money judgment docketed with the clerk is ITSELF a lien on the debtor's real property in that county, whatever its cause of action says. So `CV - Money Owed`, `CV - Collection on Account` and `CV - Transcript of Judgment` rows are encumbrances too. Measured on one name: 4 rows whose cause contains "lien", and 35 further docketed money judgments the filter would silently drop — roughly a tenfold under-count. For a lien or title question, DO NOT filter; report the whole set and let the reader classify. `cause_of_action` is for isolating a RECORD TYPE — "show me only the lis pendens", "only the summary ejectments" — not for deciding what counts as a lien. ASK WHICH RECORD TYPES THEY WANT — do not guess. Run the search, read `narrowing["Cause of Action"]` (computed from the actual rows, BEFORE any filter, so it always shows the full menu), tell them what is there, and let them choose. `cause_of_action` MATCHES ON SUBSTRING AND FILTERS CLIENT-SIDE. `"lien"` catches every lien variant above; `"Claim of Lien"` catches only G.S. 44A. Because the index offers no server-side filter for it, the match runs over the rows already fetched — so when `results_total` exceeds what was fetched, `cause_of_action_note` will say the count is NOT a total. Read that note before reporting a number. NOT in this index, and not anywhere in this server: UCC financing statements (those are NC Secretary of State), Register of Deeds records, and lien-agent notices under G.S. 44A-11.1 (liensnc.com is not a court system). Say so plainly rather than implying a clean search covered them. Provide at least one of `party`, `case_number`, `alias`, or `from_date`. `party` is a name in "LAST, FIRST" form (business names work as-is). `case_number` accepts dashed or undashed. `from_date`/`to_date` bound the date the judgment was ORDERED (not the case filing date, and not a hearing date) — ISO `YYYY-MM-DD` or `MM/DD/YYYY`, both accepted. A PARTY SEARCH DOES NOT COVER ALIASES, so this tool checks them for you. `party` and `alias` are separate indexes with no overlap — measured, a search for "WILLIAMS, PAMALA" as a party misses a judgment filed against "MCARDELL, PAMALA" that lists "WILLIAMS, PAMALA" as an alias. Whenever you pass a full `party` name, an alias sweep runs automatically alongside it and its hits come back in `alias_matches`, separate from `results`. READ `alias_sweep.status` BEFORE CALLING ANYONE CLEAR: "ran" -> aliases were checked. Zero matches is a real negative. "failed" -> they were NOT checked. Say so; do not report the search as clear. "skipped" -> not applicable, EXCEPT when the reason says the name was a surname only. Ask for a full "LAST, FIRST" name and re-run. AN ALIAS IS NOT NECESSARILY A FORMER NAME. It is any other name recorded for that party — a maiden or married name, a hyphenated or reordered variant ("LEWIS-WILLIAMS, FARRAH" vs "WILLIAMS, FARRAH LEWIS"), or a fuller spelling ("WILLIAMS, SHANE" vs "WILLIAMS, SHANE CHRISTOPHER"). Measured, 15% share the party's own surname. Do NOT describe an alias as a name that was "changed", and do not infer a marriage or divorce from one — the record does not say. An `alias_matches` row is filed against a party recorded under a DIFFERENT NAME, so it may be the same person or an unrelated namesake. Report those rows as leads to confirm — never state them as this person's judgments, and never merge them into a total owed. They carry no amounts. `alias` as an INPUT searches the alias index directly and takes the same "LAST, FIRST" form ("PAMALA WILLIAMS" returns nothing). Passing it explicitly turns the automatic sweep off, since it would repeat the same query. Row-level `debtor_aliases` / `creditor_aliases` list other names recorded for that party. They are populated essentially only on alias searches — empty on a party search is normal and means nothing. CIVIL vs CRIMINAL — read this before reporting a null. Each row has a `case_category` of CV, CR or FAM. `judgment_type` populates on civil rows; `sentence_type` populates on criminal rows. A null on either one means NOT APPLICABLE to that row's category — it is NOT an absence of fact, and must never be reported as "no sentence recorded" or "no judgment type". DOLLAR AMOUNTS ARE FETCHED AUTOMATICALLY WHEN THE RESULT SET IS SMALL — do NOT ask the user whether to pull them. Leave `detail` unset and this tool decides: a `case_number` search, or any search returning 10 rows or fewer, comes back with amounts already included. Check `detail_included` to see what happened, and `detail_skipped_reason` when it didn't. The reason it is not unconditional: `detail` fans out one upstream call PER ROW. A broad name search with detail forced on has been measured timing out at 60s — "ANDERSON, DAVID" returns 153 judgments, and asking for 153 amounts at once fails outright, whereas the same search without detail succeeds. So on a large result set the amounts are deliberately skipped and `detail_skipped_reason` tells you how to narrow (county, date range, judgment_type, or a specific case_number). Narrow and re-run rather than forcing it. Override only if you must: `detail=true` still respects the row guard and will not fan out over a large set; `detail=false` suppresses amounts entirely. With detail, each row gains `total_judgment_amount`, `principal_amount`, `court_costs`, `attorney_fees`, `interest_rate`, `judgment_status` and the for/against party roster. Amounts are strings; a null means the court recorded no value, which is different from "0.00". Where `detail` is null on a row, no dollar figure is available — never infer or state an amount from such a row. Filters: - `county` — a plain county name ("Wake"). Filtered SERVER-SIDE and exactly, covering both that county's District and Superior court. Unlike `search_cases_by_party`, this filter does not eat into a result cap. - `judgment_type` — civil, comma-separated, e.g. "Recorded", "Granted in Whole or Part", "Default Civil". - `sentence_type` — criminal, comma-separated, e.g. "Active", "Community", "Intermediate", "Fine". Every valid value for all three is returned in `facets` with live counts, so read `facets` rather than guessing a filter value. Speed: ~1-3 seconds. This tool is the FAST exception — it does NOT run the slow WAF-gated portal search that `search_cases_by_party` and `lookup_court_case` do, so do not warn the user about a long wait here. Completeness: `results_total` is the TRUE statewide total. This index has no 200-case cap, so the truncation caveat that applies to `search_cases_by_party` does NOT apply here. `results_truncated` reflects only the display `limit`; page further with `offset` if needed. Read-only. NC only. Informational, not legal advice. A name match is not an identity confirmation — same-name people are common.

100.0/100

1 trials · measured 27 days ago

search_judgments scores 100.0/100 on Vouch's measured behaviour index, from 1 real invocation trials against com.courtdelta/court-delta, measured 11 Sept 2026 under methodology v0.2.0. Every measured component scored 100.

Component breakdown

ComponentWeightValue
Reliability35%not applicable
Schema integrity25%100.0
Failure behaviour15%not applicable
Latency15%not applicable
Concurrency10%not applicable

Tool details

Transport
remote
Credential class
open
Input schema
not declared
Output schema
not declared
Side-effect classification
unclassified

Score history

DayScoreTierMethodology
2026-09-11100.0shallowv0.2.0

Probe evidence

ProbeOutcomes
schema_integritypass: 1

Raw request/response logs are not archived yet — the outcome counts above are drawn directly from every recorded trial.

Embed this score

Available for every tool, scored or not — not a verification perk. Always links back to this page.

Vouch score: search_judgments
[![Vouch score](https://vouch.tools/api/tools/8e808b40-8df1-46f4-8efb-23a1575d6757/badge.svg)](https://vouch.tools/tools/8e808b40-8df1-46f4-8efb-23a1575d6757)
search_judgments — Vouch