EscrowMeetings

Verdict

Build EscrowMeetings as a source-bound public meeting radar, not as a generic AI search engine, meeting scheduler, legal monitor, lobbying tool, or authority layer.

The V1 job is simple: show what public bodies are about to discuss about escrow, title, settlement funds, payoff demands, wire instructions, licensing, insurance, and consumer protection. Search is the interface. The product is the public meeting watch.

Why This Exists

Escrow and settlement workflows are shaped by a messy set of public bodies: state agencies, county boards, city councils, licensing commissions, insurance departments, consumer-protection offices, tax collectors, recorder offices, legislative committees, advisory committees, and national insurance bodies.

The useful moment is before the meeting, when an agenda packet first exposes what will be discussed. Today that information is public but fragmented. EscrowMeetings makes the next relevant public discussion visible in one place.

The product is credible only if it stays close to source records and preserves uncertainty. It should feel like a serious source docket, not a news feed pretending to know more than the public record says.

Primary User

The first user is a Veto operator or founder reviewing public-source signals for escrow-adjacent product, regulatory, standards, and outreach decisions.

Later users may include escrow operators, title/settlement leaders, trade association staff, counsel, insurers, vendor risk teams, and policy watchers. Do not design for them until the internal operator workflow proves useful.

Reference Model

The product reference is Digital Democracy for escrow-relevant public meetings, with CourtListener-style alerts and LegiScan-style topic tracking.

That means source-bound records, saved topic watches, clear dates, clear jurisdictions, and no floating AI answer. Every useful answer should show the records used, source links, dates, record type, jurisdiction, and what the record does not prove.

Product Boundaries

Keep the lanes distinct.

• EscrowMeetings: what public bodies are about to discuss.
• EscrowMinutes: what public meeting records later said.
• EscrowNotices: what regulators and agencies published outside meeting workflows.
• EscrowCalendar: where the industry gathers. This is not part of EscrowMeetings V1.
• EscrowRecords: later unified search across EscrowMap, EscrowCases, EscrowNotices, EscrowMeetings, and EscrowMinutes.

V1 Product

Core Screen

• Search across public body, agenda title, agenda excerpt, source URL, and matched watch terms.
• Filter by time window: today, next 7 days, next 30 days.
• Filter by watch term: escrow, wire instructions, payoff demands, licensing, insurance, real estate settlement, funds movement, consumer protection, county tax, recorder, title, fraud notice, trust account, disbursement, closing documents.
• Filter by public body type: state agency, county board, city council, commission, department, recorder, tax collector, advisory committee.
• Show a feed of upcoming agenda signals with meeting date, public body, agenda item, short excerpt, source state, and reason it matched.
• Show a detail pane with source link, agenda excerpt, matched terms, next operator action, and boundary language.
• Allow a local operator note and a copyable brief. The note can stay local in V1.
• Expose topic watches such as wire fraud, escrow instructions, title insurance, trust accounts, settlement funds, payoff fraud, seller proceeds, buyer funding, AI or automation, consumer protection, enforcement, and license actions.
• Generate a weekly digest preview from source-backed records. Do not send it automatically.

Public Search

• The homepage should be question-first: what are public bodies about to discuss?
• Suggested prompts: meetings mentioning wire fraud, escrow trust accounts, title insurance, payoff fraud, AI, settlement funds, or consumer protection.
• Search results must show source records before any summary.
• If an answer-style summary exists, it must include records used, source links, jurisdictions, dates, record type, limitations, related meetings, and topic-watch action.

What Counts As A Signal

• A publicly posted agenda item for a real upcoming public meeting.
• A public packet, staff report, attachment, or agenda PDF tied to that meeting.
• A source page that identifies the public body, meeting date, agenda item, and public URL.

What Does Not Count

• News articles, blog posts, social posts, private emails, relationship notes, or internal operator notes.
• Past meeting minutes unless used later as follow-up evidence.
• General regulatory pages with no meeting date.
• Speculative interpretations that are not anchored to an agenda item.

Route Map

The first production app should have real URLs even if the first implementation keeps them static.

• /: question-first search surface and current high-signal records.
• /meetings: upcoming meeting feed with filters.
• /records/:id: source-bound record page.
• /topics/wire-fraud: topic page for public meeting records and watches.
• /topics/title-insurance: topic page for title-insurance records.
• /topics/escrow-trust-accounts: topic page for trust-account records.
• /agencies/dfpi: agency page for known sources and records.
• /sources: source registry and coverage state.
• /corrections: correction and source issue intake.
• /subscribe: topic-watch signup and RSS links when enabled.

Data Model

Use a small, source-first record. Avoid broad content objects until the narrow record is proven.

