Glossary — PropTech Engineering

What we mean by grain, signal, list, move, and the patterns behind them — here, in this app. Each term shows a short quote from the accepted definition, then how we use it.

Articles link here first. The quote is the original; Here is this product.

Vision: Signals on a grain.

Product loop

Move

Use the Pipes and Filters architectural style to divide a larger processing task into a sequence of smaller, independent processing steps (Filters) that are connected by channels (Pipes).

from: Hohpe — Pipes and Filters

Here: One step of the product loop. There are three — not a deploy, not a sprint.

In the app: Detect/extract → match to grain → layer into lists.

Signal

In computing, an event is an action or occurrence recognized by software, often originating asynchronously from the external environment, that may be handled by the software.

from: Wikipedia — Event (computing)

Here: An event or derived flag a buyer can combine as a list filter — not the raw filing.

In the app: Court filing type, tax delinquency, absentee-owner flag; list-eligible only after match to the property.

Signal layering

Faceted search is a technique that involves augmenting traditional search techniques with a faceted navigation system, allowing users to narrow down search results by applying multiple filters.

from: Wikipedia — Faceted search

Here: Combining signals and attributes on one property row so a buyer can find properties that match a set they choose.

In the app: Marketplace list filters; e.g. absentee and a recent filing and a value band. Requires match (attach) first.

Attribute

Dimensions provide the “who, what, where, when, why, and how” context surrounding a business process event.

from: Kimball — Dimension table

Here: A fact of the grain itself, not an event.

In the app: Assessed value, beds, mailing vs site address — facts on the property row at list time.

Grain

… the grain is the pivotal step in a dimensional design. The grain establishes exactly what a single fact table row represents …

from: Kimball — Declaring the Grain

Here: What one list row is. Everyone must agree.

In the app: Today: one property (parcel × county × state). Preview, export, and mask all use the same grain contract.

List

The grain declaration becomes a binding contract on the design.

from: Kimball — Declaring the Grain

Here: A set of grains selected by a combination of signals and attributes (signal layering).

In the app: Filter combinations on the marketplace; e.g. absentee and a recent filing and a value band.

Spine

Conformed dimensions are the backbone of any enterprise approach as they provide the integration “glue.”

from: Kimball — Differences of Opinion

Here: The product loop for one grain: signals → grain → lists. Not the four ingest layers. One product, one spine. A later grain is a second spine on the same landing.

In the app: — (detail in platform-layers-overview when published)

Locator

Record linkage is necessary when joining different data sets based on entities that may or may not share a common identifier.

from: Wikipedia — Record linkage

Here: Identifiers used to match a signal to a grain (address, APN, legal description, parties).

In the app: Keys / identity fields from extractors.

Extension axes

How the loop stays cheap as we grow. Not extra product steps (not moves 4–6).

Extension axis

… software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification …

from: Wikipedia — Open–closed principle

Here: A growth direction we keep cheap on purpose.

In the app: New source/jurisdiction, new detector, or (later) a different domain grain — without a new pipeline philosophy.

Open-closed ingest

… software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification …

from: Wikipedia — Open–closed principle

Here: Add a source or jurisdiction without changing the list contract. Jurisdiction is data, not a fork.

In the app: — (detail in platform-layers-overview when published)

Ports and adapters

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.

from: Cockburn — Hexagonal architecture

Here: Swap or add a detector. Output stays fields + locators.

In the app: — (detail in local-ocr-llm-court-enrich when published)

Rebindable grain

Each proposed fact table grain results in a separate physical table; different grains must not be mixed in the same fact table.

from: Kimball — Declaring the Grain

Here: Same kit, completely different domain later. New spine, same four layers.

In the app: Property lists today; another entity later with its own matching rules on the same landed sources.

Shared landing

In ELT, data is extracted and loaded into a data warehouse first, allowing the data to be transformed using the warehouse’s computing power.

from: dbt — ETL vs ELT

Here: Sources are grain-agnostic. Land once. Do not re-scrape per domain. Spines attach later; they do not own the land.

In the app: — (detail in platform-layers-overview when published)

Grain-specific attach

Record linkage (also known as data matching, data linkage, entity resolution …) is the task of finding records in a data set that refer to the same entity across different data sources.

from: Wikipedia — Record linkage

Here: Each grain has its own locators. Fail closed if this grain cannot bind.

