191
production loans in the verified reconciliation scope
A sanitized scope metric from the loan-operations engagement; it is not a claim about total portfolio size.
Case study · Loan operations, CRM integration, and agent operations
Caul Group / Sympli Mortgage — Operations Platform & Integration Architecture
Connecting loan operations, CRM, team execution, and leadership visibility without creating a second source of truth.
Integration Architect · Technical Product Owner · Operations Automation Lead
- LiveLoan-operations integration
- Structured demoAgent operations hub; pilot-gated
- Sanitized reconstructionPublic case study
01 · At a glance
The operating context
- Organization
- Caul Group / Sympli Mortgage
- Role
- Integration Architect · Technical Product Owner · Operations Automation Lead
- Period
- Recent engagement
- System type
- Loan operations, CRM integration, and agent operations
Maturity and public status
- LiveLoan-operations integration
- Structured demoAgent operations hub; pilot-gated
- Sanitized reconstructionPublic case study
≈55%
reduction in automation execution cost
An engagement result from consolidating redundant executions while preserving necessary operational controls.
02 · Context
What the environment demanded
Mortgage loan operations were centered on ARIVE, while CRM and communication workflows lived in GoHighLevel. A custom application was needed for operational visibility, orchestration, and reconciliation without replacing either transactional system.
A related Agent Hub explored recurring check-ins, coaching requests, training evidence, and leadership visibility. Because policy, authentication, roster, messaging, and backend decisions still required approval, that product was explicitly separated from the live integration and treated as pilot-gated.
03 · The real problem
The risk was larger than a messy workflow.
A governed operating layer across mortgage, CRM, and team systems—designed to preserve system boundaries, prevent unsafe duplicate communication, and make reconciliation visible.
Conflicting sources of truth could create inconsistent loan or borrower state.
Duplicate borrower or contact records could trigger incorrect or repeated communication.
A sync could appear successful without reconciling the correct environment, account, record, or workflow.
Automation volume could exceed plan limits without improving operational control.
Provisional internal policies or demo behavior could be mistaken for approved production rules.
Fragile environment and release handoffs could make recovery slower when a live issue surfaced.
04 · Ownership
What I owned
I owned the framing, operating logic, constraints, acceptance model, and delivery direction. Implementation was completed with engineering and/or AI-assisted tools according to the engagement context; I do not claim to have hand-written every line.
- Defined the product and operational requirements across the loan, CRM, and operating layers.
- Established the source-of-truth model and cross-system boundaries.
- Set deduplication, stable-key, idempotency, and borrower-communication requirements.
- Defined reconciliation acceptance criteria and stakeholder decision briefs.
- Directed cost-aware automation design and end-to-end validation.
- Oversaw testing, type checking, authentication, environment, release, and recovery expectations.
- Gated pilot and production readiness for the Agent Hub while shaping the agent and leadership experiences.
05 · System map
Boundaries before integrations.
ARIVE supplies verified loan and borrower state to the custom operating layer. That layer coordinates controlled CRM enrichment and internal workflows, then surfaces role-appropriate views for leadership and agents. Writes are limited by system ownership, identity confidence, and borrower-safety rules.
ARIVE
Owns canonical loan and borrower state.
Boundary: The operating layer reads verified state and does not redefine loan truth.
Custom operations layer
Coordinates visibility, exceptions, reconciliation, and internal handoffs.
Boundary: It orchestrates work without becoming a second loan-origination system.
GoHighLevel
Receives approved workflow context and CRM enrichment under controlled rules.
Boundary: Borrower creation and borrower-facing actions are not blindly automated.
Leadership and agent experiences
Surface assigned work, evidence, coaching needs, and decision context.
Boundary: Visibility is role-aware; provisional policy remains visibly provisional.
Systems in context
- ARIVE
- Authoritative loan and borrower state
- Custom operations application
- Visibility, orchestration, exceptions, and reconciliation
- GoHighLevel
- Controlled CRM and communication enrichment
- Supabase and Vercel
- Application data and deployment where applicable
- Approved automation layer
- Cost-aware sync and workflow execution
- React, TypeScript, and Vite
- Agent Hub interface and implementation context
06 · Decisions and rationale
The judgment behind the system.
Tools change. The durable work is deciding what owns truth, what may move, what must stop, and what evidence is enough.
Keep ARIVE authoritative
- Decision
- ARIVE owns canonical loan and borrower state.
- Why
- A second operational truth would introduce conflicting statuses, reconciliation failures, and unsafe borrower-facing behavior.
- Consequence
- The custom platform visualizes, orchestrates, and enriches work; it does not become another loan-origination system.
Control CRM enrichment
- Decision
- GoHighLevel may receive approved enrichment and workflow context, but the system must not blindly create another borrower contact.
- Why
- Duplicate contacts can trigger duplicate nurture, follow-up, or borrower communication.
- Guardrail
- Borrower-facing actions require a verified identity and state path.
Use stable keys and idempotent updates
- Decision
- Records are matched through stable identifiers and updated through idempotent logic.
- Why
- Names, email addresses, and other mutable fields are not sufficient as the only reconciliation key.
- Guardrail
- Running the same sync again must update the same logical record rather than create another one.
Treat reconciliation as evidence
- Decision
- Validate the complete data path before declaring an integration complete.
- Why
- A successful API response does not prove that every record landed in the right environment, account, table, or workflow.
- Evidence
- The verified reconciliation scope covered 191 production loans; only the sanitized scope is represented publicly.
Separate orchestration from transaction systems
- Decision
- The custom app owns operational visibility, handoffs, and exceptions while transactional truth stays in authoritative systems.
- Why
- Clear boundaries reduce duplicated business logic and make handoff ownership easier to inspect.
Fail safely around borrowers
- Decision
- Uncertain matches or validation failures escalate internally instead of contacting a borrower.
- Why
- Operational speed is not worth an incorrect or duplicated customer interaction.
Optimize around value and plan limits
- Decision
- Consolidate unnecessary executions and prefer event-driven triggers where they preserve the required checks.
- Why
- Automation should spend capacity on meaningful control, not repeated work.
- Evidence
- The engagement reduced automation execution cost by approximately 55% while retaining the necessary controls.
Treat environments and rollback as product concerns
- Decision
- Authentication, database selection, environment truth, deployment, and rollback receive explicit acceptance criteria.
- Why
- A wrong-database discovery and a production login outage required verification, rollback, correction, and a hardened release path.
- Consequence
- The incidents became inputs to stronger release controls rather than hidden footnotes.
Use AI as an implementation engine
- Decision
- AI-assisted coding accelerates implementation while architecture, constraints, acceptance criteria, and validation remain under human ownership.
- Why
- AI can build the wrong system quickly when source-of-truth rules and business guardrails are weak.
07 · Implementation
How the model became executable
- Built the operating model around ARIVE’s authority and a controlled CRM-enrichment boundary.
- Specified stable-key matching, repeatable update behavior, exception handling, and full-path reconciliation.
- Consolidated automation runs while retaining the checks required for safe operations.
- Validated environment, authentication, database, type, and release behavior in proportion to production risk.
- Overhauled the Agent Hub in place, preserving working routes, brand assets, meeting controls, coaching requests, export behavior, and data keys.
- Replaced device-level check-in assumptions with per-agent duplicate prevention and occurrence IDs for recurring meetings.
- Designed training completion around checkpoints, assessments, applied evidence, and leader sign-off rather than viewing time alone.
Guardrails
Where the system must stop
- No automatic creation of a second borrower contact.
- Uncertain identity or state escalates internally.
- Repeat syncs update a logical record instead of duplicating it.
- Live integration and pilot-gated Agent Hub maturity are labeled separately.
- Attendance, role, SMS, retention, privacy, and training rules remain provisional until approved.
- Authentication, roster, calendar, messaging, legal, and backend decisions gate an Agent Hub pilot.
08 · Outcomes
What changed
- Reconciled the verified data path across a sanitized scope of 191 production loans.
- Tested end-to-end sync behavior rather than assuming success from individual API responses.
- Reduced automation execution cost by approximately 55% while preserving necessary controls.
- Established borrower deduplication and communication guardrails.
- Clarified the boundary between source-of-truth systems and the operating layer.
- Converted production incidents into stronger environment, rollback, and release controls.
- Produced a decision-ready Agent Hub that preserved existing work and exposed policy dependencies before pilot.
09 · Evidence register
What the public record can show
Evidence is described conservatively. Any visual proof added to this page must be redacted, captioned, and checked before publication.
Diagram
System-boundary diagram
Shows authoritative data, permitted direction of travel, write boundaries, and internal escalation paths.
Sanitized evidence
Reconciliation record
A sanitized record of scope and full-path validation with borrower information removed.
Narrative record
Exception and recovery narrative
Documents how environment and authentication issues were detected, rolled back, corrected, and translated into release controls.
Sanitized evidence
Agent Hub decision model
Separates preserved product behavior, pilot assumptions, training evidence, and unresolved policy gates.
10 · What this proves