This really is an interesting test case, I never expected that a project would "fly under the radar" in this way.

If Source Finder was not already white-listed it may not be eligible for white-list consideration based on the requirement:

All users have an equal chance of receiving work units within any one application / platform with the following exceptions:
A project may restrict work to computers generating faulty results
A project may restrict / ban users or computers for breach of either BOINC or the projects terms of service

• The batches of work that are currently released on a weekly basis are often too small to supply all project contributors with work batches exhausted between 0.5 days and 2 days. Depending on what time of day client computers are requesting work they may not receive work from a batch.
• The only application currently providing work is a beta version requiring opt-in (there are potential issues that require some technical skill and willingness on the part of the cruncher to manage so beta opt-in is warranted)

This raises two questions for me:

1. When new policy for white-listing is introduced should all projects be tested under the new rules in order to maintain their status?
2. Should every project be required to maintain user's equal chance of receiving work units in order to keep white-list status?

Source Finder would have been grey-listed under the new policy when its Work Availability Score (WAS) became RED on previous occasions but the fact that it has had a consistently low level of work for an extended period gives it a green WAS right now. The other grey-list trigger is Zero Credit Days (ZCD) ≤ 7 in 20 which will adequately trap projects that are able to produce an ample supply of work periodically or projects with a temporary shortage of work but due to the latency in processing work units won't trap projects that are consistently under supplying work.
It seems a project that is grey-listed for low WAS could become automatically white-listed under the current policy if it at least provides a consistent level of work even if it is a very small amount. In this case I would expect a poll for de-listing created during the grey-list period but Ideally such a project shouldn't be automatically restored to white-list status.

If it is possible to capture the number of days a project has Zero Work Available it could be a useful metric to filter projects that are under supplying work.
As I see it, the most important issue for the Gridcoin network is not how much work a project can produce but whether all of the Gridcoin miners contributing to a project have an equal chance at receiving enough work to maintain a fair payment distribution.

I am celebrating the new white-list management procedure, it is a positive step for Gridcoin and in most cases will serve it's purpose very well. Source Finder may have inadvertently caused some frustration with the timing of events but it has provided some valuable insight into potential flaws at an early stage.