# The Guide Changed on Tuesday and You Have 4,000 Loans in Flight: Version-Controlling the Rules an AI Mortgage Agent Reasons Against

*October 29, 2026 · 6 min read · Ramkumar Venkataraman*

> Fannie and Freddie update their selling guides constantly, often with several effective dates inside a single announcement, and a loan in your pipeline is governed by the rule that was in force when its application was dated, not the rule in force today. Most AI mortgage tools hardcode the rules and silently drift out of date. A technical account of how we version-control the rulebook, apply the right rule by effective date, and re-plan in-flight loans when the guide moves underneath them.

## The Rule Is Not a Constant, and Your Code Probably Treats It Like One

Here is a fact that most AI mortgage products are quietly wrong about. The rules a loan is underwritten against are not fixed. Fannie Mae and Freddie Mac revise their selling guides several times a year, agency handbooks change, investor overlays move, and your own credit policy gets tightened and loosened as markets shift. A tool that reads the guide once, encodes the requirements into logic, and ships that logic is correct on the day it ships and decaying every day after, because the guide it was built against stops being the guide in force the moment the agency publishes an announcement.

The decay is invisible, which is what makes it dangerous. A hardcoded rule does not throw an error when the guide changes. It keeps producing confident decisions against a standard that no longer applies, and nobody notices until an investor review or an internal audit finds a batch of loans underwritten to last quarter's requirements. The model did not break. It kept doing exactly what it was told, which was the wrong thing, because the thing it was told became wrong and nothing updated it. For an AI agent that touches credit and compliance decisions at volume, treating the rule set as a constant is not a simplification. It is a defect with a delayed fuse.

## A Single Announcement Carries Several Clocks

