A rental-assistance workflow spans income verification, landlord confirmation, and payment authorization across agencies. Why should orchestration checkpoint after each verification step?
Select an answer to reveal the explanation.
Short Explanation
It’s like saving a game after each level—if the console freezes, you don’t replay from the title screen. Checkpoints after each agency verification let a multi-day rental-assistance flow pick up where it left off.
Full Explanation
Long-running rental-assistance orchestration spans agencies for income verification, landlord confirmation, and payment authorization. Checkpoints after each verification step persist committed progress so a failure, pause, or overnight gap does not force restarting work that already succeeded. Stateful orchestration with checkpoints therefore lets municipal processes resume from the last durable boundary rather than redoing completed verifications across multi-day civic case timelines.
Checkpoints do not replace long-term memory of applicant identity; identity and case linkage still matter across days and systems. They also do not force verifications to run only during business hours—timing policies are separate scheduling controls. Converting unstructured emails into vector embeddings for RAG is a retrieval concern, not the purpose of orchestration checkpoints in housing workflows.
Exam caveat: checkpointing is about durable progress and restart safety, not about eliminating memory or performing RAG. Operational check: inject a failure after landlord confirmation in a non-production run and confirm the workflow resumes at payment authorization without re-collecting income evidence already marked committed. Keep checkpoint payloads minimal but sufficient to resume agency handoffs without re-asking residents for documents already verified.