# Data # Data Two domain models: the mortgage model covers the loan transaction end to end, and the property model covers the physical asset and the public record behind it. Both models are class dictionaries: a class, its properties, each property's type, and the classes it points at. Every product request and response is a subset of one of them, so a field name on a product page resolves to a definition here rather than to a per-endpoint glossary. The two are separate dictionaries with separate governance, and they overlap by name where both descend from the same standards work. The overlap below is computed from the two files rather than asserted. ## Mortgage model The transaction: the parties, the loan and the mortgage plan behind it, the documents, the fees and taxes, income and employment, credit, insurance, the payment schedule and the borrower's wider financial profile. Definitions are complete sentences by rule. The dictionary as written also models the platform that served it — its API objects, its ticketing, its tenancy and its own catalogue. Those classes are named and withheld rather than published, because a reader looking for the shape of a loan does not need the shape of the software that carried it. - `address` - `credit` - `document` - `employment` - `employment_income` - `fee` - `finance_relation` - `income` - `insurance` - `loan` - `mortgage_application` - `mortgage_plan` - `payment` - `person` - `person_credit` - `person_income` - `pricing_schema` - `property` - `property_tax` - `tax` ## Property model The asset: parcel, structure, layout, lot, deed, tax, sales history, permits and the surrounding jurisdiction records. Grouped below by the question each class answers about a property, which is the grouping the extraction pipeline itself uses. - `property_seed` - `unnormalized_address` - `address` - `parcel` - `person` - `property` - `tax` - `tax_jurisdiction` - `tax_exemption` - `lot` - `sales_history` - `file` - `layout` - `flood_storm_information` - `structure` - `property_improvement` - `utility` - `deed` - `geometry` - `appliance` - `homeowners_association` - `hoa_policy` - `loan` - `property_ranking_overall` - `inspection` - `environment_characteristics` - `safety_security` - `transportation_access` - `school` - `tax_authority` ## Shared lineage Both models descend from the same standards work, and the overlap is the evidence for that rather than a sentence claiming it. A row appears here because both dictionaries name the class; it disappears the moment either renames it. A shared name is not a shared definition. The two models were governed separately and a class on both sides may carry different properties, so the table links to each side rather than merging them. Shared classes are computed at build time by intersecting the class names in the two dictionaries: a class is listed because both models name it, and it drops out the moment either one renames it. A class with no property-model link exists in the property graph but is reached by no published data group, so it has no page. | Class | Mortgage model | Property model | | --- | --- | --- | | `address` | open | open | | `credit` | open | not published | | `document` | open | not published | | `employment` | open | not published | | `fee` | open | not published | | `finance relation` | open | not published | | `income` | open | not published | | `insurance` | open | not published | | `loan` | open | open | | `mortgage application` | open | not published | | `mortgage plan` | open | not published | | `payment` | open | not published | | `person` | open | open | | `pricing schema` | open | not published | | `property` | open | open | | `tax` | open | open |