A role describes what an attribute is, and therefore determines what an observed effect on it may become. High lift on a bureau attribute can support a candidate rule; the same lift on loan purpose raises a pricing question, not a reason to decline every applicant who chose it. Roles keep those interpretations separate.
- The six roles
- Where the roles come from
- Editing the map
- Suppressed attributes
- Product and channel become segments
- What to check first
The six roles
| Role | What it means | What analysis may do with it |
|---|---|---|
| Risk | Something about the applicant's creditworthiness: bureau values, scores, arrears, derived ratios | Candidate rules, cutoffs, scorecard characteristics |
| Operational | Something about how the application arrived: fraud signals, device, session | Candidate rules, and usually a fraud tooling question rather than a credit one |
| Product | Something you chose to offer: amount, term, purpose, product code | Segments and cutoff dimensions, never a decline rule |
| Channel | Where the application came from: partner, campaign, source | Segments and mix analysis, never a decline rule |
| Restricted | Protected characteristics: gender, nationality, ethnicity, religion, marital status | Nothing. It is dropped before profiling and the drop is recorded |
| Identifier | Values that identify rather than describe: application id, customer id, and anything that is really the answer in disguise | Nothing. Its "lift" is memory, not prediction |
An attribute that has not been classified is Unknown, but unknown attributes remain available for mining. The map records only classifications it can defend, so an unfamiliar name does not quietly cause an attribute to be demoted.
Where the roles come from
The roles come from three sources, applied in order of authority:
- What you saved. A role you set is final and is never overwritten.
- A classification pass, where one has run for your account.
- Naming conventions, which provide the fallback. Paths under
$.bureau.,$.credit.,$.score.,$.risk.and$.derived.seed as risk;$.product.and$.offer.as product;$.channel.,$.campaign.and$.marketing.as channel;$.fraud.,$.device.and$.session.as operational;$.outcome.as identifier. Leaf names add a few more conventions, soloan_amountandloan_term_monthsseed as product,application_idandcustomer_idas identifier, andgender,sex,nationality,ethnicity,race,religionandmarital_statusas restricted wherever they sit.
These conventions provide a starting point, but they are often wrong about the meaning of your data. The editable map lets you correct them.
Editing the map
After a mining run finishes, open Attribute roles under the findings to review every attribute the run profiled, along with its Role and Source. The source shows whether the role came from the naming rules or from you; change any incorrect roles, then press Save roles. Saved roles apply to every later run, including policy mining pipelines.
Check first for any attribute whose value is derived from the outcome you are predicting, because it can look like an unusually strong predictor precisely because it contains the answer. Mark it Identifier once, and it will no longer compete with the attributes that genuinely describe the application.
Suppressed attributes
Restricted and identifier attributes are removed before candidates are formed, and the removal appears under Suppressed attributes together with the role and its source. This record matters: a silent drop gives you no way to distinguish an excluded attribute from one that was never present.
Nothing suppressed reaches findings, WOE sheets, the scorecard fit or the record.
Product and channel become segments
Product and channel attributes are not simply excluded; analysis gives them a different job by using them as dimensions for approval-rate and bad-rate cuts at your cutoff, per product and per channel. Policy mining presents this as Cutoff by segment, and the record lists the dimensions under Segmentations.
The distinction is practical. "Decline this partner's applications" is a rule you will never write, whereas "at this cutoff, that partner is approved at 71% with twice the bad rate" starts a conversation about pricing, mix and monitoring.
What to check first
- Anything that is really the answer: expected loss, a stored probability, a score computed from the outcome. Mark it Identifier.
- Protected characteristics under names the conventions do not recognise. Mark them Restricted.
- Risk attributes sitting under a product-shaped path, or the other way round, which is common when a request payload groups by source system rather than by meaning.