Proposition Missing After Revision Deployment
A health insurer with 4.3 million members configured a new Annual Wellness proposition in Pega CDH. The proposition, treatment, and NBA design changes were built in the CDH application on a branch, then merged and deployed through revision management from Development to Test and Production. In Production, the proposition is not returned by the real-time container, while Test works. The data flow that loads member profiles runs nightly and completes with 3% rejections due to a null dateOfBirth property. The proposition's eligibility uses memberAge >= 18. The production revision is pinned to the NBA ruleset version that was active before the release. The container log shows no eligible actions for 12% of requests. Business also reports that a separate contact-policy change did not take effect.
1. What are the most likely reasons the proposition is not returned in Production? Give a prioritized troubleshooting sequence.
Read the worked answer
Start with revision management: confirm that the production revision is pinned to the new ruleset version and that the proposition and NBA design are part of that revision. A container pinned to an old revision cannot see new artifacts. Next confirm the proposition is in Available state and is mapped to a treatment and action in the issue and group. Then check eligibility: a null dateOfBirth makes memberAge null, and memberAge >= 18 evaluates false or unknown. The 3% rejects can cascade into the 12% no-eligible-actions rate.
Check the contact-policy rule is in the deployed revision and scoped to the right issue. Finally verify the container's application and revision configuration. Use the strategy test with a production-like member record to see which component drops the row. Fix the most global cause first: revision pinning, then design inclusion, then data quality, then container configuration.
2. How should the team handle the null dateOfBirth data quality issue without weakening eligibility for all members?
Read the worked answer
Do not default age to zero. Use data flow validation or a filter to route records with null dateOfBirth to a work queue, and report the rejection rate. Backfill from the source system where possible. For genuinely unknown age, define an unknown-age band and write an eligibility rule that permits Annual Wellness only when age is known or when an alternative criterion, such as an existing care relationship, is met.
Add data flow error handling and monitoring so the 3% rejection rate is visible to operations. Test the rule with null, boundary, and valid ages. This preserves the intent of the age criterion without silently excluding members or allowing minors.
3. What configuration and release controls would prevent this class of failure?
Read the worked answer
Use revision management consistently: build, test, and promote the same revision through environments, and ensure the production container is pinned to that revision. Automate a post-deploy smoke test that calls the container with test members and asserts that the proposition is returned. Add a data flow reconciliation check and alert on rejection spikes.
Include proposition state, eligibility, action-treatment mapping, and contact-policy scope in the release checklist. Put contact-policy changes in revision-managed rulesets rather than hotfixes. Use a deployment pipeline with gates and a rollback plan, and monitor no-eligible-action rates by segment after release.