At its core, I think this is a problem of data modeling. The way your org is defining what is/isn't an object is at odds with what you're actually trying to accomplish.
One thing to ask yourself is whether or not there needs to be two separate records (I'm assuming, based on your description, that "Application" and "Placement" are both
If not, then you could write a validation rule to enforce that a log needs to be an "Application" before it can become a "Placement".
PRIORVALUE() would help with that.
Otherwise, splitting it into two objects, and creating a master-detail relationship between your "Application" and "Placement" would enforce your rule (with a master-detail relationship, the child "detail" record cannot exist without being related to a record of the "master" object).
Something else to ask yourself is what is the value to your organization for forcing people to go through this process? What do you gain by having a separate record for applications and placements?
Do you report on that data?
Is the measurement of performance of your case managers dependent on that information?
From my limited point of view, I'd suggest going with the split it into two objects approach. It would seem to satisfy your needs, even without the need to dive into the declarative tools (valdiation, workflow, process builder, etc...). Another possible option would be to use an approval process to manage the transition from application to placement (an approval process can modify a record after it reaches "final approval").
Of course, if you/your org can't justify why an Application is required before a placement, then requiring an Application is just slowing down your process and you may be better off without making that a requirement.