RealTrust AI: Security-First Real Estate Transactions

I just shipped my latest project, RealTrust AI, a full-stack real estate transaction platform focused on one core idea: legality and access control should be enforceable at the data layer, not just in route handlers.

This repo combines a FastAPI backend, Next.js frontend, PostgreSQL (with PostGIS and pgvector), and an architecture where AI is advisory only. The result is a platform designed for auditability, role safety, and real-world workflow constraints.

The project is open source here: vancedenson-ac/realestate-ai.

LIVE DEMO: RealTrust

Why I Built It This Way

Most demos optimize for speed to first feature. I wanted to optimize for proof of correctness under real transaction pressure:

• State changes should be legal by definition, not by convention
• Access control should be testable and explainable to non-engineers
• Events should be durable evidence, not just log noise
• AI should assist users without mutating authoritative records

Real estate workflows involve many roles, milestones, and compliance requirements. This architecture treats those as first-class product constraints.

Core Architecture

RealTrust AI uses:

• Backend: FastAPI for API boundaries and service orchestration
• Frontend: Next.js for workflow-centric UX
• Database: PostgreSQL as system of record, with RLS and policy controls
• Storage: MinIO for S3-compatible document/object handling
• Infra: Docker Compose for reproducible local stack startup

At a high level, each workflow action passes through API checks and then lands in database-backed legality gates (state-machine transitions, constraints, and role policy). That keeps the critical rules centralized and testable.

Key Design Principles

1) State Machine as Law

Transaction transitions are modeled so illegal transitions are rejected. This reduces hidden business logic drift between backend code and persistent data.

2) Authorization at the Data Layer

Row-level security and explicit deny patterns are central. This lets us answer questions like "could this role have seen this record?" with evidence.

3) Evidence-First Events

Events are emitted in a commit-safe pattern so state and event history remain coherent. That gives a stronger audit story for transaction history and operational replay.

4) AI Is Advisory Only

AI assists users and workflows, but it does not bypass policy or write directly to authoritative tables. That boundary is deliberate and enforced in system design.

Local Developer Experience

One of my goals was a clean onboarding path for contributors and reviewers:

docker compose up -d
scripts\init-db.bat
scripts\seed.bat
scripts\test.bat

That gives a local stack with API, frontend, PostgreSQL, and object storage, plus repeatable DB initialization and test execution.

What Makes This Project Different

A lot of AI-enabled apps still treat governance and evidence as add-ons. RealTrust AI flips that:

1. Legality is encoded and tested
2. Access is policy-driven and provable
3. Events are part of compliance evidence
4. AI is useful but bounded

This approach is heavier than a quick prototype, but it scales better for transaction systems where correctness matters as much as UX.

Final Thoughts

RealTrust AI is my current reference build for a security-first, regulator-aware product architecture that still ships with modern developer ergonomics.

If you're building workflow-heavy products in regulated or trust-sensitive domains, this project may be a helpful baseline for thinking about policy, state legality, and AI boundaries from day one.