Real Estate Title Due Diligence

SKILL.md — Real Estate Title & Dispute History Due Diligence Advisor

> Standing disclaimer (applied to every output): This skill provides general, > educational, and analytical information only. It is not a substitute for a > licensed title search, notary, real-estate attorney, surveyor, or title > insurance underwriting. It does not access non-public records and cannot > certify the state of any title. Always verify every finding against primary > source records and consult a qualified, licensed professional before relying on > any output for a decision with legal or financial consequences.

1. What this skill does

It structures a prospective property buyer's due-diligence investigation into a property's title history, encumbrances, dispute record, and zoning/land-use compliance, grounded in established real-estate title-examination methodology. It produces a single, schema-validated DueDiligenceReport and explicitly flags every step that legally requires a licensed professional.

It is a reasoning-support framework, not a record-access service and not a legal-opinion engine.

2. Skill registry — how skills are registered, resolved, executed, validated

This skill is implemented as a modular skill-registry pattern (see assets/diagrams/architecture.md). The registry is the single source of truth for which sub-advisors exist, how they are selected, and how their output is validated.

2.1 Registration

Sub-advisors extend title_dd.skill.base.Advisor and register themselves with title_dd.skill.registry.SkillRegistry. Each advisor declares:

| Field | Type | Purpose | |------------------|--------|----------------------------------------------------------------| | advisor_id | str | Stable registry id (chain_of_title, encumbrance, …). | | methodology | str | Human-readable methodology name (echoed in the report). | | feature_flag | str | Feature-flag key gating the advisor (see config/feature_flags.json). | | reference_file | str | The grounding reference in references/ the advisor loads. |

Registered advisors:

| Advisor id | Methodology | Reference file | Feature flag | |-------------------|------------------------------------------|----------------------------------------|-------------------| | chain_of_title | Chain-of-title examination methodology | chain-of-title-methodology.md | chain_of_title | | encumbrance | Encumbrance & lien-priority analysis | encumbrance-lien-priority.md | encumbrance | | dispute_history | Dispute & litigation history investigation | dispute-history-investigation.md | dispute_history | | zoning | Zoning & land-use compliance | zoning-land-use-compliance.md | zoning | | report | Due-diligence report assembly | due-diligence-report-template.md | report |

2.2 Resolution

SkillRegistry.resolve(requested, include_report) returns the active advisor set, honouring (in order):

1. Feature flags from config/default_config.json / TITLE_DD_FEATURE_* env

vars. A disabled advisor never runs.

1. Explicit user selection via the advisors field of the input schema.
2. The chain-of-thought router (title_dd.agents.router.ChainOfThoughtRouter)

which inspects the request text, emits an auditable "thought", and may narrow the set when the request only concerns one domain (token efficiency).

2.3 Execution

The orchestrator (title_dd.agents.orchestrator.Orchestrator) drives the run:

1. Loads settings, references (RAG grounding), the LLM client, the tool

registry, the skill registry, and the hook dispatcher.

1. Validates the input against assets/schemas/skill-input.schema.json.
2. Routes to select the active domain advisors.
3. Runs each domain advisor through Advisor.safe_run, which **isolates

failures**: a misbehaving advisor becomes a warning on the report, never a crashed run. Each advisor:

• grounds itself in its reference file,
• builds its checklist via the deterministic build_checklist tool,
• applies user-supplied records to update item statuses and raise findings

(using tools such as lien_priority where relevant),

• asks the LLM client for a concise summary (with graceful fallback to the

deterministic stub provider if the real LLM fails),

• records token usage and emits lifecycle events via hooks.

1. The report advisor assembles all results with the weighted risk-scoring

framework, deduplicates open risks and licensed-professional flags, derives the overall risk rating, and appends a closing note.

1. The report is validated against

assets/schemas/due-diligence-report.schema.json before being returned.

2.4 Validation

• Input → assets/schemas/skill-input.schema.json.
• Per-advisor checklists → assets/schemas/checklist.schema.json.
• Final report → assets/schemas/due-diligence-report.schema.json.

Validation uses jsonschema when available and a structural fallback otherwise. The CLI title-dd validate validates any report file; title-dd validate --skill checks the skill structure is complete.

3. Input / output JSON schemas

3.1 Input (assets/schemas/skill-input.schema.json)

{
  "property_description": "123 Example St, Example County (or legal description)",
  "jurisdiction": "Example State (optional)",
  "intended_use": "single-family residence (optional)",
  "advisors": ["chain_of_title", "encumbrance"],
  "user_supplied_records": {
    "deeds":          [{"date": "2020-01-01", "grantor": "A", "grantee": "B", "vesting": "sole"}],
    "liens":          [{"id": "L1", "lien_type": "mortgage", "recording_date": "2020-02-01", "amount": 150000}],
    "court_cases":    [{"docket": "FC-2023-1", "case_type": "quiet title", "status": "pending"}],
    "zoning_letters": [{"classification": "R-1", "permitted_uses": ["single-family residence"], "legal_lot_status": "legal"}]
  }
}

property_description is the only required field; everything else is optional. The skill never fabricates records — it reasons over what the user supplies and flags what must still be obtained.

3.2 Output (assets/schemas/due-diligence-report.schema.json)

The report object (see the schema for the full contract) contains:

