Manager is the administrative hub of PPE1 — the single, governed surface where everything the engines consume is configured: client companies and their org hierarchies, investor programs and the rules within them, the ratesheet mappings that turn investor files into base pricing, and the government data that drives eligibility. Nothing reaches the engines until it is defined, scoped, and governed here.
One PPE1 deployment hosts many independent lending companies side by side — each with its own org hierarchy and, where it runs wholesale, its own broker division. Every record carries its owning company, and that scoping is enforced platform-wide over a privileged system-owner tenant. This is the tenancy model a SaaS provider needs — already built and exercised, not a roadmap item.
Region → branch → loan officer — each manager scoped to the regions and branches they run, seeing only their own company's world.
Broker branch → account executive — an optional third-party-origination structure running alongside retail, under the same ownership scoping.
Every screen and action is gated by named roles, and scope follows the org structure. PPE1 never hard-deletes — deactivation is a soft-delete that History Mode can reveal and reactivate — so every configuration change is preserved, recoverable, and auditable.
Not a policy document — enforced in code and in the database.
A named-role catalog gates every screen and action, with org-derived scoping narrowing a manager's reach to the regions and branches they run. Enforcement is layered — the UI hides controls and the API independently rejects unauthorized actions — so a hidden control can never be driven directly.
Records are never physically removed; deactivation stamps a marker that History Mode can surface and reactivate, giving every configuration change a preserved, auditable trail. The widening filter lives in the stored procedures themselves, making history a system-wide property — not a per-screen feature.
Almost all data access runs through parameterized stored procedures — inline SQL is a rare, reviewed exception — for plan caching, injection safety, and maintainability. The same disciplined layer drives high-volume ratesheet migration (routinely over a million pricing records a day) and preview-gated annual government-data imports.
Everything Loan Pricer evaluates is defined and governed here.
Request Private AccessDefines who uses the platform and exactly which programs they may be priced on.
Client companies (lenders and brokers), their regions, branches, and users are created and organized here, and each client is subscribed to the investor programs it may use. Investor programs are defined as shells — categorized by plan and program type and their distribution channels — then populated downstream; the subscription is the contractual switch that gates what the pricing engine will ever consider for a client.
Where a program's eligibility limits and price-adjustment structures are built and maintained.
Administrators define a program's guideline sections — the max-allowable matrices for credit, LTV/CLTV, loan amount by purpose, DTI, reserves and MI — plus the LLPA and SRP adjustment grids the pricing engine applies on top of base pricing. Whole-program guideline inheritance and selective, cell-level adjustment inheritance let common rules be reused across similar programs without re-entry. This is the definition side; the engine's application of the math stays protected.
Turns inconsistent investor ratesheet files into the base pricing the engine prices from.
Each product is mapped to coordinates in the investor's price sheet via Headers — supporting a Block structure and two Linear/flat-file formats — then migration extracts that pricing into the base-pricing store the engine consumes. It's one of the highest-stakes areas in the platform — routinely migrating over a million pricing records a day — with auto-adjustment for shifting layouts, fatal-error flagging, and a Show-Pricing verification path so a bad mapping is caught before it reaches loans.
Loads the public government data that drives loan eligibility and geography.
Annual import wizards pull loan limits (FHFA conforming, HUD FHA/HECM), census-tract geography, AMI, and Duty-to-Serve classifications directly from official primary sources, while a background service ingests Federal Reserve index and mortgage-rate series. Imports run as a safe staging phase followed by a reviewable preview-and-apply, so administrators verify the data before it updates the tables the engine uses for conforming/high-balance and special-program determinations.