Skip to content
Staircase

Mortgage model

The mortgage class dictionary: the loan transaction, its parties, its collateral and the documents and money that move with it.

The model derives from the industry standard for mortgage data and covers the whole life of a loan — origination, funding, secondary market and servicing — together with the document types the transaction produces.

The dictionary as written covers a second subject as well: the platform that served it, in classes for its API objects, its ticketing, its tenancy and its own product catalogue. Those are withheld by name, each with its reason, so what remains here is the mortgage.

It is a graph rather than a relational schema, and it is flat: no class nests another. A relationship between two classes is itself a class, whose properties join them. Every class is independently addressable and a relationship can carry its own attributes, which a foreign key cannot.

How it is governed

Naming is a written law rather than a convention. Types, properties and relationships are lower snake case; abbreviations are spelled out unless expansion is painful; and the property suffix carries the type — an indicator is boolean, an identifier is an identifier, an amount and a percent are decimal, and a type is an enumeration whose range is a named enumeration set backed by its own file.

Definitions are required to be complete sentences that define the term rather than expand the acronym. The stated reason on record is future use by a conversational system: a definition reading as a glossary stub transfers nothing to a model reading it.

Every proposed change ran a fixed sequence: a use case submitted on a form, a draft class diagram, alignment against the existing model, review by a named domain expert, revision, notice to the requester, then publication.

How it works

Identity is immutable. Every state of an entity is a new database-generated identifier, and a stable global identifier groups every state of the same real-world thing, named for its class. Reading history is a query over that group rather than an audit table, and a correction never destroys what it corrected.

An attribute becomes its own class on six tests: whether it repeats, whether it is shared, whether it has internal structure, whether it changes over time, whether it relates to other attributes, and how it is used. The tests are what kept the model from either flattening into wide records or exploding into a class per field.

There is a deprecation pipeline for the model itself: duplicate analysis, impact analysis across every consumer of a class, automatic upcasting of a caller's payload to the current model, and usage monitoring of classes on the way out. Several removals were executed through it, each with its own recorded runbook.

Validation is two-layered — see Lexicon for the serving surface. Syntactic shapes constrain datatype, enumeration, pattern, length and range. Semantic shapes carry conditional rules: if a borrower's marital status is married, the spouse's name becomes required.

Classes

The classes carrying the most

ClassPropertiesReferenced by
address 36 0
insurance 32 1
loan 30 2
person 23 4
payment 16 1
pricing_schema 14 1
property 13 2
finance_relation 12 0

Type to search.