Open source pet screening, built for AI-native property platforms.

What's working today (v0.1).

An honest accounting of what ships in the binary you can run right now — and what is in active development.

• Authentication and tenancy — sessions, scoped API keys, multi-org isolation, on-behalf-of headers
• Properties and RBAC — properties, manager assignments, role-based access control
• Resident invitations and accounts — email invitations for staff and residents, password reset
• Pet profiles with review workflow — pets, screening profiles with state machine, manager review queue, audit trail
• Document upload — vet records, vaccination certificates, photos (PDF, JPEG, PNG, HEIC, up to 10 MB, 5 per profile); pluggable local-FS or S3-compatible storage
• MCP server — SSE transport, 18 tools (12 reads + 2 workflow + 3 manager write-back + score-explanation), templated resident-notification emails, audit-grade dual-event logging on every write
• Chat-first onboarding — every role lands in /chat immediately after sign-in. A Claude Sonnet assistant auto-fires a personalized briefing within seconds: who you are, what you can access, the 2–3 highest-priority items in your queue, and a concrete next action. Same tool catalog the MCP server exposes, scope-filtered per role. Streaming SSE, inline tool-call pills, full audit trail. No browser extension or external client needed.
• Operator-configurable agent behavior — tone (formal / neutral / casual), terminology overrides (call residents tenants), additional instructions, and site-wide policy notes adjust the LLM's responses without code changes or restarts. Edit at /admin/site-settings, hit save, the next chat turn reflects the change. Every save is audited with a before/after diff.
• Honest permission model — managers see role-appropriate capabilities; the agent communicates clearly when permission is insufficient instead of pretending. Every MCP write tool runs through one gate, and a structured permission_denied response carries the reason, who can act, and concrete alternatives — so the chat agent surfaces the truth (“Diane isn’t assigned to Acme West”) instead of inventing a technical-sounding excuse. Operator-only /admin/permission-audit page lists historical writes by managers at properties they aren’t currently assigned to.
• Manager-initiated pet applications with conversational walkthroughs — the manager opens chat and says “send Maria an application request for her new pet at Acme East,” and the agent does the rest: creates the request, emails the resident, surfaces it in the resident’s next-login briefing. The resident’s chat assistant then walks them through pet basics and screening questions one at a time, capturing explicit-absence narratives (“will renew next week,” “no vet yet, will establish within 30 days”) as audit-quality reviewer context. On submit the application converts into a real pet + scored profile and the manager gets a notification email with the score — no forms, no PDFs, no copying between systems. Resident dashboard surfaces pending requests with a one-click “Continue in chat” CTA; the property page lists every request across its lifecycle with a manager-side Revoke action.
• Drag-and-drop document uploads in chat with conversational follow-up — residents drop a vaccination PDF or vet letter directly into the chat textarea; a paperclip chip shows what's staged. The agent picks up the upload, asks which profile it should attach to (or infers from context when the resident is mid–needs-info resolution), and calls the new attach_document_to_profile tool. Same 10 MB / PDF · JPEG · PNG · HEIC validation as the REST surface, with a 24-hour TTL on staged-but-unattached uploads and a per-hour janitor sweep. Closes the needs-info loop entirely in chat: manager says “please upload current rabies vaccination,” resident drops the file, agent attaches it, resident says “done,” agent resubmits the profile in a single tool call.
• Visual approval pipeline with milestone-by-milestone status indicators — every destructive action requires confirmation against the canonical workflow — when a manager says “approve Buddy,” the agent doesn't just call transition_profile and report success. It calls preview_transition_profile first; the chat renders a vertical canonical pipeline showing each milestone (Submitted → Under Review → optionally Needs Info if the profile ever entered it → the proposed terminal step) with a green ✓ for completed steps, a filled blue dot for the current step, and a dashed-border arrow for the proposed step (red-tinted when destructive and terminal). Each completed step shows the date it was reached and who acted; needs_info shows entry and resolution dates plus a brief synthesised resolution context. Then a Confirm button. Only on Confirm does the action fire. Same flow for outbound emails: the agent drafts via preview_notification, the chat renders the message as an email card with the rendered subject + body, the manager clicks Send. The contract is enforced server-side — an agent that skips the preview gets a structured permission_denied with reason=preview_required and no profile state changes / no emails send. Every confirmed action's audit row carries the originating preview_id so six-months-later forensic queries can reconstruct exactly what the manager saw before each terminal decision.
• Profile workflow view available on demand — managers can ask “where is Buddy?” and see the canonical pipeline of approval milestones rendered visually, with completed steps marked and current state highlighted — get_profile_workflow is the read-only sibling of the preview tools. Same vertical pipeline widget the destructive-action flow renders, just without a Confirm button. Active profiles show the current step as a filled blue dot; terminal profiles (approved, rejected) show the terminal step as a completed green ✓. Permission gate stricter than the existing read: only admin / property-assigned manager / resident-on-profile / operator-with-pin can render a profile's workflow — a structured permission_denied response carries alternatives naming people who CAN view it, so the agent's failure narrative is honest rather than masked as NotFound.
• Visual review surface with scannable profile cards, urgency indicators, status badges, and the canonical approval pipeline rendered the same way everywhere — property managers see priorities at a glance — Phase 2.3 codifies a small set of structured visual patterns the chat agent emits as markdown blocks, which the frontend renders as styled components: a review-queue-table showing 2+ profiles with urgency-colored left edges and a 12-day “ready for approval” cell next to a 1-day fresh-submission, a single priority-callout for the top item (red · amber · green tier per waiting age), an action-prompt yes/no card at the end of each turn (red-tinted for destructive transitions), and a compact summary-card for single-profile context with score chip, status badge, and highlights/concerns columns. The vertical pipeline widget always shows the canonical 4-step skeleton (Submitted → Under Review → Needs Info → terminal) so every profile’s journey has the same visual rhythm — un-visited milestones render as de-emphasised “Not required” gray dots. Status references in prose like 🔍 under_review upgrade to colored pills automatically. All components share a unified LeashPass design-token system; see docs/styling.md.
• Property managers see scannable review queues, priority callouts, and profile summaries rendered server-side — the agent calls structured-data tools instead of formatting JSON, eliminating an entire class of UI bugs — Phase 2.4 moves structured-data authorship out of the LLM and into three new MCP tools: list_review_queue returns the caller's scoped queue with per-row urgency tiers and write-permission flags, get_priority_item returns the single highest-priority lead (with a friendly “queue clear” positive callout when nothing's waiting), and get_profile_summary returns the highlights / concerns card derived directly from screening fields (no LLM inference — bullets always match reality). The chat handler detects each tool by name and wraps the JSON response in the same fenced widget block format the Phase 2.3 patterns use; the frontend renderer stays unchanged. The LLM’s instructions become simpler too — one rule per visual (“call this tool”) instead of a JSON-shape spec the LLM had to author correctly under streaming pressure. Same visual outcome as Phase 2.3, far fewer failure modes (wrong tag spelling, empty payloads, info-string variants, streaming flicker — all gone). The defensive LLM-emit path stays in place so historical conversations render unchanged.
• LP-Score engine — rule-based, breed-blind, FHA-aware pet screening with published YAML rubric, deterministic scoring, and exempt-by-default service animals / ESAs
• Document duplicate detection — every upload is SHA-256 hashed in-stream; collisions emit an audit event and a reviewer-UI badge
• Realistic demo dataset for evaluation — one command (or one button click in the operator UI for hosted deploys) populates 17 pets across 2 properties, 7 staff, 15 residents, profiles in every workflow state, plus optional 6 months of deterministic synthetic audit history so MCP timeline queries return meaningful answers. Operator accounts persist across seed runs.

Version v0.1 is a working backend you can run and integrate against today. It is not yet recommended as the sole system of record for production leasing decisions — check the repo for current status.