Powered by eniston
  1. Overview
  2. Architecture
  3. Architecture Overview

Architecture Overview

Architecture Overview: The Inbox-Native Automation Engine

The Objective: Zero-UI Data Entry In a standard SaaS application, a user logs into a dashboard, navigates to "Deal #101," and uploads a file. This creates a clear, unambiguous link between the data and the transaction.

DealTrail reverses this model. We are building an Inbox-Native platform. Our users (Agents, Lenders, Escrow Officers) should not have to leave their existing workflow to interact with us. They simply email "Amy" (tc@dealtrail.com).

This creates a massive engineering challenge: The Routing Problem. If a Lender emails us saying "Here is the appraisal," how do we know if that document belongs to the active deal at 123 Maple Ave or the pending one at 456 Oak St?

To solve this, we have built a two-part architecture:

  1. The Ingestion Engine: A "Traffic Controller" that identifies and routes incoming data.

  2. The Core Workflows: A "Logic Engine" that executes tasks inside our system of record, DocuSign Rooms.

Part 1: The Ingestion Engine (The Traffic Controller)

Before we can act on data, we must normalize it and route it to the correct transaction context.

A. Ingestion (The Ears)

We do not scrape IMAP servers directly. Instead, we treat Email as an API.

  1. The Listener: A specialized service listens to our tc@ domain.

  2. The Parser: When an email arrives, this service strips away noise (signatures, HTML formatting) and converts the message into a clean JSON Payload.

  3. The Push: This payload—containing the Sender, Subject, Body, and Attachments—is pushed instantly via Webhook to our orchestration layer.

B. The Router (The Brain)

Once we have the JSON payload, we use a Three-Stage Waterfall Logic to determine the destination Deal ID:

  • Gate 1: The Stakeholder Match (Who?) We query our "Rolodex" database. If the Sender address is linked to exactly one active deal, we route it there. If they are linked to >1 deal (e.g., a Lender working multiple files), we move to Gate 2.

  • Gate 2: Semantic Analysis (What?) We analyze the Subject and Body text against the Property Address of the candidate deals. (e.g., Subject "Appraisal for Maple" matches the deal at "123 Maple Ave").

  • Gate 3: The Thread ID (Context) When "Amy" sends an email, she embeds a hidden tracking identifier. If the incoming email is a Reply, we strip this ID to override all other logic and force-route the message to the original deal.

C. The Ambiguity Protocol (The Safety Net)

Rule #1: We Do Not Guess. In real estate, filing a contract into the wrong folder is a liability event. If the Router cannot determine the destination with >90% confidence, it triggers the Ambiguity Protocol:

  1. Auto-Reply: The system pauses and asks the sender: "I see we have a few open files together. Is this for Maple or Oak?"

  2. Human Fallback: If clarification fails, the payload is flagged for manual review by a Human Supervisor to ensure zero data loss.

Part 2: The Core Workflows (The Logic & Action)

Once the Ingestion Engine has successfully routed the data to a specific Deal ID, the Core Workflows take over.

Crucial Architectural Note: We treat DocuSign Rooms as our operational "Holy Grail." While brokers may use various compliance platforms, our internal system of record is the DocuSign Room. The AI's primary job is to keep this room perfectly organized, compliant, and up-to-date.

Workflow A: New Deal Onboarding

Objective: From "Contract Signed" to "Escrow Open" in seconds.

  • The Trigger: A "New Escrow" email with a Purchase Agreement (RPA) attached.

  • The Action:

    1. Extraction: The AI parses the PDF to extract Purchase Price, Client Names, and Key Dates (Inspection, Loan, Closing).

    2. Room Initialization: The system calls the DocuSign API to create a new DocuSign Room.

    3. Role Assignment: It adds external stakeholders (Buyers, Sellers, Lenders) to the Room roster with correct permissions.

Workflow B: Drafting Documents

Objective: Turning plain English into Legal Contracts.

  • The Trigger: An agent emails: "Draft an Addendum giving the buyer a $5,000 credit for roof repairs."

  • The Action:

    1. Intent Mapping: The AI identifies the correct form (e.g., C.A.R. Form ADM).

    2. Data Mapping: It maps variables ($5,000, Credit) to the digital form fields.

    3. Generation: It generates a "Draft" envelope inside the DocuSign Room.

Workflow C: The "Agent Approval" Loop

Objective: The Liability Shield.

  • The Trigger: A draft document is generated.

  • The Action: The system emails the Agent a "Magic Link" to the draft. It waits for an explicit "Approved" signal before routing the envelope to the client for signature. This ensures the AI never sends unauthorized contracts.

Workflow D: The Filing Protocol

Objective: The AI Librarian.

  • The Trigger: A document is fully signed by all parties.

  • The Action:

    1. Identification: The AI scans the PDF to identify the form type (e.g., "Natural Hazard Disclosure").

    2. Renaming: It applies a standardized naming convention (e.g., YYYY-MM-DD_123_Maple_NHD_Signed.pdf).

    3. Sorting: It moves the file into the correct sub-folder within the DocuSign Room (e.g., moving from "Working Docs" to "Disclosures").

Summary

By combining the Ingestion Engine with DocuSign Rooms, we achieve a robust, "Zero-UI" architecture:

  1. The User sees a responsive, intelligent assistant in their email.

  2. The Developer sees a clean, structured API of incoming documents.

  3. The Business maintains full data ownership and compliance within DocuSign, independent of third-party broker platforms.

Was this article helpful?
© 2026 DealTrail 3.0