Glossary
Ask AI
Registry objects
Section titled “Registry objects”Data Table : A registered source data table (Parquet, Hive, ORC, CSV, Snowflake, or JDBC). The starting point for everything else in the platform. See Register a Table.
Primary Table : The Data Table that holds the complete list of unique identifiers for an entity (for example, every Application ID, or every Customer ID). Marked with the Primary Table checkbox. Each entity has exactly one.
Key : A rule attached to a column, with a Constraint of Primary, Unique, or None. A column carrying a Key with the Primary constraint is what uniquely identifies a row. See Configure Table Keys.
Data Element : A governed wrapper around a single column of a Data Table, exposing it with metadata, tags, and lineage for use downstream. This is the simple case (with Is Aggregated unticked). A Data Element is often shortened to DE. See Register a Data Element.
Data Aggregate : A Data Element whose value is computed by rolling up multiple rows (sum, count, max, custom logic) using Python, Pandas, or PySpark. Also called an Aggregated Data Element, and often shortened to DE Agg. It is not a separate object type, just a Data Element with Is Aggregated ticked. See Register a Data Aggregate.
Feature : A reusable, versioned variable produced by transforming Data Elements or other Features. Features (often shortened to Feat) become the building blocks of Models and Policies, and sit one layer above Data Elements. See Register a Feature.
Feature Aggregate : A Feature that rolls many rows from a lower entity up into a single value at the Feature’s entity, often shortened to Feat Agg. Not a separate object type, just a Feature with Is Aggregated ticked. See Register a Feature Aggregate.
Model : A trained or imported prediction object registered with inputs, outputs, training data, and explainability metadata. A Model produces a score. See Register a Model Definition.
Policy : The decision workflow that turns a Model score and rules into an actual outcome (approve, decline, refer, offer terms). Policies are what get deployed to your LOS or scoring engine. See Register a Policy Decision Workflow.
Framework : A reusable parameterized definition (most commonly a Product Framework) that Policies or Models can consume as input, so shared configuration is defined once.
Dataset : A registered object type that combines Tables and Features for downstream use such as training or scoring.
Report : A registered, reusable analysis attached to Models, Policies, or dashboards. See Register Reports.
Reason Code : A registered object that maps a decision or score to an explanation code (for example, an adverse-action reason).
Global Function / Global Variable / Runtime Parameter : Shared building blocks registered under Resources and reused across other objects. These are often shortened to GF, GV, and RTP respectively. See Register a Global Function.
Quality Profile : A registered object type used to define data-quality checks, often shortened to QP.
Product : A registered product definition (loan amounts, rates, terms). Held in the Product Framework module and consumed by Policies and Models.
Artifact : A self-contained, deployable bundle Corridor generates for a registered Data Element, Feature, Model, or Policy, used by external systems to execute the logic. See What’s in the Artifact.
Policy building blocks
Section titled “Policy building blocks”Decision Workflow : The chain of blocks that makes up a Policy. Building a Policy means composing these blocks. See Register a Policy Decision Workflow.
Block : A node in a Policy’s Decision Workflow. Blocks chain together to produce a decision. The block types are Application Decision, Offer Creation, Offer Filtering, Offer Optimization, Offer Display, and Derived Variable. See Register a Policy Decision Workflow.
Application Decision : A block that applies rule-based logic to approve, deny, or send an application for manual review.
Derived Variable : A block that computes policy-specific values (for example, APR or monthly payment) that can be referenced in later blocks.
Offer : A product proposal generated by a Policy (amount, rate, term), presented to a customer or prospect.
Offer Creation : A block that builds candidate Offers from parameters and rules.
Offer Filtering : A block that removes ineligible Offers from the candidate set.
Offer Optimization : A block that picks the best Offer from the filtered set based on objective rules.
Offer Display : A block that controls which Offers are surfaced.
Segment : A branch inside a block that groups rules sharing a condition (for example, by product, channel, or borrower type).
Action Rule : A rule that assigns a Policy output. Used inside blocks to set outcomes.
Waterfall : The report showing how a population flows through the Policy, including how many records were approved, filtered, or declined at each step.
Lifecycle, versions, and approvals
Section titled “Lifecycle, versions, and approvals”Draft : The initial status of any object. Editable, scoped to the workspace, not yet visible to broader users.
Pending Approval : Status when an object has been sent for approval but has not yet been signed off. Usually locked from edits. See Approve an Object.
Approved : Status after every required reviewer has signed off. Locked from edits; a new version is needed for further changes. Sometimes referred to as Published.
Rejected : Status when a reviewer rejects (vetoes) an object. You clone a Rejected object to start a fresh Draft.
Active / Shadow : Deployment statuses for a Policy in production (a live version versus one running in parallel for comparison).
Retired : Status of an object taken out of use via the Retire action. Its history is preserved for audit.
Version : A point-in-time snapshot of an object. Each edit on an Approved object creates a new Draft version.
Approval Workflow : A configurable sequence of Responsibilities (reviewers) that an object must pass through before it can be Approved. Defined per object type by an admin. See Configure an Approval Workflow.
Responsibility : One reviewer slot inside an Approval Workflow. Can be a user, role, or external tool, and can have Veto Power. See Configure an Approval Workflow.
Veto Power : A flag on a Responsibility that lets that reviewer single-handedly reject an approval. While a veto reviewer is active, the object is typically locked from edits.
Sequence Order : The order in which Responsibilities review. Same-sequence reviewers act in parallel; later sequences unlock only when every earlier sequence is complete.
Editable by Reviewer : A Responsibility option that lets the reviewer make edits during their review phase (useful for code-style or fair-lending reviews that may require small fixes).
Change History : The chronological audit log on every object: author, timestamp, version, and comments for each change.
Lineage : The dependency graph for an object: every upstream input it relies on, every downstream object that consumes it.
Audit Trail : The read-only, chronological record of state changes on an object. Used for compliance and traceability.
Simulations and jobs
Section titled “Simulations and jobs”Simulation : A job that runs the logic of a registered object (Data Element, Feature, Model, Policy) on data and returns row-level outputs plus metrics. See Run a Simulation.
Job : Any backgrounded execution. Jobs progress through statuses: Scheduled, Queued, Compiling, Running, Completed, Partially Completed, Failed, or Cancelled. See Understand Job Output.
What-If Analysis : A sandbox copy of an approved Policy that you edit and simulate against a baseline, to see how the changes shift the outcomes. See Run a What-If Analysis.
Comparison : A side-by-side view of two simulations on the same dataset. Comparison jobs are deprecated; run two simulations and compare them side by side instead. See Compare Two Simulations.
Single Record Review : A trace of one record through a Policy, showing which segments and rules fired, which Offers were generated, and why. A Single Record Review is often shortened to SRR. See Run a Single Record.
Quick Test : A quick run of an aggregated Data Element on a single record, showing the result right away. Available for Python and Pandas aggregates. See Do a Quick Test.
Portfolio Analysis : A custom multi-object analysis on a portfolio slice (product, region, date range) that assembles the results into one dataset. See Run a Portfolio Analysis.
Data Pull Logic : The PySpark code inside a Portfolio Analysis that runs registered objects and returns one final DataFrame.
Scheduling : The simulation form section that sets a Start Date, Time, and Recurrence so the job runs repeatedly on its own.
Sampling : The simulation form section that selects which records the job runs against, by size, date range, rule, or an explicit ID list.
Job Configs : Form settings that override Spark configuration for a run (for example, executor memory, YARN queue, library versions).
Monitoring, metrics, and alerts
Section titled “Monitoring, metrics, and alerts”Monitoring Dashboard : A recurring view that refreshes on a schedule, tracks metrics across a Model or Policy, and triggers Alerts on breaches. A Monitoring Dashboard is often shortened to MD. See Monitor your Model or Policy.
Alert : A rule on a Monitoring Dashboard’s Alert Settings tab that fires when a condition is met (metric threshold crossed, review date approaching). See Set up Alerts.
Triggered Alert : An Alert that has fired. Listed in the Triggered Alerts tab, where it can be acknowledged, closed, or bulk-managed. See Set up Alerts.
Drift : A change over time in the distribution of inputs or outputs that signals a Model or Policy may no longer match the population it was built on. See Monitor your Model or Policy.
PSI (Population Stability Index) : A drift metric for continuous variables. Compares the distribution of a variable in production against a reference period.
CSI (Characteristic Stability Index) : PSI’s counterpart for categorical variables.
KS (Kolmogorov-Smirnov) : A discrimination metric that measures how well a Model separates positive and negative classes. Higher is better.
AUC (Area Under the Curve) : A discrimination metric for classification Models. The probability that the Model ranks a random positive above a random negative.
ROC Curve : The plot from which AUC is derived: true positive rate against false positive rate as the threshold varies.
Decile Lift : The performance of the top 10% of scored records relative to the population average. A standard scoring-model report.
Approval Rate : The percentage of records a Policy approves on a given run.
Bad Rate : The percentage of approved records that go bad (default, charge-off, or another adverse outcome) over a defined window.
Data and governance concepts
Section titled “Data and governance concepts”Read Logic : Optional Python / PySpark code attached to a Data Table that runs before any downstream job uses it. Used for casts, joins, normalization, and filtering. See Register a Table.
Permissible Purpose : Tags applied to objects that declare where the object is allowed to be used (for example, underwriting only, no marketing, PII-restricted), often shortened to PP. Violations are flagged via Lineage. See Organize Objects.
Collection : A set of conditions on a Role that scopes an action to objects matching certain Groups, Keywords, or Permissible Purposes. See Configure Roles and Permissions.
Superuser : A Role option on Read or Write that grants blanket access on that action, ignoring any Collection filters.
Workspace : The scope within which Draft objects are visible. Drafts are private to the workspace until they are approved.
Modules and UI areas
Section titled “Modules and UI areas”For a tour of how these modules fit together, see the Platform Overview.
Data Vault : The module where Data Tables and Data Elements are registered and governed.
Feature Engineering : The module where Features are built, simulated, and approved.
Model Studio : The module where Models are registered, trained, simulated, and compared.
Prospecting / Underwriting / Customer Management : The decision modules that hold Policies. Prospecting targets prospects before they apply, Underwriting decides at the moment of application, and Customer Management applies to existing customers.
Loan Investment : A decision module for loan-investment policies.
Product Framework : The module that holds reusable product definitions (loan amounts, rates, terms) consumed by Policies and Models.
Resources : The module that holds shared building blocks (Global Functions, Global Variables, Runtime Parameters) used across other objects.
GenGuardX : The module for generative-AI features.
Settings : The area where admins configure Approval Workflows, Users, Roles, authentication and alert providers, and other platform-wide settings. See Configure Platform Settings.
Support : The module that links to the user manual and help resources.
Monitoring Dashboard (page) : The page, reached from a decision or Model module, that holds Monitoring Dashboards, reports, and Alerts for in-production Models and Policies.
Object short forms
Section titled “Object short forms”Informal shorthand you’ll hear for the common object types. Each links to its full definition above.
| Short form | Object |
|---|---|
| DE | Data Element |
| DE Agg | Data Aggregate (Aggregated Data Element) |
| Feat | Feature |
| Feat Agg | Feature Aggregate |
| GF | Global Function |
| GV | Global Variable |
| RTP | Runtime Parameter |
| QP | Quality Profile |
| SRR | Single Record Review |
| MD | Monitoring Dashboard |
| PP | Permissible Purpose |
Common acronyms
Section titled “Common acronyms”SRR : Single Record Review.
PSI / CSI / KS / AUC / ROC : See definitions above under Monitoring, metrics, and alerts.
DPD : Days Past Due. The number of days a loan payment is late. Often used as the basis for Bad Rate definitions (for example, “30+ DPD at 6 months”).
LOS : Loan Origination System. The downstream production system that Corridor artifacts deploy into.
MRM : Model Risk Management. The team or function that typically owns the Approved gate on Model Approval Workflows.
PII : Personally Identifiable Information. A common Permissible Purpose tag.
See also
Section titled “See also”- Common Troubleshooting: symptom-to-fix lookup for errors.
- FAQs: answers to frequent questions.
- Getting Started: guided introduction to these concepts.
Was this page helpful?
Thanks for the feedback.