What was done

Ran a dedicated live source-tracing pass for Bi-Weekly Status Call with Client after the broader backlog audit showed this family was too large to treat as stale-task residue.

Confirmed findings

• Exact-name lookup on litify_pm__Default_Matter_Task__c for Bi-Weekly Status Call with Client returned 0 rows.
• All 6,383 rows carry RecurrenceInterval = 14.
• Recurrence profile:
  • 3,947 rows: RecurrenceRegenerateAfterToday
  • 2,435 rows: RecurrenceRegenerated
  • 1 row: RecurrenceRegenerateAfterDueDate
• All still show IsRecurrence = false.
• 6,363 rows have litify_pm__Parent_Task_Id__c.
• Only 20 rows are parentless roots.
• Root creators:
  • Josh Hollan: 18
  • Sam Aguiar: 2
• 6,383 of 6,383 rows have litify_pm__Default_Matter_Task__c = null.
• 6,375 rows have litify_pm__Matter_Stage_Activity__c != null.
• Sampled stage-activity records are named Treatment.
• The underlying Treatment matter stage a0I5e00000A1MZyEAN has exactly 1 configured default task and Task_Set = false.
• That actual default task is Fee agreement signed?, not Bi-Weekly Status Call with Client.
• Sampled parent-task lookup showed the Litify parent field is workflow ancestry, not a same-subject recurrence pointer: parent 00T8W00003D9dZJUAZ is Complete Intro Call with Client.

Working conclusion

The family is best treated as a Treatment-stage-linked recurring client-call workflow family with custom or operational task seeding, not as a simple live default-task template. What remains unproven is the exact execution path behind the Sam Aguiar burst-created rows on 2026-04-16, 2026-04-20, and 2026-04-21.

Local artifacts

• C:\Users\SAguiar\Documents\Projects\_repo-staging\litify\Litify_AI_Integration_Project\analytics\biweekly-status-call-source-trace-2026-04-29\README.md