• id: stable record ID.
• public_body_name: official or source-visible name.
• public_body_type: state agency, county, city, commission, department, other.
• jurisdiction: state, county, city, or agency jurisdiction.
• record_type: agenda, minutes, board packet, committee packet, public hearing, transcript, supporting exhibit, bulletin, notice, advisory, or rate filing.
• meeting_date_time: local meeting time with timezone when available.
• agenda_title: source-visible item title.
• agenda_excerpt: short excerpt copied from or clearly derived from the public source.
• record_text: retained extracted text when available.
• text_hash: hash of extracted source text used to detect source changes.
• source_url: original public URL.
• source_file_url: agenda packet or PDF URL when separate.
• raw_file_key: retained raw HTML, PDF, screenshot, or packet location.
• source_registry_id: link to the source registry entry.
• source_posted_at: posted timestamp if visible.
• source_checked_at: when Veto last checked it.
• source_state: linked, queued, needs review, stale, broken, archived.
• matched_terms: terms that triggered the record.
• match_reason: one plain sentence explaining why this may matter.
• operator_action: read, watch, ignore, add source, verify source URL, follow up after meeting.
• boundary_note: explicit reminder that the record is a signal, not a conclusion.

Source Registry Record

• source_id: stable source ID.
• source_name: public body or source page name.
• source_lane: meetings, minutes, notices, or industry calendar.
• source_url: official source page.
• jurisdiction: state, county, city, national, or agency.
• fetch_method: manual, known crawler, PDF parser, portal adapter, or monitor discovery.
• coverage_state: candidate, active, partial, broken, paused, or rejected.
• last_success_at: last successful retained fetch.
• failure_reason: visible reason when a source cannot be trusted.

Source Strategy

Start with California plus national title and insurance sources, then expand state by state. Do not start with all states. Start with a source registry and make every result trace back to an official page.

P0 Source Candidates

• DFPI Escrow Law Advisory Committee pages, past agendas, minutes, PDF packets, and Escrow Law archive pages.
• DFPI bulletins and notices. These belong in the shared source registry, but should usually route to EscrowNotices rather than EscrowMeetings.
• California Legislature bills, committee hearing pages, hearing agendas, bill analyses, and Digital Democracy links where they help locate public hearing records.
• DRE alerts, advisories, updates, public hearings, and meeting pages when source-visible.
• CDI title insurance pages, bulletins, rate filings, hearings, forums, studies, reports, and commissioner materials.
• NAIC title insurance task force or working group materials, agendas, minutes, proceedings, and related antifraud work.
• County and city public meeting portals. Start with Los Angeles, Orange, San Diego, Riverside, San Bernardino, Ventura, and Sacramento, then add five more high-signal city or county portals.
• Common portal systems including Granicus, Legistar, CivicClerk, Municode, BoardDocs, Simbli, and agency-specific pages.

Ingestion Order

1. Manual source registry with URLs, body types, lanes, and coverage states.
2. Known-source crawler or parser for official agenda pages and packet links.
3. Retain raw HTML, PDF, screenshots, extracted text, and text hash for every accepted source record.
4. Term matching and source-state classification.
5. Operator review queue for ambiguous matches.
6. External monitor discovery for unknown long-tail updates. Discovery is not canonical until the official source record is fetched and retained.
7. Follow-up pass after meeting date to attach minutes or outcome if useful.

Current Build State

The public beta now has three retained layers: official source-page records, upcoming agenda document or agenda-link records, and extracted agenda item signals from source documents with parseable public text.

Coverage remains partial. LA County Board agenda PDFs are currently the first retained agenda-text path. San Diego public docket links are retained as upcoming agenda links when the portal exposes a meeting date and agenda URL, but they are not treated as item-level text extraction until the direct document body can be parsed.

The page may show source-linked agenda signals from retained text, but it must not imply complete California coverage, regulator affiliation, Veto verification, or automatic alerts.

Discovery And Stack

Use external monitors for discovery, not as the source of truth. The canonical record should come from the source registry and retained fetches.

• Known source pages: Veto crawler and parser.
• Unknown long-tail updates: Exa Monitor or equivalent discovery monitor.
• Canonical records: Postgres.
• Raw files: Cloudflare R2 or equivalent object storage.
• Search: Typesense first, with structured fields first and vectors second.
• Embeddings: optional semantic retrieval after the structured corpus works.
• Extraction: PDF parser, OCR fallback, and LLM classifier only after raw source retention.
• Digest: Resend only for reviewed topic-watch output, never automatic outbound in V1.
• Admin review: NocoDB, Airtable, Retool, or a small custom admin after source states are proven.

Do not dump PDFs into a vector store and call it a product.

User Workflow

1. Operator opens EscrowMeetings.
2. Operator scans the next 7 days by default.
3. Operator filters to a watch term or public body type.
4. Operator opens an item, reads the source excerpt, and checks the source state.
5. Operator chooses one action: ignore, read source, add to internal follow-up, or check after the meeting.
6. Operator copies a short brief only when the source is good enough to route internally.

V1 should not add anything to a calendar. It can show meeting dates and times, but it should not create external events or reminders.

Product Principles

