Disposal rate method

[henrydingliu]

Summary of Changes

Implement the disposal rate method from Friedland FreqSev Approach 3 as an adjustment estimator

Related GitHub Issue(s)

closes#931

Additional Context for Reviewers

• Created a DisposalMixin for the new adjustment estimator and Triangle

  • Berquist-Sherman also uses disposal rate. will leave harmonization to another PR
  • We may eventually want to split Common into DevelopmentMixin, IncrementalMixin, etc.

• Added disposal_rate_tri to Triangle, mimicking age_to_age/link_ratio

• Added is_disposal_rate to Triangle, in order to differentiate the proper path in incr_to_cum and cum_to_incr

• I passed tests locally for both code (uv run pytest) and documentation changes (uv run jb build docs --builder=custom --custom-builder=doctest)

---

Note

Medium Risk
Changes core triangle cum/incr behavior for a new pattern type and introduces a reserving path that overwrites projected triangles from ultimates; mistakes could affect forecast outputs but scope is isolated behind disposal-rate flags and new estimator usage.

Overview
Adds Friedland disposal-rate reserving as public DisposalRate, which fits a cumulative “% of ultimate” emergence pattern from a triangle and a required sample_weight ultimate, then projects the lower triangle via derived LDFs.

Triangle gains disposal_rate_tri, an is_disposal_rate flag, and DisposalMixin (disposal_rate_ / incr_disposal_rate_) mixed into TriangleBase. incr_to_cum / cum_to_incr now treat disposal-rate patterns as additive cumulative ratios instead of multiplicative link-ratio patterns.

MethodBase.validate_weight is refactored to a @staticmethod for reuse from DisposalRate. Tests cover Friedland textbook fidelity, chainladder parity, sparse backends, and required-weight validation; DisposalRate is wired into the public API.

