Skip to content

Design: segmented scorecards and artifact suites #13

Description

@orgoca

Problem

Real portfolios run segmented scorecards: thin file vs thick file, new vs existing customer, by product. One CompileML artifact governs one population. There is currently no answer to:

  • How do I govern a suite of six artifacts as one policy?
  • How do I route an applicant to the right artifact, deterministically, with the routing itself auditable?
  • How do bands stay comparable across segments (does G07 mean the same risk in both)?
  • What does a champion/challenger comparison look like across a suite?

Why this is a design issue, not an implementation issue

The obvious answer — "just make N artifacts" — loses the property that makes CompileML worth using: a single hashed object that is the decision. If routing lives in someone's Python glue, the glue is now an unaudited part of the decision, which is precisely the failure mode this project exists to prevent.

Options worth exploring

  1. Suite artifact: a parent document with deterministic routing rules and child artifact hashes. Routing becomes part of the hashed contract.
  2. Segment as a feature: one artifact, segment indicator as an input. Simple, but constrains model structure and can fight monotonicity.
  3. Out of scope: declare routing the caller's responsibility, and document the boundary honestly.

Ask

Discussion first, no PR. Input especially welcome from anyone who has governed a segmented suite in production — what did the model risk function actually require?

Metadata

Metadata

Assignees

No one assigned

    Labels

    credit-riskDomain requirement from regulated lending practicedesignNeeds a design decision before implementation

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions