From Theory to Practice: How We Built a Guardrailed AI Layer on Top of Enterprise PPE

Last month, we published a three-part series asking a hard question: does an LLM have enough algorithmic consistency to be trusted with mortgage pricing? Part One made the case that AI is transforming every industry, but lending demands a higher standard than most. Part Two tried to define what acceptable algorithmic inconsistency even means in a regulated lending context. Part Three moved from theory to testing — outlining the methods and principles required to audit a black box and prove it meets lending standards.

The postings reflected a lot reflection as we were building toward something.

This post is about what we built.

The standard we won't compromise on

Four words have anchored everything we do in pricing, long before 'AI in lending' was a phrase anyone used: repeatable, testable, auditable, scalable. Repeatable — a price has to come from the same rule every time, given the same inputs. It has to produce that same price again tomorrow, and next year, under examination — repeatable. It has to be provable in a test suite before it ever reaches a borrower — testable. It has to operate consistently and FAST over large numbers of transactions — scalable. And it has to be traceable, after the fact, to the exact rule and the exact data that produced it — auditable.

That's the bar we set in our Algorithmic Consistency series. It's also the bar that most 'AI pricing' announcements quietly skip past.

The problem with 'AI pricing'

Everywhere you look right now, pricing engines are bolting conversational AI onto their products. Ask a question in plain English, get a rate back. It's a genuinely useful interface improvement. It's also, if you're not careful, a way to quietly hand the most consequential number in the transaction — the price — to a system that wasn't designed to be deterministic, auditable, or repeatable.

That's the line we said we wouldn't cross in Part Two: AI inconsistency might be acceptable in a recommendation, a summary, or a conversation. It is not acceptable in a number a borrower will be held to.

So the question we've spent the last several months answering wasn't 'how do we add AI to PPE.' It was 'how do we add a conversational layer without letting the conversation touch the math.'

Two layers, doing two different jobs

Underneath Enterprise PPE, nothing has changed. The PPE Engine and the Best Offer Wizard Engine are still the same core they've always been: deterministic, repeatable, testable, auditable. Same rule, same price, every time. Provable before it ships. Traceable after the fact. That's the foundation our Algorithmic Consistency series argued for, and it's the foundation that doesn't move, no matter what sits on top of it.

What's new is the layer that sits above that core. We've built support for MCP (Model Context Protocol) — an open standard that lets AI agents and conversational applications talk directly to Enterprise PPE, alongside the PPE API our customers already integrate with. And we've built our own client on top of it: MACK, a conversational pricing assistant that can field a question like 'what if we dropped the LTV by five points' or 'walk me through why this borrower doesn't qualify for the better rate,' and turn it into the exact same calls our pricing engine has always made — then explain the result in plain language.

The distinction matters more than it sounds like it should. MACK's job is translation, not calculation. It takes a loose, human question and turns it into a precise, structured request against the PPE Engine through MCP. It then takes a precise, structured answer and turns it back into something a loan officer or a borrower can actually use. At no point does it invent a number, round a number, or 'interpret' a number. The engine still owns every figure that comes out the other side.

We've taken to describing this internally as deterministic core, improvisational edge — and we mean both halves literally. The core doesn't improvise. The edge doesn't calculate.

What this actually looks like in practice

Testing this wasn't a matter of running MACK through QA once and calling it done. Per the auditing framework we laid out in Part Three, we built test suites that don't just check whether a conversation sounds right — they check whether every number a conversation surfaces traces back to a specific, reproducible PPE Engine call. Deterministic in, deterministic out. If a conversational response can't be traced to that source — if it isn't testable, repeatable, and auditable on demand — it doesn't ship. That's not a policy. It's a build requirement.

The result is a system where MACK gets to be genuinely conversational — flexible, responsive, able to handle a question phrased six different ways — precisely because it isn't carrying any of the weight of being right about pricing. The engine carries that weight. It always has.

What's next

Next week, we're formally introducing MCP support for Enterprise PPE, and MACK as the first client built on it. The short version: we've built a way for AI agents and conversational tools to talk directly to Enterprise PPE, without giving up an inch of what's made that engine trustworthy — repeatable, testable, auditable, scalable — just with a much more natural way to get there.

If you read the Algorithmic Consistency series and walked away convinced that AI in lending needs real guardrails, not just good intentions, you'll recognize what's coming.

More soon.