^{Reviewed by Cursor Bugbot for commit 210ec67. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 97.39130% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.70%. Comparing base (1dddf97) to head (210ec67).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
chainladder/adjustments/disposal.py	97.43%	1 Missing and 1 partial ⚠️
chainladder/core/triangle.py	96.15%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #1022 +/- ##
==========================================
+ Coverage 89.47% 89.70% +0.22% 
==========================================
Files 91 91 Lines 5284 5343 +59 Branches 681 692 +11 ==========================================
+ Hits 4728 4793 +65 + Misses 388 384 -4 + Partials 168 166 -2 

Flag	Coverage Δ
unittests	89.70% <97.39%> (+0.22%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[genedan]

Just letting you guys know that I can look through this today.

[genedan]

I wonder if we should be using a higher level of precision than what Friedland has. That is, have the expectation values at the precision of the atol fixture.

Since this test passes, I think the numbers are correct, so we'd just change the rounding to 4 places and the expectation values at 4 decimals.

Interestingly, Friedland doesn't round on page 253 and also doesn't show the precision, so it looks like the paper isn't 100% consistent in that regard.

[henrydingliu]

i'll add a new assertion statement with round(,4).

[henrydingliu]

got to full matching at 3 decimals.

[genedan]

Friedland has 43 incremental claims at AY 2008 at 72 months. I calculated (609 - 127) / (1 - .2) (.862 - .791) = 42.7775.

[henrydingliu]

fat finger. will fix

[genedan]

Small typo in "examine"

[henrydingliu]

will fix

[genedan]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

[henrydingliu]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

My current approach is to build enough basic functionality within the package such that they can be manually linked together to recreate friedland. That's why I split out TriangleWeight in #941, to handle the different regression periods for the severity trend selections. Once you help me work out the kinks on this, the next blocker is #1024. (Was really hoping one of the younger contributors could help me out on that one; reading latex formulas for #952 gave me enough headaches for this calendar year). if i run into more blockers after that, i'll create more issues.

i haven't thought too much about long term if all this piecemeal functionality should be combined into a new freqsev method. we can decide as a collective once we can see a completed chapter 11 recreation. maybe it'll be too much hacking (i tried hacking the severity regression periods but it got too ugly) and we'll want to do some more integration. but if it's like, iono, a dozen or so lines and it's all using the public API (no numpy hacking tri.values), it could be a cool example of how to be innovative with the package. right now we are building a lego model based on the instructions. but the magic comes from combining the pieces in weird and unexpected ways. i mean, that's also the whole end goal of having a well-typed, well-doc'd API.

there is one major refactor that i'm fairly certain i want to push for at some point, but can't yet clearly articulate the right requirements. and that's the entire votingchainladder and pipeline workflow folder of the package. within friedland, and also fairly common in actual practice, actuaries are using reported and paid to estimate the same loss ultimate or using reported and closed to estimate the same count ultimate. votingchainladder currently doesn't support weighing between reported triangle and paid triangle. pipeline currently doesn't support using reported ultimate to recast closed disposal rate. so i think for votingchainladder and pipeline to be more than window dressing, it needs to accommodate multi-triangle interaction. and then however we refactor votingchainladder and pipeline will likely result in some further harmonizing on all the dev transformers, adjustment transformers, and ibnr predictors. not sure if all this would be 1.0 work. we can decide after an initial friedland recreation.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 335ddca. Configure here.}

[github-actions]

Pyright Type Completeness

View the full pyright --verifytypes output for this commit

Project (full chainladder package, at this PR's head): 14.1% of exported symbols fully typed (175 / 1237)

	Known	Ambiguous	Unknown	Total
Project (head)	175	107	955	1237

Other symbols referenced but not exported by chainladder: 13

	Known	Ambiguous	Unknown	Total
Other (head)	3	1	9	13

Symbols without documentation:

• Functions without docstring: 314
• Functions without default param: 0
• Classes without docstring: 10

Patch (exported symbols added or changed by this PR): 40.0% fully typed (12 / 30)

	Known	Ambiguous	Unknown	Total
Patch	12	0	18	30

Patch symbol details

Symbol	Status	Change
chainladder.adjustments.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.incr_disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.X_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.__init__	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.average	✅ known	new
chainladder.adjustments.disposal.DisposalRate.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.disposal_w_	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.drop_above	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_below	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_high	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_low	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_valuation	✅ known	new
chainladder.adjustments.disposal.DisposalRate.fit	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.fit_transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.n_periods	✅ known	new
chainladder.adjustments.disposal.DisposalRate.preserve	✅ known	new
chainladder.adjustments.disposal.DisposalRate.transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.xp	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_cl_parity	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_friedland_fidelity	✅ known	new
chainladder.adjustments.tests.test_disposal.test_no_disposal_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_no_weight_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_setting_incr	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_sparse_transform	❌ unknown	new
chainladder.core.triangle.Triangle.disposal_rate_tri	✅ known	new
chainladder.core.triangle.Triangle.is_disposal_rate	✅ known	new

[henrydingliu]

Summary of Changes

Implement the disposal rate method from Friedland FreqSev Approach 3 as an adjustment estimator

Related GitHub Issue(s)

closes#931

Additional Context for Reviewers

• Created a DisposalMixin for the new adjustment estimator and Triangle

  • Berquist-Sherman also uses disposal rate. will leave harmonization to another PR
  • We may eventually want to split Common into DevelopmentMixin, IncrementalMixin, etc.

• Added disposal_rate_tri to Triangle, mimicking age_to_age/link_ratio

• Added is_disposal_rate to Triangle, in order to differentiate the proper path in incr_to_cum and cum_to_incr

• I passed tests locally for both code (uv run pytest) and documentation changes (uv run jb build docs --builder=custom --custom-builder=doctest)

---

Note

Medium Risk
Changes core triangle cum/incr behavior for a new pattern type and introduces a reserving path that overwrites projected triangles from ultimates; mistakes could affect forecast outputs but scope is isolated behind disposal-rate flags and new estimator usage.

Overview
Adds Friedland disposal-rate reserving as public DisposalRate, which fits a cumulative “% of ultimate” emergence pattern from a triangle and a required sample_weight ultimate, then projects the lower triangle via derived LDFs.

Triangle gains disposal_rate_tri, an is_disposal_rate flag, and DisposalMixin (disposal_rate_ / incr_disposal_rate_) mixed into TriangleBase. incr_to_cum / cum_to_incr now treat disposal-rate patterns as additive cumulative ratios instead of multiplicative link-ratio patterns.

MethodBase.validate_weight is refactored to a @staticmethod for reuse from DisposalRate. Tests cover Friedland textbook fidelity, chainladder parity, sparse backends, and required-weight validation; DisposalRate is wired into the public API.

^{Reviewed by Cursor Bugbot for commit 210ec67. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 97.39130% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.70%. Comparing base (1dddf97) to head (210ec67).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
chainladder/adjustments/disposal.py	97.43%	1 Missing and 1 partial ⚠️
chainladder/core/triangle.py	96.15%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #1022 +/- ##
==========================================
+ Coverage 89.47% 89.70% +0.22% 
==========================================
Files 91 91 Lines 5284 5343 +59 Branches 681 692 +11 ==========================================
+ Hits 4728 4793 +65 + Misses 388 384 -4 + Partials 168 166 -2 

Flag	Coverage Δ
unittests	89.70% <97.39%> (+0.22%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[genedan]

Just letting you guys know that I can look through this today.

[genedan]

I wonder if we should be using a higher level of precision than what Friedland has. That is, have the expectation values at the precision of the atol fixture.

Since this test passes, I think the numbers are correct, so we'd just change the rounding to 4 places and the expectation values at 4 decimals.

Interestingly, Friedland doesn't round on page 253 and also doesn't show the precision, so it looks like the paper isn't 100% consistent in that regard.

[henrydingliu]

i'll add a new assertion statement with round(,4).

[henrydingliu]

got to full matching at 3 decimals.

[genedan]

Friedland has 43 incremental claims at AY 2008 at 72 months. I calculated (609 - 127) / (1 - .2) (.862 - .791) = 42.7775.

[henrydingliu]

fat finger. will fix

[genedan]

Small typo in "examine"

[henrydingliu]

will fix

[genedan]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

[henrydingliu]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

My current approach is to build enough basic functionality within the package such that they can be manually linked together to recreate friedland. That's why I split out TriangleWeight in #941, to handle the different regression periods for the severity trend selections. Once you help me work out the kinks on this, the next blocker is #1024. (Was really hoping one of the younger contributors could help me out on that one; reading latex formulas for #952 gave me enough headaches for this calendar year). if i run into more blockers after that, i'll create more issues.

i haven't thought too much about long term if all this piecemeal functionality should be combined into a new freqsev method. we can decide as a collective once we can see a completed chapter 11 recreation. maybe it'll be too much hacking (i tried hacking the severity regression periods but it got too ugly) and we'll want to do some more integration. but if it's like, iono, a dozen or so lines and it's all using the public API (no numpy hacking tri.values), it could be a cool example of how to be innovative with the package. right now we are building a lego model based on the instructions. but the magic comes from combining the pieces in weird and unexpected ways. i mean, that's also the whole end goal of having a well-typed, well-doc'd API.

there is one major refactor that i'm fairly certain i want to push for at some point, but can't yet clearly articulate the right requirements. and that's the entire votingchainladder and pipeline workflow folder of the package. within friedland, and also fairly common in actual practice, actuaries are using reported and paid to estimate the same loss ultimate or using reported and closed to estimate the same count ultimate. votingchainladder currently doesn't support weighing between reported triangle and paid triangle. pipeline currently doesn't support using reported ultimate to recast closed disposal rate. so i think for votingchainladder and pipeline to be more than window dressing, it needs to accommodate multi-triangle interaction. and then however we refactor votingchainladder and pipeline will likely result in some further harmonizing on all the dev transformers, adjustment transformers, and ibnr predictors. not sure if all this would be 1.0 work. we can decide after an initial friedland recreation.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 335ddca. Configure here.}

[github-actions]

Pyright Type Completeness

View the full pyright --verifytypes output for this commit

Project (full chainladder package, at this PR's head): 14.1% of exported symbols fully typed (175 / 1237)

	Known	Ambiguous	Unknown	Total
Project (head)	175	107	955	1237

Other symbols referenced but not exported by chainladder: 13

	Known	Ambiguous	Unknown	Total
Other (head)	3	1	9	13

Symbols without documentation:

• Functions without docstring: 314
• Functions without default param: 0
• Classes without docstring: 10

Patch (exported symbols added or changed by this PR): 40.0% fully typed (12 / 30)

	Known	Ambiguous	Unknown	Total
Patch	12	0	18	30

Patch symbol details

Symbol	Status	Change
chainladder.adjustments.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.incr_disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.X_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.__init__	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.average	✅ known	new
chainladder.adjustments.disposal.DisposalRate.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.disposal_w_	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.drop_above	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_below	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_high	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_low	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_valuation	✅ known	new
chainladder.adjustments.disposal.DisposalRate.fit	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.fit_transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.n_periods	✅ known	new
chainladder.adjustments.disposal.DisposalRate.preserve	✅ known	new
chainladder.adjustments.disposal.DisposalRate.transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.xp	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_cl_parity	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_friedland_fidelity	✅ known	new
chainladder.adjustments.tests.test_disposal.test_no_disposal_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_no_weight_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_setting_incr	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_sparse_transform	❌ unknown	new
chainladder.core.triangle.Triangle.disposal_rate_tri	✅ known	new
chainladder.core.triangle.Triangle.is_disposal_rate	✅ known	new

[henrydingliu]

Summary of Changes

Implement the disposal rate method from Friedland FreqSev Approach 3 as an adjustment estimator

Related GitHub Issue(s)

closes#931

Additional Context for Reviewers

• Created a DisposalMixin for the new adjustment estimator and Triangle

  • Berquist-Sherman also uses disposal rate. will leave harmonization to another PR
  • We may eventually want to split Common into DevelopmentMixin, IncrementalMixin, etc.

• Added disposal_rate_tri to Triangle, mimicking age_to_age/link_ratio

• Added is_disposal_rate to Triangle, in order to differentiate the proper path in incr_to_cum and cum_to_incr

• I passed tests locally for both code (uv run pytest) and documentation changes (uv run jb build docs --builder=custom --custom-builder=doctest)

---

Note

Medium Risk
Changes core triangle cum/incr behavior for a new pattern type and introduces a reserving path that overwrites projected triangles from ultimates; mistakes could affect forecast outputs but scope is isolated behind disposal-rate flags and new estimator usage.

Overview
Adds Friedland disposal-rate reserving as public DisposalRate, which fits a cumulative “% of ultimate” emergence pattern from a triangle and a required sample_weight ultimate, then projects the lower triangle via derived LDFs.

Triangle gains disposal_rate_tri, an is_disposal_rate flag, and DisposalMixin (disposal_rate_ / incr_disposal_rate_) mixed into TriangleBase. incr_to_cum / cum_to_incr now treat disposal-rate patterns as additive cumulative ratios instead of multiplicative link-ratio patterns.

MethodBase.validate_weight is refactored to a @staticmethod for reuse from DisposalRate. Tests cover Friedland textbook fidelity, chainladder parity, sparse backends, and required-weight validation; DisposalRate is wired into the public API.

^{Reviewed by Cursor Bugbot for commit 210ec67. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 97.39130% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.70%. Comparing base (1dddf97) to head (210ec67).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
chainladder/adjustments/disposal.py	97.43%	1 Missing and 1 partial ⚠️
chainladder/core/triangle.py	96.15%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #1022 +/- ##
==========================================
+ Coverage 89.47% 89.70% +0.22% 
==========================================
Files 91 91 Lines 5284 5343 +59 Branches 681 692 +11 ==========================================
+ Hits 4728 4793 +65 + Misses 388 384 -4 + Partials 168 166 -2 

Flag	Coverage Δ
unittests	89.70% <97.39%> (+0.22%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[genedan]

Just letting you guys know that I can look through this today.

[genedan]

I wonder if we should be using a higher level of precision than what Friedland has. That is, have the expectation values at the precision of the atol fixture.

Since this test passes, I think the numbers are correct, so we'd just change the rounding to 4 places and the expectation values at 4 decimals.

Interestingly, Friedland doesn't round on page 253 and also doesn't show the precision, so it looks like the paper isn't 100% consistent in that regard.

[henrydingliu]

i'll add a new assertion statement with round(,4).

[henrydingliu]

got to full matching at 3 decimals.

[genedan]

Friedland has 43 incremental claims at AY 2008 at 72 months. I calculated (609 - 127) / (1 - .2) (.862 - .791) = 42.7775.

[henrydingliu]

fat finger. will fix

[genedan]

Small typo in "examine"

[henrydingliu]

will fix

[genedan]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

[henrydingliu]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

My current approach is to build enough basic functionality within the package such that they can be manually linked together to recreate friedland. That's why I split out TriangleWeight in #941, to handle the different regression periods for the severity trend selections. Once you help me work out the kinks on this, the next blocker is #1024. (Was really hoping one of the younger contributors could help me out on that one; reading latex formulas for #952 gave me enough headaches for this calendar year). if i run into more blockers after that, i'll create more issues.

i haven't thought too much about long term if all this piecemeal functionality should be combined into a new freqsev method. we can decide as a collective once we can see a completed chapter 11 recreation. maybe it'll be too much hacking (i tried hacking the severity regression periods but it got too ugly) and we'll want to do some more integration. but if it's like, iono, a dozen or so lines and it's all using the public API (no numpy hacking tri.values), it could be a cool example of how to be innovative with the package. right now we are building a lego model based on the instructions. but the magic comes from combining the pieces in weird and unexpected ways. i mean, that's also the whole end goal of having a well-typed, well-doc'd API.

there is one major refactor that i'm fairly certain i want to push for at some point, but can't yet clearly articulate the right requirements. and that's the entire votingchainladder and pipeline workflow folder of the package. within friedland, and also fairly common in actual practice, actuaries are using reported and paid to estimate the same loss ultimate or using reported and closed to estimate the same count ultimate. votingchainladder currently doesn't support weighing between reported triangle and paid triangle. pipeline currently doesn't support using reported ultimate to recast closed disposal rate. so i think for votingchainladder and pipeline to be more than window dressing, it needs to accommodate multi-triangle interaction. and then however we refactor votingchainladder and pipeline will likely result in some further harmonizing on all the dev transformers, adjustment transformers, and ibnr predictors. not sure if all this would be 1.0 work. we can decide after an initial friedland recreation.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 335ddca. Configure here.}

[github-actions]

Pyright Type Completeness

View the full pyright --verifytypes output for this commit

Project (full chainladder package, at this PR's head): 14.1% of exported symbols fully typed (175 / 1237)

	Known	Ambiguous	Unknown	Total
Project (head)	175	107	955	1237

Other symbols referenced but not exported by chainladder: 13

	Known	Ambiguous	Unknown	Total
Other (head)	3	1	9	13

Symbols without documentation:

• Functions without docstring: 314
• Functions without default param: 0
• Classes without docstring: 10

Patch (exported symbols added or changed by this PR): 40.0% fully typed (12 / 30)

	Known	Ambiguous	Unknown	Total
Patch	12	0	18	30

Patch symbol details

Symbol	Status	Change
chainladder.adjustments.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.incr_disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.X_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.__init__	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.average	✅ known	new
chainladder.adjustments.disposal.DisposalRate.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.disposal_w_	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.drop_above	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_below	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_high	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_low	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_valuation	✅ known	new
chainladder.adjustments.disposal.DisposalRate.fit	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.fit_transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.n_periods	✅ known	new
chainladder.adjustments.disposal.DisposalRate.preserve	✅ known	new
chainladder.adjustments.disposal.DisposalRate.transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.xp	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_cl_parity	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_friedland_fidelity	✅ known	new
chainladder.adjustments.tests.test_disposal.test_no_disposal_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_no_weight_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_setting_incr	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_sparse_transform	❌ unknown	new
chainladder.core.triangle.Triangle.disposal_rate_tri	✅ known	new
chainladder.core.triangle.Triangle.is_disposal_rate	✅ known	new

[henrydingliu]

Summary of Changes

Implement the disposal rate method from Friedland FreqSev Approach 3 as an adjustment estimator

Related GitHub Issue(s)

closes#931

Additional Context for Reviewers

• Created a DisposalMixin for the new adjustment estimator and Triangle

  • Berquist-Sherman also uses disposal rate. will leave harmonization to another PR
  • We may eventually want to split Common into DevelopmentMixin, IncrementalMixin, etc.

• Added disposal_rate_tri to Triangle, mimicking age_to_age/link_ratio

• Added is_disposal_rate to Triangle, in order to differentiate the proper path in incr_to_cum and cum_to_incr

• I passed tests locally for both code (uv run pytest) and documentation changes (uv run jb build docs --builder=custom --custom-builder=doctest)

---

Note

Medium Risk
Changes core triangle cum/incr behavior for a new pattern type and introduces a reserving path that overwrites projected triangles from ultimates; mistakes could affect forecast outputs but scope is isolated behind disposal-rate flags and new estimator usage.

Overview
Adds Friedland disposal-rate reserving as public DisposalRate, which fits a cumulative “% of ultimate” emergence pattern from a triangle and a required sample_weight ultimate, then projects the lower triangle via derived LDFs.

Triangle gains disposal_rate_tri, an is_disposal_rate flag, and DisposalMixin (disposal_rate_ / incr_disposal_rate_) mixed into TriangleBase. incr_to_cum / cum_to_incr now treat disposal-rate patterns as additive cumulative ratios instead of multiplicative link-ratio patterns.

MethodBase.validate_weight is refactored to a @staticmethod for reuse from DisposalRate. Tests cover Friedland textbook fidelity, chainladder parity, sparse backends, and required-weight validation; DisposalRate is wired into the public API.

^{Reviewed by Cursor Bugbot for commit 210ec67. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 97.39130% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.70%. Comparing base (1dddf97) to head (210ec67).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
chainladder/adjustments/disposal.py	97.43%	1 Missing and 1 partial ⚠️
chainladder/core/triangle.py	96.15%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #1022 +/- ##
==========================================
+ Coverage 89.47% 89.70% +0.22% 
==========================================
Files 91 91 Lines 5284 5343 +59 Branches 681 692 +11 ==========================================
+ Hits 4728 4793 +65 + Misses 388 384 -4 + Partials 168 166 -2 

Flag	Coverage Δ
unittests	89.70% <97.39%> (+0.22%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[genedan]

Just letting you guys know that I can look through this today.

[genedan]

I wonder if we should be using a higher level of precision than what Friedland has. That is, have the expectation values at the precision of the atol fixture.

Since this test passes, I think the numbers are correct, so we'd just change the rounding to 4 places and the expectation values at 4 decimals.

Interestingly, Friedland doesn't round on page 253 and also doesn't show the precision, so it looks like the paper isn't 100% consistent in that regard.

[henrydingliu]

i'll add a new assertion statement with round(,4).

[henrydingliu]

got to full matching at 3 decimals.

[genedan]

Friedland has 43 incremental claims at AY 2008 at 72 months. I calculated (609 - 127) / (1 - .2) (.862 - .791) = 42.7775.

[henrydingliu]

fat finger. will fix

[genedan]

Small typo in "examine"

[henrydingliu]

will fix

[genedan]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

[henrydingliu]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

My current approach is to build enough basic functionality within the package such that they can be manually linked together to recreate friedland. That's why I split out TriangleWeight in #941, to handle the different regression periods for the severity trend selections. Once you help me work out the kinks on this, the next blocker is #1024. (Was really hoping one of the younger contributors could help me out on that one; reading latex formulas for #952 gave me enough headaches for this calendar year). if i run into more blockers after that, i'll create more issues.

i haven't thought too much about long term if all this piecemeal functionality should be combined into a new freqsev method. we can decide as a collective once we can see a completed chapter 11 recreation. maybe it'll be too much hacking (i tried hacking the severity regression periods but it got too ugly) and we'll want to do some more integration. but if it's like, iono, a dozen or so lines and it's all using the public API (no numpy hacking tri.values), it could be a cool example of how to be innovative with the package. right now we are building a lego model based on the instructions. but the magic comes from combining the pieces in weird and unexpected ways. i mean, that's also the whole end goal of having a well-typed, well-doc'd API.

there is one major refactor that i'm fairly certain i want to push for at some point, but can't yet clearly articulate the right requirements. and that's the entire votingchainladder and pipeline workflow folder of the package. within friedland, and also fairly common in actual practice, actuaries are using reported and paid to estimate the same loss ultimate or using reported and closed to estimate the same count ultimate. votingchainladder currently doesn't support weighing between reported triangle and paid triangle. pipeline currently doesn't support using reported ultimate to recast closed disposal rate. so i think for votingchainladder and pipeline to be more than window dressing, it needs to accommodate multi-triangle interaction. and then however we refactor votingchainladder and pipeline will likely result in some further harmonizing on all the dev transformers, adjustment transformers, and ibnr predictors. not sure if all this would be 1.0 work. we can decide after an initial friedland recreation.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 335ddca. Configure here.}

[github-actions]

Pyright Type Completeness

View the full pyright --verifytypes output for this commit

Project (full chainladder package, at this PR's head): 14.1% of exported symbols fully typed (175 / 1237)

	Known	Ambiguous	Unknown	Total
Project (head)	175	107	955	1237

Other symbols referenced but not exported by chainladder: 13

	Known	Ambiguous	Unknown	Total
Other (head)	3	1	9	13

Symbols without documentation:

• Functions without docstring: 314
• Functions without default param: 0
• Classes without docstring: 10

Patch (exported symbols added or changed by this PR): 40.0% fully typed (12 / 30)

	Known	Ambiguous	Unknown	Total
Patch	12	0	18	30

Patch symbol details

Symbol	Status	Change
chainladder.adjustments.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.incr_disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.X_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.__init__	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.average	✅ known	new
chainladder.adjustments.disposal.DisposalRate.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.disposal_w_	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.drop_above	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_below	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_high	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_low	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_valuation	✅ known	new
chainladder.adjustments.disposal.DisposalRate.fit	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.fit_transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.n_periods	✅ known	new
chainladder.adjustments.disposal.DisposalRate.preserve	✅ known	new
chainladder.adjustments.disposal.DisposalRate.transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.xp	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_cl_parity	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_friedland_fidelity	✅ known	new
chainladder.adjustments.tests.test_disposal.test_no_disposal_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_no_weight_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_setting_incr	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_sparse_transform	❌ unknown	new
chainladder.core.triangle.Triangle.disposal_rate_tri	✅ known	new
chainladder.core.triangle.Triangle.is_disposal_rate	✅ known	new

[henrydingliu]

Summary of Changes

Implement the disposal rate method from Friedland FreqSev Approach 3 as an adjustment estimator

Related GitHub Issue(s)

closes#931

Additional Context for Reviewers

• Created a DisposalMixin for the new adjustment estimator and Triangle

  • Berquist-Sherman also uses disposal rate. will leave harmonization to another PR
  • We may eventually want to split Common into DevelopmentMixin, IncrementalMixin, etc.

• Added disposal_rate_tri to Triangle, mimicking age_to_age/link_ratio

• Added is_disposal_rate to Triangle, in order to differentiate the proper path in incr_to_cum and cum_to_incr

• I passed tests locally for both code (uv run pytest) and documentation changes (uv run jb build docs --builder=custom --custom-builder=doctest)

---

Note

Medium Risk
Changes core triangle cum/incr behavior for a new pattern type and introduces a reserving path that overwrites projected triangles from ultimates; mistakes could affect forecast outputs but scope is isolated behind disposal-rate flags and new estimator usage.

Overview
Adds Friedland disposal-rate reserving as public DisposalRate, which fits a cumulative “% of ultimate” emergence pattern from a triangle and a required sample_weight ultimate, then projects the lower triangle via derived LDFs.

Triangle gains disposal_rate_tri, an is_disposal_rate flag, and DisposalMixin (disposal_rate_ / incr_disposal_rate_) mixed into TriangleBase. incr_to_cum / cum_to_incr now treat disposal-rate patterns as additive cumulative ratios instead of multiplicative link-ratio patterns.

MethodBase.validate_weight is refactored to a @staticmethod for reuse from DisposalRate. Tests cover Friedland textbook fidelity, chainladder parity, sparse backends, and required-weight validation; DisposalRate is wired into the public API.

^{Reviewed by Cursor Bugbot for commit 210ec67. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 97.39130% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.70%. Comparing base (1dddf97) to head (210ec67).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
chainladder/adjustments/disposal.py	97.43%	1 Missing and 1 partial ⚠️
chainladder/core/triangle.py	96.15%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #1022 +/- ##
==========================================
+ Coverage 89.47% 89.70% +0.22% 
==========================================
Files 91 91 Lines 5284 5343 +59 Branches 681 692 +11 ==========================================
+ Hits 4728 4793 +65 + Misses 388 384 -4 + Partials 168 166 -2 

Flag	Coverage Δ
unittests	89.70% <97.39%> (+0.22%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[genedan]

Just letting you guys know that I can look through this today.

[genedan]

I wonder if we should be using a higher level of precision than what Friedland has. That is, have the expectation values at the precision of the atol fixture.

Since this test passes, I think the numbers are correct, so we'd just change the rounding to 4 places and the expectation values at 4 decimals.

Interestingly, Friedland doesn't round on page 253 and also doesn't show the precision, so it looks like the paper isn't 100% consistent in that regard.

[henrydingliu]

i'll add a new assertion statement with round(,4).

[henrydingliu]

got to full matching at 3 decimals.

[genedan]

Friedland has 43 incremental claims at AY 2008 at 72 months. I calculated (609 - 127) / (1 - .2) (.862 - .791) = 42.7775.

[henrydingliu]

fat finger. will fix

[genedan]

Small typo in "examine"

[henrydingliu]

will fix

[genedan]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

[henrydingliu]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

My current approach is to build enough basic functionality within the package such that they can be manually linked together to recreate friedland. That's why I split out TriangleWeight in #941, to handle the different regression periods for the severity trend selections. Once you help me work out the kinks on this, the next blocker is #1024. (Was really hoping one of the younger contributors could help me out on that one; reading latex formulas for #952 gave me enough headaches for this calendar year). if i run into more blockers after that, i'll create more issues.

i haven't thought too much about long term if all this piecemeal functionality should be combined into a new freqsev method. we can decide as a collective once we can see a completed chapter 11 recreation. maybe it'll be too much hacking (i tried hacking the severity regression periods but it got too ugly) and we'll want to do some more integration. but if it's like, iono, a dozen or so lines and it's all using the public API (no numpy hacking tri.values), it could be a cool example of how to be innovative with the package. right now we are building a lego model based on the instructions. but the magic comes from combining the pieces in weird and unexpected ways. i mean, that's also the whole end goal of having a well-typed, well-doc'd API.

there is one major refactor that i'm fairly certain i want to push for at some point, but can't yet clearly articulate the right requirements. and that's the entire votingchainladder and pipeline workflow folder of the package. within friedland, and also fairly common in actual practice, actuaries are using reported and paid to estimate the same loss ultimate or using reported and closed to estimate the same count ultimate. votingchainladder currently doesn't support weighing between reported triangle and paid triangle. pipeline currently doesn't support using reported ultimate to recast closed disposal rate. so i think for votingchainladder and pipeline to be more than window dressing, it needs to accommodate multi-triangle interaction. and then however we refactor votingchainladder and pipeline will likely result in some further harmonizing on all the dev transformers, adjustment transformers, and ibnr predictors. not sure if all this would be 1.0 work. we can decide after an initial friedland recreation.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 335ddca. Configure here.}

[github-actions]

Pyright Type Completeness

View the full pyright --verifytypes output for this commit

Project (full chainladder package, at this PR's head): 14.1% of exported symbols fully typed (175 / 1237)

	Known	Ambiguous	Unknown	Total
Project (head)	175	107	955	1237

Other symbols referenced but not exported by chainladder: 13

	Known	Ambiguous	Unknown	Total
Other (head)	3	1	9	13

Symbols without documentation:

• Functions without docstring: 314
• Functions without default param: 0
• Classes without docstring: 10

Patch (exported symbols added or changed by this PR): 40.0% fully typed (12 / 30)

	Known	Ambiguous	Unknown	Total
Patch	12	0	18	30

Patch symbol details

Symbol	Status	Change
chainladder.adjustments.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.incr_disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.X_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.__init__	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.average	✅ known	new
chainladder.adjustments.disposal.DisposalRate.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.disposal_w_	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.drop_above	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_below	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_high	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_low	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_valuation	✅ known	new
chainladder.adjustments.disposal.DisposalRate.fit	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.fit_transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.n_periods	✅ known	new
chainladder.adjustments.disposal.DisposalRate.preserve	✅ known	new
chainladder.adjustments.disposal.DisposalRate.transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.xp	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_cl_parity	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_friedland_fidelity	✅ known	new
chainladder.adjustments.tests.test_disposal.test_no_disposal_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_no_weight_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_setting_incr	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_sparse_transform	❌ unknown	new
chainladder.core.triangle.Triangle.disposal_rate_tri	✅ known	new
chainladder.core.triangle.Triangle.is_disposal_rate	✅ known	new

[henrydingliu]

Summary of Changes

Implement the disposal rate method from Friedland FreqSev Approach 3 as an adjustment estimator

Related GitHub Issue(s)

closes#931

Additional Context for Reviewers

• Created a DisposalMixin for the new adjustment estimator and Triangle

  • Berquist-Sherman also uses disposal rate. will leave harmonization to another PR
  • We may eventually want to split Common into DevelopmentMixin, IncrementalMixin, etc.

• Added disposal_rate_tri to Triangle, mimicking age_to_age/link_ratio

• Added is_disposal_rate to Triangle, in order to differentiate the proper path in incr_to_cum and cum_to_incr

• I passed tests locally for both code (uv run pytest) and documentation changes (uv run jb build docs --builder=custom --custom-builder=doctest)

---

Note

Medium Risk
Changes core triangle cum/incr behavior for a new pattern type and introduces a reserving path that overwrites projected triangles from ultimates; mistakes could affect forecast outputs but scope is isolated behind disposal-rate flags and new estimator usage.

Overview
Adds Friedland disposal-rate reserving as public DisposalRate, which fits a cumulative “% of ultimate” emergence pattern from a triangle and a required sample_weight ultimate, then projects the lower triangle via derived LDFs.

Triangle gains disposal_rate_tri, an is_disposal_rate flag, and DisposalMixin (disposal_rate_ / incr_disposal_rate_) mixed into TriangleBase. incr_to_cum / cum_to_incr now treat disposal-rate patterns as additive cumulative ratios instead of multiplicative link-ratio patterns.

MethodBase.validate_weight is refactored to a @staticmethod for reuse from DisposalRate. Tests cover Friedland textbook fidelity, chainladder parity, sparse backends, and required-weight validation; DisposalRate is wired into the public API.

^{Reviewed by Cursor Bugbot for commit 210ec67. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 97.39130% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.70%. Comparing base (1dddf97) to head (210ec67).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
chainladder/adjustments/disposal.py	97.43%	1 Missing and 1 partial ⚠️
chainladder/core/triangle.py	96.15%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #1022 +/- ##
==========================================
+ Coverage 89.47% 89.70% +0.22% 
==========================================
Files 91 91 Lines 5284 5343 +59 Branches 681 692 +11 ==========================================
+ Hits 4728 4793 +65 + Misses 388 384 -4 + Partials 168 166 -2 

Flag	Coverage Δ
unittests	89.70% <97.39%> (+0.22%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[genedan]

Just letting you guys know that I can look through this today.

[genedan]

I wonder if we should be using a higher level of precision than what Friedland has. That is, have the expectation values at the precision of the atol fixture.

Since this test passes, I think the numbers are correct, so we'd just change the rounding to 4 places and the expectation values at 4 decimals.

Interestingly, Friedland doesn't round on page 253 and also doesn't show the precision, so it looks like the paper isn't 100% consistent in that regard.

[henrydingliu]

i'll add a new assertion statement with round(,4).

[henrydingliu]

got to full matching at 3 decimals.

[genedan]

Friedland has 43 incremental claims at AY 2008 at 72 months. I calculated (609 - 127) / (1 - .2) (.862 - .791) = 42.7775.

[henrydingliu]

fat finger. will fix

[genedan]

Small typo in "examine"

[henrydingliu]

will fix

[genedan]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

[henrydingliu]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

My current approach is to build enough basic functionality within the package such that they can be manually linked together to recreate friedland. That's why I split out TriangleWeight in #941, to handle the different regression periods for the severity trend selections. Once you help me work out the kinks on this, the next blocker is #1024. (Was really hoping one of the younger contributors could help me out on that one; reading latex formulas for #952 gave me enough headaches for this calendar year). if i run into more blockers after that, i'll create more issues.

i haven't thought too much about long term if all this piecemeal functionality should be combined into a new freqsev method. we can decide as a collective once we can see a completed chapter 11 recreation. maybe it'll be too much hacking (i tried hacking the severity regression periods but it got too ugly) and we'll want to do some more integration. but if it's like, iono, a dozen or so lines and it's all using the public API (no numpy hacking tri.values), it could be a cool example of how to be innovative with the package. right now we are building a lego model based on the instructions. but the magic comes from combining the pieces in weird and unexpected ways. i mean, that's also the whole end goal of having a well-typed, well-doc'd API.

there is one major refactor that i'm fairly certain i want to push for at some point, but can't yet clearly articulate the right requirements. and that's the entire votingchainladder and pipeline workflow folder of the package. within friedland, and also fairly common in actual practice, actuaries are using reported and paid to estimate the same loss ultimate or using reported and closed to estimate the same count ultimate. votingchainladder currently doesn't support weighing between reported triangle and paid triangle. pipeline currently doesn't support using reported ultimate to recast closed disposal rate. so i think for votingchainladder and pipeline to be more than window dressing, it needs to accommodate multi-triangle interaction. and then however we refactor votingchainladder and pipeline will likely result in some further harmonizing on all the dev transformers, adjustment transformers, and ibnr predictors. not sure if all this would be 1.0 work. we can decide after an initial friedland recreation.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 335ddca. Configure here.}

[github-actions]

Pyright Type Completeness

View the full pyright --verifytypes output for this commit

Project (full chainladder package, at this PR's head): 14.1% of exported symbols fully typed (175 / 1237)

	Known	Ambiguous	Unknown	Total
Project (head)	175	107	955	1237

Other symbols referenced but not exported by chainladder: 13

	Known	Ambiguous	Unknown	Total
Other (head)	3	1	9	13

Symbols without documentation:

• Functions without docstring: 314
• Functions without default param: 0
• Classes without docstring: 10

Patch (exported symbols added or changed by this PR): 40.0% fully typed (12 / 30)

	Known	Ambiguous	Unknown	Total
Patch	12	0	18	30

Patch symbol details

Symbol	Status	Change
chainladder.adjustments.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.incr_disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.X_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.__init__	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.average	✅ known	new
chainladder.adjustments.disposal.DisposalRate.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.disposal_w_	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.drop_above	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_below	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_high	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_low	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_valuation	✅ known	new
chainladder.adjustments.disposal.DisposalRate.fit	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.fit_transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.n_periods	✅ known	new
chainladder.adjustments.disposal.DisposalRate.preserve	✅ known	new
chainladder.adjustments.disposal.DisposalRate.transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.xp	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_cl_parity	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_friedland_fidelity	✅ known	new
chainladder.adjustments.tests.test_disposal.test_no_disposal_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_no_weight_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_setting_incr	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_sparse_transform	❌ unknown	new
chainladder.core.triangle.Triangle.disposal_rate_tri	✅ known	new
chainladder.core.triangle.Triangle.is_disposal_rate	✅ known	new

[henrydingliu]

Summary of Changes

Implement the disposal rate method from Friedland FreqSev Approach 3 as an adjustment estimator

Related GitHub Issue(s)

closes#931

Additional Context for Reviewers

• Created a DisposalMixin for the new adjustment estimator and Triangle

  • Berquist-Sherman also uses disposal rate. will leave harmonization to another PR
  • We may eventually want to split Common into DevelopmentMixin, IncrementalMixin, etc.

• Added disposal_rate_tri to Triangle, mimicking age_to_age/link_ratio

• Added is_disposal_rate to Triangle, in order to differentiate the proper path in incr_to_cum and cum_to_incr

• I passed tests locally for both code (uv run pytest) and documentation changes (uv run jb build docs --builder=custom --custom-builder=doctest)

---

Note

Medium Risk
Changes core triangle cum/incr behavior for a new pattern type and introduces a reserving path that overwrites projected triangles from ultimates; mistakes could affect forecast outputs but scope is isolated behind disposal-rate flags and new estimator usage.

Overview
Adds Friedland disposal-rate reserving as public DisposalRate, which fits a cumulative “% of ultimate” emergence pattern from a triangle and a required sample_weight ultimate, then projects the lower triangle via derived LDFs.

Triangle gains disposal_rate_tri, an is_disposal_rate flag, and DisposalMixin (disposal_rate_ / incr_disposal_rate_) mixed into TriangleBase. incr_to_cum / cum_to_incr now treat disposal-rate patterns as additive cumulative ratios instead of multiplicative link-ratio patterns.

MethodBase.validate_weight is refactored to a @staticmethod for reuse from DisposalRate. Tests cover Friedland textbook fidelity, chainladder parity, sparse backends, and required-weight validation; DisposalRate is wired into the public API.

^{Reviewed by Cursor Bugbot for commit 210ec67. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 97.39130% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.70%. Comparing base (1dddf97) to head (210ec67).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
chainladder/adjustments/disposal.py	97.43%	1 Missing and 1 partial ⚠️
chainladder/core/triangle.py	96.15%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #1022 +/- ##
==========================================
+ Coverage 89.47% 89.70% +0.22% 
==========================================
Files 91 91 Lines 5284 5343 +59 Branches 681 692 +11 ==========================================
+ Hits 4728 4793 +65 + Misses 388 384 -4 + Partials 168 166 -2 

Flag	Coverage Δ
unittests	89.70% <97.39%> (+0.22%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[genedan]

Just letting you guys know that I can look through this today.

[genedan]

I wonder if we should be using a higher level of precision than what Friedland has. That is, have the expectation values at the precision of the atol fixture.

Since this test passes, I think the numbers are correct, so we'd just change the rounding to 4 places and the expectation values at 4 decimals.

Interestingly, Friedland doesn't round on page 253 and also doesn't show the precision, so it looks like the paper isn't 100% consistent in that regard.

[henrydingliu]

i'll add a new assertion statement with round(,4).

[henrydingliu]

got to full matching at 3 decimals.

[genedan]

Friedland has 43 incremental claims at AY 2008 at 72 months. I calculated (609 - 127) / (1 - .2) (.862 - .791) = 42.7775.

[henrydingliu]

fat finger. will fix

[genedan]

Small typo in "examine"

[henrydingliu]

will fix

[genedan]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

[henrydingliu]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

My current approach is to build enough basic functionality within the package such that they can be manually linked together to recreate friedland. That's why I split out TriangleWeight in #941, to handle the different regression periods for the severity trend selections. Once you help me work out the kinks on this, the next blocker is #1024. (Was really hoping one of the younger contributors could help me out on that one; reading latex formulas for #952 gave me enough headaches for this calendar year). if i run into more blockers after that, i'll create more issues.

i haven't thought too much about long term if all this piecemeal functionality should be combined into a new freqsev method. we can decide as a collective once we can see a completed chapter 11 recreation. maybe it'll be too much hacking (i tried hacking the severity regression periods but it got too ugly) and we'll want to do some more integration. but if it's like, iono, a dozen or so lines and it's all using the public API (no numpy hacking tri.values), it could be a cool example of how to be innovative with the package. right now we are building a lego model based on the instructions. but the magic comes from combining the pieces in weird and unexpected ways. i mean, that's also the whole end goal of having a well-typed, well-doc'd API.

there is one major refactor that i'm fairly certain i want to push for at some point, but can't yet clearly articulate the right requirements. and that's the entire votingchainladder and pipeline workflow folder of the package. within friedland, and also fairly common in actual practice, actuaries are using reported and paid to estimate the same loss ultimate or using reported and closed to estimate the same count ultimate. votingchainladder currently doesn't support weighing between reported triangle and paid triangle. pipeline currently doesn't support using reported ultimate to recast closed disposal rate. so i think for votingchainladder and pipeline to be more than window dressing, it needs to accommodate multi-triangle interaction. and then however we refactor votingchainladder and pipeline will likely result in some further harmonizing on all the dev transformers, adjustment transformers, and ibnr predictors. not sure if all this would be 1.0 work. we can decide after an initial friedland recreation.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 335ddca. Configure here.}

[github-actions]

Pyright Type Completeness

View the full pyright --verifytypes output for this commit

Project (full chainladder package, at this PR's head): 14.1% of exported symbols fully typed (175 / 1237)

	Known	Ambiguous	Unknown	Total
Project (head)	175	107	955	1237

Other symbols referenced but not exported by chainladder: 13

	Known	Ambiguous	Unknown	Total
Other (head)	3	1	9	13

Symbols without documentation:

• Functions without docstring: 314
• Functions without default param: 0
• Classes without docstring: 10

Patch (exported symbols added or changed by this PR): 40.0% fully typed (12 / 30)

	Known	Ambiguous	Unknown	Total
Patch	12	0	18	30

Patch symbol details

Symbol	Status	Change
chainladder.adjustments.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.incr_disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.X_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.__init__	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.average	✅ known	new
chainladder.adjustments.disposal.DisposalRate.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.disposal_w_	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.drop_above	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_below	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_high	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_low	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_valuation	✅ known	new
chainladder.adjustments.disposal.DisposalRate.fit	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.fit_transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.n_periods	✅ known	new
chainladder.adjustments.disposal.DisposalRate.preserve	✅ known	new
chainladder.adjustments.disposal.DisposalRate.transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.xp	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_cl_parity	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_friedland_fidelity	✅ known	new
chainladder.adjustments.tests.test_disposal.test_no_disposal_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_no_weight_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_setting_incr	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_sparse_transform	❌ unknown	new
chainladder.core.triangle.Triangle.disposal_rate_tri	✅ known	new
chainladder.core.triangle.Triangle.is_disposal_rate	✅ known	new

[henrydingliu]

Summary of Changes

Implement the disposal rate method from Friedland FreqSev Approach 3 as an adjustment estimator

Related GitHub Issue(s)

closes#931

Additional Context for Reviewers

• Created a DisposalMixin for the new adjustment estimator and Triangle

  • Berquist-Sherman also uses disposal rate. will leave harmonization to another PR
  • We may eventually want to split Common into DevelopmentMixin, IncrementalMixin, etc.

• Added disposal_rate_tri to Triangle, mimicking age_to_age/link_ratio

• Added is_disposal_rate to Triangle, in order to differentiate the proper path in incr_to_cum and cum_to_incr

• I passed tests locally for both code (uv run pytest) and documentation changes (uv run jb build docs --builder=custom --custom-builder=doctest)

---

Note

Medium Risk
Changes core triangle cum/incr behavior for a new pattern type and introduces a reserving path that overwrites projected triangles from ultimates; mistakes could affect forecast outputs but scope is isolated behind disposal-rate flags and new estimator usage.

Overview
Adds Friedland disposal-rate reserving as public DisposalRate, which fits a cumulative “% of ultimate” emergence pattern from a triangle and a required sample_weight ultimate, then projects the lower triangle via derived LDFs.

Triangle gains disposal_rate_tri, an is_disposal_rate flag, and DisposalMixin (disposal_rate_ / incr_disposal_rate_) mixed into TriangleBase. incr_to_cum / cum_to_incr now treat disposal-rate patterns as additive cumulative ratios instead of multiplicative link-ratio patterns.

MethodBase.validate_weight is refactored to a @staticmethod for reuse from DisposalRate. Tests cover Friedland textbook fidelity, chainladder parity, sparse backends, and required-weight validation; DisposalRate is wired into the public API.

^{Reviewed by Cursor Bugbot for commit 210ec67. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 97.39130% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.70%. Comparing base (1dddf97) to head (210ec67).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
chainladder/adjustments/disposal.py	97.43%	1 Missing and 1 partial ⚠️
chainladder/core/triangle.py	96.15%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #1022 +/- ##
==========================================
+ Coverage 89.47% 89.70% +0.22% 
==========================================
Files 91 91 Lines 5284 5343 +59 Branches 681 692 +11 ==========================================
+ Hits 4728 4793 +65 + Misses 388 384 -4 + Partials 168 166 -2 

Flag	Coverage Δ
unittests	89.70% <97.39%> (+0.22%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[genedan]

Just letting you guys know that I can look through this today.

[genedan]

I wonder if we should be using a higher level of precision than what Friedland has. That is, have the expectation values at the precision of the atol fixture.

Since this test passes, I think the numbers are correct, so we'd just change the rounding to 4 places and the expectation values at 4 decimals.

Interestingly, Friedland doesn't round on page 253 and also doesn't show the precision, so it looks like the paper isn't 100% consistent in that regard.

[henrydingliu]

i'll add a new assertion statement with round(,4).

[henrydingliu]

got to full matching at 3 decimals.

[genedan]

Friedland has 43 incremental claims at AY 2008 at 72 months. I calculated (609 - 127) / (1 - .2) (.862 - .791) = 42.7775.

[henrydingliu]

fat finger. will fix

[genedan]

Small typo in "examine"

[henrydingliu]

will fix

[genedan]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

[henrydingliu]

Do you think we should incorporate some of the latter steps in the method into the package - such as the severity trend selection (even though Friedland just wound up doing a judgmental 5%), and the tail selection of the incremental paid severities?

Or is the package already capable of these things for the Friedland recreation?

My current approach is to build enough basic functionality within the package such that they can be manually linked together to recreate friedland. That's why I split out TriangleWeight in #941, to handle the different regression periods for the severity trend selections. Once you help me work out the kinks on this, the next blocker is #1024. (Was really hoping one of the younger contributors could help me out on that one; reading latex formulas for #952 gave me enough headaches for this calendar year). if i run into more blockers after that, i'll create more issues.

i haven't thought too much about long term if all this piecemeal functionality should be combined into a new freqsev method. we can decide as a collective once we can see a completed chapter 11 recreation. maybe it'll be too much hacking (i tried hacking the severity regression periods but it got too ugly) and we'll want to do some more integration. but if it's like, iono, a dozen or so lines and it's all using the public API (no numpy hacking tri.values), it could be a cool example of how to be innovative with the package. right now we are building a lego model based on the instructions. but the magic comes from combining the pieces in weird and unexpected ways. i mean, that's also the whole end goal of having a well-typed, well-doc'd API.

there is one major refactor that i'm fairly certain i want to push for at some point, but can't yet clearly articulate the right requirements. and that's the entire votingchainladder and pipeline workflow folder of the package. within friedland, and also fairly common in actual practice, actuaries are using reported and paid to estimate the same loss ultimate or using reported and closed to estimate the same count ultimate. votingchainladder currently doesn't support weighing between reported triangle and paid triangle. pipeline currently doesn't support using reported ultimate to recast closed disposal rate. so i think for votingchainladder and pipeline to be more than window dressing, it needs to accommodate multi-triangle interaction. and then however we refactor votingchainladder and pipeline will likely result in some further harmonizing on all the dev transformers, adjustment transformers, and ibnr predictors. not sure if all this would be 1.0 work. we can decide after an initial friedland recreation.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 335ddca. Configure here.}

[github-actions]

Pyright Type Completeness

View the full pyright --verifytypes output for this commit

Project (full chainladder package, at this PR's head): 14.1% of exported symbols fully typed (175 / 1237)

	Known	Ambiguous	Unknown	Total
Project (head)	175	107	955	1237

Other symbols referenced but not exported by chainladder: 13

	Known	Ambiguous	Unknown	Total
Other (head)	3	1	9	13

Symbols without documentation:

• Functions without docstring: 314
• Functions without default param: 0
• Classes without docstring: 10

Patch (exported symbols added or changed by this PR): 40.0% fully typed (12 / 30)

	Known	Ambiguous	Unknown	Total
Patch	12	0	18	30

Patch symbol details

Symbol	Status	Change
chainladder.adjustments.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalMixin.incr_disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.X_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.__init__	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.average	✅ known	new
chainladder.adjustments.disposal.DisposalRate.disposal_rate_	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.disposal_w_	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.drop_above	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_below	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_high	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_low	✅ known	new
chainladder.adjustments.disposal.DisposalRate.drop_valuation	✅ known	new
chainladder.adjustments.disposal.DisposalRate.fit	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.fit_transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.n_periods	✅ known	new
chainladder.adjustments.disposal.DisposalRate.preserve	✅ known	new
chainladder.adjustments.disposal.DisposalRate.transform	❌ unknown	new
chainladder.adjustments.disposal.DisposalRate.xp	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_cl_parity	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_friedland_fidelity	✅ known	new
chainladder.adjustments.tests.test_disposal.test_no_disposal_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_no_weight_exception	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_setting_incr	❌ unknown	new
chainladder.adjustments.tests.test_disposal.test_sparse_transform	❌ unknown	new
chainladder.core.triangle.Triangle.disposal_rate_tri	✅ known	new
chainladder.core.triangle.Triangle.is_disposal_rate	✅ known	new