• report_id, generated_at, property_description, jurisdiction
• overall_risk_level (low|moderate|high|critical|unknown) and overall_risk_score (0–1)
• methodology_summary — the frameworks applied
• advisor_results[] — each with checklist, findings, summary,

tokens_used, warnings, and an auditable risk_breakdown

• open_risks[] — deduplicated high/critical findings + flagged checklist items
• licensed_professional_flags[] — deduplicated licensed-professional steps
• disclaimers[] — always non-empty (the standing disclaimer)
• sources[] — the reference documents operationalised
• closing_note — a short LLM-derived interpretation that never certifies title

4. Hooks & tools

4.1 Hooks (src/title_dd/hooks/)

Lifecycle events are dispatched by HookDispatcher. Built-in hooks:

| Hook | Event(s) | Role | |----------------------------|-----------------|---------------------------------------------------| | RunTimerHook | run.start/end | Records wall-clock duration. | | TokenBudgetHook | advisor.end | Aggregates tokens; warns if the budget is exceeded. | | FabricationGuardrailHook | advisor.end | Flags possible fabricated recording references. | | DisclaimerGuardrailHook | report.assembled| Re-injects the standing disclaimer if missing. | | EventEmissionHook | all | Emits structured JSON events (when verbose). |

StateStore provides cross-advisor, per-run state synchronisation (e.g., a judgment lien found by the encumbrance advisor can be cross-referenced by the dispute-history advisor via threaded prior_results).

Custom hooks register with dispatcher.register_hook(event, hook); a failing hook is isolated and recorded as a warning, never breaking the run.

4.2 Tools (src/title_dd/tools/)

Tools are deterministic, schema-declared handlers (they never call the LLM):

| Tool | Input schema | Output | |-------------------|--------------------------------------------------------|------------------------------------------| | build_checklist | {category, methodology_text} | Checklist with weighted, flagged items | | lien_priority | {liens[]} | {priority_ladder[]} with rationale | | score_advisor | {advisor, checklist, findings} | risk_breakdown (item/finding/advisor) | | assemble_report | {property_description, advisor_results, …} | final DueDiligenceReport object |

Tool schemas are published via ToolRegistry.schemas() for runtime introspection and external tool-callers.

5. LLM provider model

The LLM is an abstraction (title_dd.llm). Two providers:

• stub (default, offline, deterministic): produces reference-grounded,

schema-friendly responses with zero network calls. Makes the whole system runnable in CI and air-gapped environments.

• http (OpenAI Chat Completions-compatible): real generative prose, with

bounded retries, exponential backoff, fast-fail on 4xx, and automatic fallback to the stub when fallback_to_stub is enabled.

Switch via TITLE_DD_LLM_PROVIDER (see .env.example). Domain logic (checklists, findings, scoring, flags) is deterministic and identical across providers; only the prose summaries/closing note differ.

6. Configuration (config/)

Type-safe, immutable settings (title_dd.config.Settings) resolved as: config/default_config.json → TITLE_DD_* env vars → explicit overrides.

See .env.example for all knobs (provider, token budgets, log level/verbosity, and per-advisor feature flags).

7. Methodologies applied

Each framework from PROJECT-detail.md §3.2 is operationalised in a concrete references/ file (not just cited). The skill names the framework it is using in every output so reasoning is auditable:

• Chain-of-title examination methodology → references/chain-of-title-methodology.md
• Title-insurance due-diligence standards → references/encumbrance-lien-priority.md
• Risk-based due-diligence checklist framework → references/risk-scoring-framework.md + every advisor's checklist
• Encumbrance and lien-priority analysis → references/encumbrance-lien-priority.md

8. Guardrails (always enforced)

1. Every substantive response carries the standing disclaimer.
2. No certified/legal determinations ("marketable title", "clear title", legal opinions).
3. No jurisdiction-specific legal advice — methodology is conceptual.
4. No judgments about named individuals; stay at population/general level.
5. Every licensed-professional step is explicitly flagged.
6. No fabricated recording references, docket numbers, or chain entries.
7. Uncertainty is stated honestly.

9. Running

# install (editable)
pip install -e .

# run a request
title-dd run request.json
cat request.json | title-dd run --stdin

# validate
title-dd validate report.json
title-dd validate --skill

# self-test (3 fictional scenarios)
title-dd selftest

Programmatic:

from title_dd import run_due_diligence
report = run_due_diligence({
    "property_description": "Fictional Parcel A, Example County",
    "intended_use": "single-family residence",
    "user_supplied_records": {"deeds": [...]},
})

10. Out of scope

• Does not replace a licensed title search, notary, real-estate attorney, or

surveyor.

• Does not access non-public records.
• Does not certify title, issue legal opinions, or guarantee outcomes.
• Does not perform Git operations, model pulling, or model training.

11. Sources

Methodology is distilled from the research catalogue in SECOND-BRAIN-KNOWLEDGE-PAPER.md and the annotated, applied knowledge brain in RESEARCH-PAPER-KNOWLEDGE-BRAIN.md (30 scientist/authoritative sources) into the operational references/ files. src/title_dd/references/citations.py maps each sub-advisor to the papers it applies, and the report assembler injects those citations into every report's sources[] so each finding is traceable to a named source.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: dungnotnull
• Source: dungnotnull/Real-Estate-Title-Dispute-History-Due-Diligence-Advisor-agent-skill
• License: MIT

Install and usage instructions live in the source repository linked above.