I turn ambiguityinto evidence.

Renters can discover and save listings easily. Important qualification details often appear only after they have already invested time. I focused on an earlier question: can a renter tell whether an application is worth pursuing?

I reviewed the full rental journey and marked where requirements, affordability, documents, and next steps become unclear. The main issue was not a lack of listings. Renters needed key decision information in one place and at the right time.

I designed a readiness layer that brings requirements forward and helps renters prepare before applying. It does not approve or rank applicants, and it never promises an outcome. This keeps the guidance useful without creating false confidence.

I would track readiness check completion, qualified application starts, progress from saved listings, and exits caused by uncertainty. I would also test whether the guidance is clear, accessible, and equally useful across different renter groups.

The dataset contained millions of encounters, but the right intervention was not obvious. I focused on a practical question for an operations team: which patterns in access and use should the team investigate first?

I studied access conditions, emergency use, timing, continuity of care, and predictive signals across 7.7 million encounters. I compared several views of the data to find repeated patterns and separate them from one time observations.

Two important signals were 55.6% broadly avoidable use and an 8.7 times weekend surge. These results do not prove what caused the pattern. They suggest that weekend access and continuity of care are strong places to begin the next investigation.

The model reached an AUC of 0.953, which shows strong signal detection. It does not prove patient or business impact. A real test would also need input from clinical teams, patient safety checks, subgroup monitoring, and clearly defined outcomes.

The AI onboarding assistant had a promising direction, but the team did not yet share one definition of correct behavior. Before adding more features, we needed to agree on what the assistant should do when a request is clear, incomplete, or unexpected.

I broke each onboarding moment into the user input, assistant response, next step, unusual cases, and possible failures. More than 30 workflows made hidden assumptions visible and gave product and technical teammates one shared reference.

I used workflows and simulations to define expected behavior before the product grew. This helped the team discuss specific responses and limits instead of relying on general impressions of whether the assistant felt good.

The 30 plus workflows show what I delivered, but they do not measure user impact. I would evaluate task completion, serious failures, recovery quality, repeated corrections, and user confidence. New problem cases would guide the next round of testing.