The reason this is harder than "update the rules when the guide changes" is that a single agency announcement rarely has a single effective date. Take [Fannie Mae's Selling Guide Announcement SEL-2025-04](https://singlefamily.fanniemae.com/news-events/announcement-sel-2025-04-selling-guide-updates). That one announcement carried at least three different clocks: the revisions tied to ANSI measurement terminology applied to loan applications dated on and after September 8, 2025, the quality-control program changes applied to QC reviews conducted on or after September 2, 2025, and everything else took effect on the announcement date of June 4, 2025. One document, three effective dates, each attached to a different trigger, one keyed to the application date, one keyed to the review date, one keyed to publication.

Get the trigger wrong and you apply the right rule at the wrong time. A loan whose application was dated before September 8 is governed by the prior measurement terminology even if you underwrite it in October, because the rule keys to the application date, not to the day you happened to touch the file. This pattern repeats constantly. [Announcement SEL-2025-07](https://singlefamily.fanniemae.com/news-events/announcement-sel-2025-07-selling-guide-updates), which retired the term "appraisal waiver" in favor of value acceptance and revised the reconsideration-of-value rules, carried its own timing. An agent that cannot represent "this rule, effective on this date, for loans meeting this trigger" cannot be correct across a pipeline that always contains loans at different ages, which is every pipeline that has ever existed.

## What Version Control for a Rulebook Actually Means

In our system the rule set the agents reason against is the Rulebook, and it is version-controlled in the literal sense, not the marketing sense. Every rule has an effective date and, where the agency gave one, an applicability trigger, so a rule is not a line of logic that is either true or false. It is a record that says what the requirement is, when it took effect, what it replaced, and which loans it governs. When Fannie publishes an announcement, the change goes into the Rulebook as a new version with its effective date and its trigger, and the prior version does not get deleted. It gets superseded, because a loan dated before the change is still governed by the rule that was in force when it was dated, and you cannot underwrite that loan correctly if you have thrown the old rule away.

This is the difference between a system that knows what the rule is today and one that knows what the rule was on any date. The second is what a mortgage operation actually needs, because the pipeline is a population of loans each frozen to the rule set in force at its application, and the agent working a file has to reason against that file's rules, not against today's. When an agent asserts a requirement, it cites the Rulebook entry, which carries the effective date, so a decision made on a loan is traceable not just to a rule but to the version of the rule that governed that loan. That is what makes the decision defensible later, when an examiner or an investor asks why a file was underwritten the way it was. The answer is the rule that was in force, cited, with its date, rather than a reconstruction of what the policy probably was at the time.

## Re-Planning the Loans That Are Already Moving

The hard case is the loan in flight when the rule changes, and it is the case that separates an agent from a batch process. A recorded workflow, an [RPA script or a copilot](/blog/long-horizon-agents-vs-copilot-mortgage-bounded-autonomy-sr-11-7), does not re-plan when the rule underneath it moves. It keeps executing the steps it recorded, against whatever rule was encoded when it was built. An agent that holds a goal rather than a script can do the thing that actually has to happen, which is reconsider the file against the change and decide whether the change affects it.

Most of the time it does not, because the loan was dated before the change and the change keys to application date, so the agent confirms the loan stays on its original rules and moves on. Sometimes it does, when the change is effective by review date or by publication and the loan has not yet passed the step the rule governs, and then the agent re-plans: it reopens the affected decision, re-evaluates against the new rule, and surfaces the delta if the decision changes. This is the same [re-planning behavior](/blog/ai-underwriting-aus-findings-du-lpa-conditions-sr-11-7-model-governance) an agent uses when a borrower switches from salaried to self-employed mid-file or a new condition appears, applied to a change that came from the rule set rather than from the file. The loan is not re-underwritten from scratch, which would be wasteful and would re-open decisions the change did not touch. Only the decisions the change actually reaches get reconsidered, which is only possible if the system can tell which decisions a given rule change affects, which is only possible if the rules are structured rather than hardcoded.

## The Change Itself Is a Governed Event

Updating the Rulebook is a change to the logic that produces consequential credit and compliance decisions at volume, which means the update is not a routine content edit. It is a governed event, handled in the spirit of [SR 11-7](https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm), because a bad rule change applied automatically across the pipeline is exactly the kind of model risk the guidance exists to catch. A Rulebook change has an owner, a review before it goes live, and a record of who made it and when, so the operation can answer the question an examiner will eventually ask, which is how you know the rules your agents enforce are the current ones and who is accountable for keeping them current.

This also means a rule change is testable before it ships, which is the part that most hardcoded systems cannot do because the rule and the code are the same thing. When the rule is a versioned record separate from the logic that applies it, we can run the proposed change against a set of historical loans and see what decisions it would have altered, which surfaces an overly broad or mis-triggered change before it touches a live file rather than after. We described the broader testing approach in the [agent evaluation work](/blog/testing-long-horizon-mortgage-ai-agent-eval-harness-golden-files-sr-11-7), and rule changes run through the same gate, because a change to what the agent is allowed to do is at least as consequential as a change to how it does it.

## Why Eight Hardcoded Tools Make This Worse

A lender running a stack of point solutions has this problem multiplied by the number of tools, because each one encodes its own copy of the rules and each one decays on its own schedule. When Fannie changes the QC requirements, the tool that does QC has to be updated, and the tool that does underwriting, and the one that does disclosures, and there is no guarantee they get updated on the same day or to the same interpretation. We wrote about the [reconciliation tax of a fractured stack](/blog/point-solution-mortgage-ai-stack-reconciliation-audit-trail-data-integrity) in the context of data, and the rule set has the same fracture: eight tools means eight rulebooks, eight change-management processes, and eight opportunities for one of them to be enforcing a standard the others have moved past. A single Rulebook that every agent reasons against is not only cleaner to maintain. It is the only arrangement where "are we on the current rules" has one answer instead of eight.

## The Honest Read

The rules a mortgage is made against change constantly, and they change with effective dates and triggers that a system has to represent precisely or get wrong in a way nobody sees until it is expensive. A tool that hardcodes the guide is correct on launch day and quietly decaying after, and the decay produces confident, consistent, wrong decisions, which are worse than obvious errors because they do not announce themselves. The fix is not to update the rules faster. It is to stop treating the rules as code and start treating them as versioned records with dates, so the system can tell you not only what the rule is but what it was for any loan on any day.

We built the Rulebook at Sei as a version-controlled layer precisely because the question "which rule governed this loan" has to have a cited, dated answer years after the loan funded, and because an agent that cannot re-plan when the guide moves underneath it is a recording, not an agent. The guide changed on Tuesday. Four thousand loans are in flight, each governed by the rule in force when it was dated. A system that knows that, and acts on it, is the difference between a pipeline that stays current and one that finds out at the next audit that it did not.

---

_Source: [https://www.seiright.com/blog/rulebook-change-management-agency-selling-guide-updates-ai-mortgage-effective-dates](https://www.seiright.com/blog/rulebook-change-management-agency-selling-guide-updates-ai-mortgage-effective-dates) · Sei AI_