v1 — safe-mode, browser-only
v1 ships without any server-side analysis at all. The flow is deliberately conservative — until the redaction-pipeline unit-test gate clears against a 5+-fixture lease corpus and the Pattern F AI tenant is provisioned, the safest behavior for tenant audiences is no server hop at all.
- Step 1
You paste lease text into the analyzer
The text lives in browser memory. No POST request fires. No background sync. No telemetry on the content of your paste. - Step 2
The browser redacts identifying patterns locally
tenant_name ← regex: (Tenant|Lessee|Resident)(?: Name)?\s*[:\-]\s*(...) landlord_name ← regex: (Landlord|Lessor|Owner|Property Manager)\s*[:\-]\s*(...) property_addr ← regex: \d+\s+<street keywords>\b ... \b[A-Z]{2}\s+\d{5} phone ← regex: (\d{3})\s*[-.\s]?\d{3}[-.\s]?\d{4} email ← regex: [A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,} ssn (safety) ← regex: \d{3}-\d{2}-\d{4}Each pattern is conservative — we'd rather over-redact than miss something. The analyzer only sees redaction tokens (<TENANT>,<ADDRESS>, etc.) from this point on. - Step 3
A local pattern matcher classifies the redacted text
~50 keyword cues (e.g., "late fee", "arbitration", "holdover") are scanned against the redacted text. Each cue maps to one of 12 clause-slug values. Cue matches are grouped by slug — the analyzer surfaces which clause types are present, not what they say. - Step 4
The deterministic ruleset renders the per-state answer
For each matched clause type, we render the per-state rule from a static, primary-source-cited JSON ruleset committed in this repo. The legal/enforceability content is never generated by an AI — that's the YMYL discipline that survives review. When a state-clause cell has not been primary-source verified, the page renders a visible PLACEHOLDER pin and the state-legislature landing link. - Step 5
What the server logs
Nothing about your paste. v1 has no server endpoint that receives lease text. Server-side telemetry on this site is limited to standard request logs (URL, timestamp, IP — kept by nginx, rotated by ops policy) and (when it ships) aggregate page-view counts via Consent-Mode-v2 analytics. No content, no PII residue.
The future Pattern F tier
When the AI extraction tier ships (Pattern F, second consumer in the Desymphony portfolio), the redaction pipeline gains an S1-extraction branch:
- Step 1
Browser still redacts first — same regex pipeline
No bypass. The v1 redaction pipeline is the same one that survives into v2. - Step 2
Only redacted text leaves the browser
The HTTPS POST goes todesymphony.dev/api/v1/chat/completionswith an X-Site-Slug header for the LeaseRedFlag tenant. Network-tab inspection is the verification path — the request body must never contain unredacted PII residue. - Step 3
S1 Ollama classifies into 1 of 12 clause-slugs
The LLM does classification only. It does not generate the legal answer. The legal answer comes from the deterministic ruleset. - Step 4
Aggregate-only logs — never content
ai_request_logs: site_id = leaseredflag-us request_class = classification success_bool = true request_body = NULL ← never logged response_body = NULL ← never logged created_at = <timestamp>We only retain that a request happened, not what was in it. If this contract is ever broken, the kill switch is the/monitor/ai-tenantspause toggle — it returns 403 at the Central middleware instantly.
What we won't do
- We won't store your lease text — v1 never receives it.
- We won't sell or share data with property managers, tenant- screening operators, or marketing networks.
- We won't promote eviction-mill operators or tenant-data resellers, even if their CPL is highest in the niche.
- We won't generate legal answers from an LLM — the LLM only classifies clause type; the rule is from the static, primary- source-cited ruleset.
- We won't ship the Pattern F upload-PDF/OCR mode until the redaction-corpus unit-test gate clears against a documented fixture set.