Building BREKIN: A Mortgage AI Knowledge System for Ratespedia

BREKIN started as a practical problem inside the Ratespedia ecosystem.

Ratespedia needed a way to train a mortgage-focused artificial intelligence (AI) system without turning every update into a code change, a prompt edit, or a messy document dump. The people who understand the business needed a controlled place to teach the system what to say, what not to say, how to handle common borrower questions, and how to route conversations toward the next useful step.

That became BREKIN: Broker Reasoning Engine for Knowledge, Intelligence & Navigation.

The goal was not to build a public chatbot first. The goal was to build the training layer behind one. BREKIN is the internal knowledge system that lets approved trainers submit mortgage knowledge, review what the AI has learned, test answers against approved sources, and prepare that knowledge for future customer-facing chat and voice experiences.

---

Why BREKIN Needed to Be Its Own Application

BREKIN needed to be its own product surface because AI training is not the same thing as day-to-day operations.

Ratespedia already has internal operational tooling for mortgage workflows, lead handling, record management, metrics, and administrative processes. BREKIN has a different job.

The existing operations layer is about business process control. BREKIN is about AI knowledge control.

Keeping BREKIN separate gave the product room to have its own interface, deployment, trainer workflow, and testing surface without burying AI training inside a broader operations dashboard. At the same time, it still needed to use the same trusted platform foundation.

That led to a split architecture:

• BREKIN has its own Next.js application.
• BREKIN has its own Vercel deployment.
• BREKIN has its own trainer-facing product surface.
• BREKIN manages authentication through Supabase.
• BREKIN stores its own AI training data in the shared database using a dedicated namespace.

That separation matters because it keeps the AI product focused while still fitting into the larger Ratespedia platform.

---

The Product Shape

BREKIN is built around four trainer-facing areas.

Training Studio is where approved trainers submit text or voice training material. This is the intake point for new knowledge.

Knowledge Base is where approved knowledge can be reviewed, searched, edited, categorized, indexed, and removed.

Test Suite is where trainers ask realistic questions and see how the AI answers using the current approved knowledge base.

Voice Router is the planned customer-side direction for call routing and voice-driven workflows.

The important design decision was that BREKIN should feel like an operations tool, not a novelty AI demo. Trainers need to know what was submitted, what was approved, what category it landed in, what sources were used, and whether the AI answer is grounded in something real.

The interface is intentionally direct: submit knowledge, inspect knowledge, test knowledge, improve knowledge.

---

Supabase-Managed Authentication

Authentication was one of the first real architecture decisions.

BREKIN should not behave like a public standalone destination where anyone can create an account and start training a mortgage AI. It needed controlled access, approved users, and a clear boundary between trainer workflows and future customer-facing experiences.

Authentication is managed through Supabase Auth.

The product flow is intentionally simple:

1. An approved trainer signs in through the authorized Ratespedia identity path.
2. Supabase validates the user session.
3. BREKIN checks whether the user is allowed to access the trainer surface.
4. Approved users land inside the protected app.
5. Unapproved users stay outside the training system.

That avoided maintaining a separate identity system just for one AI training tool.

The redirect behavior had to be hardened too. During development, it is easy for authentication callbacks to drift between localhost and production. BREKIN now treats production redirects and next parameters carefully so a sign-in flow cannot bounce users back to localhost or to an unsafe external URL.

---

Controlled Training Instead of Prompt Chaos

One of the easiest ways to make a bad AI product is to treat training as a pile of loose notes.

That was exactly what BREKIN was built to avoid.

Training needs structure. Mortgage knowledge can include tone guidance, qualification details, program explanations, objection handling, pricing language, document checklists, process steps, compliance-sensitive statements, and call-routing rules. Those should not all land in the same generic bucket.

BREKIN organizes knowledge into practical training categories such as:

• Tone & Voice
• Customer Interaction
• Do's & Don'ts
• Qualification & Programs
• Compliance & Risk
• Objections
• Process & Next Steps
• Pricing & Costs
• Documents & Checklists
• Voice Router
• Needs Review

This gives trainers a way to see what the system knows and where that knowledge lives.

The purpose is not just organization. Categorization makes the system easier to audit. If something sounds wrong in the Test Suite, the trainer can inspect the source category, edit the entry, remove it, or add better training.

---

Text and Voice Training

BREKIN supports both text and voice training input.

Text training is straightforward: a trainer writes or pastes training material, then the system cleans it, categorizes it, and prepares it for review and indexing.

Voice training is more interesting.

The voice workflow is transcript-first. A trainer can speak training material, BREKIN sends the temporary audio for speech-to-text (STT) transcription, receives the transcript, cleans the transcript, and discards the audio. The audio file is not kept as the knowledge source.

That decision was intentional.