• Source first: every claim must point back to a public agenda source.
• Before the meeting: upcoming agendas are the core product. Minutes are secondary.
• Signal, not conclusion: the product explains why an item may matter, not what it legally means.
• Operator judgment stays visible: ambiguous records should route to review, not disappear into a false score.
• No private data: public agendas only. No relationship notes, customer files, email history, or private contact data.
• One serious screen: avoid dashboards, vanity charts, generic news cards, or broad market intelligence theater.
• Structured first: public body, jurisdiction, record type, date, source URL, and hash matter before embeddings or summaries.

V0 Acceptance Criteria

• At least 100 source-linked records.
• At least 20 upcoming meetings.
• At least five topic pages.
• One weekly digest preview generated from reviewed source records.
• Every real record has source URL, date, agency or public body, record type, jurisdiction, retained text or retained file, and text hash.
• Every record has a visible source state.
• Every record has matched terms and a short match reason.
• Filters work for time window, watch terms, body type, and source state.
• Detail pane shows the source, excerpt, matched terms, and operator action.
• No UI copy implies Veto approval, verification, endorsement, ranking, fraud detection, insurance, authorization, identity proofing, account confirmation, or funds safety.
• No calendar writes. No outbound messages. No private notes in public output.
• Hostile completion check passes before any public or operator-facing demo.

Non-Goals

• No meeting attendance automation.
• No lobbying workflow.
• No legal interpretation.
• No claim that an agenda item is important beyond the source-visible signal and matched terms.
• No generalized regulation tracker.
• No news product.
• No private CRM, outreach, or relationship layer.
• No generic AI answer engine.
• No unreviewed vector-only corpus.
• No insurance, fraud-prevention, identity-verification, account-verification, or funds-movement claim.

Implementation Shape

Start with one static or lightweight web app. Do not build infrastructure before the source loop works.

Suggested Files

• sources.csv or sources.json: public body source list.
• agenda_items.json: normalized agenda records.
• records.json: normalized source records across meetings, minutes, notices, packets, hearings, and exhibits.
• fetch_agendas.py: source fetcher for known pages.
• match_terms.py: term matcher and source-state annotator.
• extract_records.py: text extraction, hash creation, and retained-file metadata.
• index.html: one-screen review surface.

If implemented inside an existing repo, repo instructions override this shape. Do not import requirements from EscrowMap or receipt projects unless the shared source-record pattern is explicitly useful.

Release Sequence

V0 - California Meeting Radar

Source-backed public meeting radar for California and national title or insurance bodies. Prove source retention, topic pages, search, and digest preview.

V1 - Search And Topic Watches

Add saved searches, topic watch pages, RSS links, and reviewed email alert drafts. Do not send automatically.

V2 - Minutes Archive

Add historical minutes, agenda packets, transcripts, attachments, and entity extraction.

V3 - Multi-State Source Registry

Add state financial regulators, real estate regulators, insurance departments, title insurance regulators, attorney general offices, bar or IOLTA programs, secretary of state records, and consumer protection bulletins using generic jurisdiction and regulator fields.

V4 - EscrowRecords Unified Search

Join EscrowMap, EscrowCases, EscrowNotices, EscrowMeetings, EscrowMinutes, and private Veto file records only where the public/private boundary is explicit.

Verification Plan

• Static check: no tables, no forbidden claim language, no calendar/export hooks, no private data strings.
• Source check: each real item has reachable public URL, meeting date, public body, agenda title, and retained extraction.
• Registry check: every accepted record links to a source registry entry and every source has a coverage state.
• Hash check: retained text or file hash exists for each real source-backed record.
• UI smoke: load app, filter by term, filter by window, open detail, copy brief, confirm no console errors.
• Responsive check: desktop and mobile have no horizontal overflow and keep the agenda feed visible.
• Hostile completion check: identify what is demo, inferred, unverified, stale, unsafe, or outside scope.

Open Questions

• Which P0 sources should be validated first: DFPI, DRE, CDI, California Legislature, NAIC, or county portals?
• Should the first operator action be internal source review, public topic watch, or outbound conversation prep?
• Should EscrowMeetings live as a standalone artifact, an EscrowMap sibling, or an internal Veto research tool?
• What source state is enough for an item to be routed to a human: linked, reviewed, or retained screenshot/PDF?
• Does the first proof loop need one real agenda item that leads to one operator judgment, or the broader 100-record radar corpus?
• Should topic watches be public from day one, or internal until source coverage is visibly reliable?

Next Build Packet

Objective: build a V0 source-backed California meeting radar that replaces demo records with retained public records from the P0 source registry.

• Allowed scope: route map, source registry, normalized records, retained raw files, search/filter UI, topic pages, and digest preview.
• Forbidden actions: no calendar writes, no outbound messages, no private data, no broad regulatory claims, no fake source URLs.
• Acceptance evidence: real source URLs, retained extracted records, hashes, source registry states, UI smoke, mobile screenshot, hostile completion check.
• Stop condition: if source extraction cannot prove public-body name, meeting date, agenda item, and URL, stop and report the source problem.