Float Tiers

Inside Predictor.RunAndSave, immediately after SageMaker returns the risk score — same choke point, good-standing gate, and fail-closed behavior as the predictor. No score means no assignment. The result is snapshotted onto the evaluation’s MLResult (float_tier_assignment), so every later call sharing the evaluation carries the same assignment without re-deriving it from live flags.

The table is keyed by float rank — the same rank the predictor persists as MLResult.rank: rank n means the user is requesting their nth float (prior_borrow_count + 1 from the RuleFloatRankV3 outcome, nil treated as 0, capped at 8). The rank is not persisted on the snapshot (it duplicates MLResult.rank); the assignment metric tags it directly.

FloatTierTable (pkg/underwriting_model/float_tier_table.go) is a list of entries, each holding a band ladder (tier letter, amount_cents, min_score cutoff) and a guardrails switch (omitted means off). Band amounts are cents, unlike float amounts and profile ladder tiers (dollars) — readers convert at the boundary. An entry either names a specific float_rank or — with no float_rank — is the default entry covering every rank without its own. Lookup takes the rank’s specific entry first, then the default. Band order in the config doesn’t matter, but a ladder’s amounts must descend along with its cutoffs — a band with a higher cutoff never offers less than one below it. The score picks the band with the highest min_score it meets; a score below the entry’s lowest cutoff is denied, no exceptions.

The table is GrowthBook-configurable (underwriting.float_tiers_table.config); on load/parse failure, an empty table, or no entry covering the rank, the hardcoded defaultFloatTierTable applies — see the source for the current entries and values. Which ranks get their own entry, band counts, amounts, cutoffs, and guardrail applicability are all GrowthBook edits, not code changes; every configured amount must be 100x a ladder tier.

Computed only under tier-table entries with guardrails on, and only when the user has a repaid prior float — every trigger is defined on the last repayment (RuleFloatRank's last_repaid_amount / last_repaid_days_late features, where days late = payback − due in calendar days; the feature’s dollar amount is converted to cents on read). The policy is a deliberate asymmetric ratchet layered on top of the score — gains stick, losses snap. By the last repaid float’s lateness:

A score below the entry’s lowest cutoff denies regardless of trigger (denied_floor — it also wins the label when the revoked trigger would deny too). Triggers change only the policy’s amount (guardrail_amount_cents, 0 when the policy denies); tier/tier_amount_cents always record what the score alone assigned (revoked denials keep them, floor denials carry none).

The on-time ratchet’s "current offer" is the assignment offer — assigned_amount_cents, whatever produced it — recorded when the user’s last float was funded: the float-created handler copies each funded float’s assignment onto its permanent HistoricalEvaluation, and the most recent float-funded record is read back per fresh assignment (funded loans are skipped; resolved only for guardrail-on entries). A float-funded record with no assignment on it — the funding predates float tiers, or the model didn’t score that evaluation — falls back to the funded amount itself, normalized for retired amounts ($75 reads as the $80 band), so established borrowers keep their ratchet through the transition. There is no standing offer — the trigger formulas then run on the target alone — when the user has never funded a float (such users sit in the rank-1 entry anyway), the last funded float was funded over a denial (bypass), or the lookup fails. The resolved input is snapshotted as current_offer_amount_cents.

underwriting.float_tiers.rollout (per-user, flags) gates whether the assignment is applied. It is read once, when the assignment is snapshotted, and persisted as the snapshot’s authoritative_v2 bool; every later reader trusts the snapshot, never the live flag — the same snapshot-reuse contract as the predictor’s authoritative (and for the same reasons: in-flight consistency across calls sharing an evaluation, and settlement keying off the same persisted field).

underwriting.float_tiers_guardrails.rollout (per-user) gates whether the trigger policy’s outcome is what the assignment offers. It is read at the same point and persisted as guardrails_applied, under the same snapshot-reuse contract. The two flags are independent in code: the guardrails flag shapes what the assignment offers, the rollout flag whether that offer is the user’s decision — a user in the guardrails rollout alone carries a guardrailed shadow assignment with no user-facing effect.

Enforcement is independent of the predictor’s authoritative flags: inference and the MLResult save do not depend on them, so a user whose approve/deny is still rulebook-decided (model in shadow mode) can carry — and be decided by — an enforced assignment. A score is the one hard dependency: no score means no snapshot and nothing to enforce.

Source: pkg/datadog/metrics.go