My solution has three parts:

1. Implement an "unknown gap threshold." This is a concept I've previously mentioned before and may have referred to it as a "grace period." The idea is that if we know Client X was homeless yesterday, they're probably still homeless today, even if we don't know for sure. If they were homeless last Wednesday and homeless last Friday, we can be 99.9% confident they were homeless on Thursday too. Basically, you set a number of days - I imagine the default might be 7 days - and if it's been that many days or less since the last time someone updated their housing information, then the client keeps their previous Housing Status. If that many days or more have passed, they become unknown. So basically, if a client books out of shelter on Monday and the unknown gap threshold is set to 3 days, they don't immediately become Unknown right after they book out. They would stay homeless on Tuesday, and on Wednesday, and on Thursday, and then on Friday they would become Unknown if no new data has been introduced in that period. This could be a threshold set locally by communities (my recommendation) but if you want it to be a standardized thing like the inactivity threshold, I'd also accept that approach.

2. Introduce a new table (or alternatively, you could repurpose the "Risk of Homelessness" table) that includes a bunch of date-stamped housing values. This would contain values like "on Thursday, Client Y was Homeless" or "on Saturday, Client Z was Housed." This is a date-stamp value as opposed to a date-range, so it does not have a duration. You're not asking for a start or end date. You're just saying they were or were not homeless on a specific date. Adding a value here should force the client's Housing Status to update, but since we have an "unknown gap threshold," above, the client will retain that status for X number of days. So if the "unknown gap threshold" is set to 7, you mark them as homeless today and they keep a Housing Status of "Homeless" for 7 days.

3. Have a way to bulk mark clients as homeless via the Encampments and also the Group Activities module, or via some version of "Block Operations."

Technically, the behind-the-scenes behaviour would need to be: When this new type of date-stamp is added, immediately update Housing Status. Update the nightly stored procedure to also check this table. Update the stored procedure to also check to see if the most recent information is >X days ago.