The useful artifact for retrieval is the cleaned transcript, not a library of stored audio files. Keeping the system transcript-first lowers storage overhead, avoids building an unnecessary audio archive, and keeps the training workflow focused on reviewable text.

Once the transcript exists, BREKIN can clean common speech artifacts:

• filler words
• repeated words
• noise markers
• rambling fragments
• unclear or conflicting statements

The point is not to pretend voice input is automatically perfect. The point is to turn rough spoken instruction into reviewable training material that can be approved, corrected, or rejected.

---

Retrieval-Augmented Generation

BREKIN uses retrieval-augmented generation (RAG).

That means the AI does not answer from a vague memory of the internet. It answers from retrieved pieces of the approved knowledge base.

The flow looks like this:

1. A trainer approves knowledge.
2. BREKIN splits that knowledge into searchable chunks.
3. Chunks are stored with category, tags, source metadata, and optional embeddings.
4. A trainer asks a question in the Test Suite.
5. BREKIN retrieves the most relevant active chunks.
6. The model receives those chunks as grounded context.
7. The answer is generated from that supplied context.
8. The UI shows the answer and the source chunks behind it.

That last step matters.

If the answer is good, the trainer can see why. If the answer is weak, the trainer can see what source material caused the weakness. That creates a feedback loop instead of a black box.

The Test Suite is not just a demo. It is an inspection tool.

---

Why Removal Had to Be Real Removal

Knowledge removal is one of those details that sounds small until it breaks trust.

If a trainer removes a bad knowledge item, it cannot keep influencing answers.

BREKIN treats removed knowledge as removed from active retrieval. The approved knowledge item is taken out of the active knowledge base, and its retrieval chunks are removed with it. The original training input can still be marked for audit purposes, but the rejected material should not remain available to the AI as an answer source.

That design prevents conflicting training from lingering in the system.

For an AI knowledge product, deletion behavior is product behavior. If trainers cannot trust removal, they cannot trust training.

---

Model Strategy

BREKIN currently uses xAI models for the AI layer.

The system uses a chat model for reasoning over retrieved context, a speech-to-text path for voice training, and an embedding path where vector storage is compatible with the database.

The embedding layer is designed defensively. If an embedding call fails or the returned vector shape is not compatible with the current database configuration, BREKIN still stores the knowledge chunk and can continue using lexical retrieval as a fallback.

That was an important engineering tradeoff.

The trainer workflow should not collapse just because one part of the model stack is still being tuned. Full semantic retrieval is the better long-term target, but the product still needs to function while that layer is hardened.

That is the difference between building a demo and building a tool people can actually test.

---

Database and Security Decisions

BREKIN uses the Ratespedia Supabase foundation.

Supabase gives the system authentication, database access, row-level security (RLS), and a path to vector retrieval through PostgreSQL extensions. BREKIN-owned data uses its own naming boundary so the AI system can stay separated from other platform responsibilities.

The important security decisions were:

• keep service-role access server-side
• validate trainer access before allowing app entry
• keep raw voice audio temporary
• separate submitted training from approved knowledge
• remove rejected knowledge from active retrieval
• keep customer-facing delivery separate from trainer workflows

Those choices are not flashy, but they are the difference between a useful internal AI system and a risky one.

---

What BREKIN Shows About My Work

BREKIN is one of the strongest examples of the kind of full-stack product work I want to keep doing.

It includes:

• Next.js App Router application architecture
• React and TypeScript interface development
• server-side API routes
• Supabase authentication and database integration
• shared identity with an existing operations suite
• Vercel deployment
• controlled AI training workflows
• transcript-first voice handling
• retrieval-augmented generation
• source-grounded answer testing
• data cleanup and categorization
• access control and redirect hardening
• product thinking around internal tools and future customer delivery

The hard part was not "adding AI."

The hard part was deciding where AI belongs in the system, how knowledge gets approved, how bad knowledge gets removed, how trainers inspect answers, how Supabase-managed identity protects the trainer surface, and how the product can grow from internal training into customer-facing chat and voice routing.

That is the part I care about most.

AI features are easy to prototype. AI systems are harder to govern.

BREKIN is my attempt to build the governance layer first.

---

What Comes Next

BREKIN is ready for internal testing, but the next phase is where the product gets sharper.

The remaining work is focused on:

• testing real trainer workflows
• improving cleanup and categorization rules
• expanding coverage reporting
• hardening retrieval quality
• building the customer embed package
• connecting the voice router path
• improving analytics around questions, weak answers, and source coverage

That feedback loop is the point of the whole system.

BREKIN is not finished because the first version can answer questions. It becomes valuable when trainers can repeatedly improve what it knows, verify how it answers, and trust that the customer-facing layer is grounded in approved mortgage knowledge instead of guesswork.

That is the product I wanted to build.