In the app: Parcel locators for property lists; a filing may match a parcel or not — it does not auto-join every list.

Attach

Attach / reattach

Record linkage (also known as data matching, data linkage, entity resolution …) is the task of finding records in a data set that refer to the same entity across different data sources.

from: Wikipedia — Record linkage

Here: Match a signal to a grain (industry: match, resolve, entity resolution, record linkage). Re-resolve when identifiers improve.

In the app: Matching step; unmatched stays off list paths.

Qualification gate

In engineering, a fail-safe is a design feature or practice that in the event of a specific type of failure, inherently responds in a way that will cause no or minimal harm …

from: Wikipedia — Fail-safe

Here: Matching is the gate. Unmatched → not list-eligible. Do not soften this.

In the app: No match to the property grain → that signal does not join property lists.

Fail closed

In engineering, a fail-safe is a design feature or practice that in the event of a specific type of failure, inherently responds in a way that will cause no or minimal harm …

from: Wikipedia — Fail-safe

Here: No identifier match for this grain → off this grain’s lists. Correct, not a missing join.

In the app: We do not show unmatched extractions as inventory on property lists.

Fan-out / projection

… you can use a different model to update information than the model you use to read information.

from: Fowler — CQRS

Here: One landed event, many optional attaches (one per grain).

In the app: Same court filing can feed property match now and another grain’s match later.

Pipeline and patterns

Internal layer names and warehouse patterns. In the app deferred until the matching series post is published.

Gather

In ELT, data is extracted and loaded into a data warehouse first … The raw data is loaded into a data warehouse without any transformations.

from: dbt — ETL vs ELT

Here: Land raw records. Does not decide list-eligibility.

In the app: — (gather-vs-augment when published)

Augment

As events arrive from the outside world at a port, a technology-specific adapter converts it into a usable procedure call or message and passes it to the application.

from: Cockburn — Hexagonal architecture

Here: Detect/extract + match to grain. Plug-in for detectors.

In the app: — (gather-vs-augment, local-ocr-llm-court-enrich when published)

Integrate

The grain declaration becomes a binding contract on the design. The grain must be declared before choosing dimensions or facts because every candidate dimension or fact must be consistent with the grain.

from: Kimball — Declaring the Grain

Here: Standardize the grain; roll matched signals onto it.

In the app: — (dbt-medallion-public-records when published)

Serve

… you can use a different model to update information than the model you use to read information.

from: Fowler — CQRS

Here: Lists — UI + API on the grain contract.

In the app: — (marketplace-query-path, keycloak-marketplace-auth when published)

Medallion

A medallion architecture is a data design pattern used to logically organize data in a lakehouse, with the goal of incrementally and progressively improving the structure and quality of data as it flows through each layer of the architecture (from Bronze ⇒ Silver ⇒ Gold layer tables).

from: Databricks — Medallion architecture

Here: bronze (close to source) → silver (typed/clean) → gold (what lists query). A separate features layer is not a second list SoT.

In the app: — (dbt-medallion-public-records when published)

OBT

Denormalization is the process of trying to improve the read performance of a database, at the expense of losing some write performance, by adding redundant copies of data or by grouping data.

from: Wikipedia — Denormalization

Here: One wide denormalized serving table at the grain. Flags and selected details on the row so a list is one query.

In the app: — (denormalized-gold-vs-star-schema when published)

SoT

A system of record (SOR) … is the authoritative data source for a given data element or piece of information, like for example a row (or record) in a table.

from: Wikipedia — System of record

Here: System of record for the list — one warehouse shape lists read.

In the app: — (denormalized-gold-vs-star-schema when published)

Derived read model (CQRS-lite)

CQRS stands for Command Query Responsibility Segregation. … At its heart is the notion that you can use a different model to update information than the model you use to read information.

from: Fowler — CQRS

Here: Search index built from list-shaped data. Discovery only. Not a second warehouse.

In the app: — (postgres-plus-elasticsearch when published)

Layered pipeline

Use the Pipes and Filters architectural style to divide a larger processing task into a sequence of smaller, independent processing steps (Filters) that are connected by channels (Pipes).

from: Hohpe — Pipes and Filters

Here: Gather → Augment → Integrate → Serve. Shared infrastructure. Not a spine. Do not add stages. One pipeline can feed many grains.

In the app: — (platform-layers-overview when published)