Ale dirèk nan kontni prensipal la

Who learns that an incident happened

Maya has scraped her knee and Denise has filed the report. Carla Reyes, Maya's mother, is at work. Tom Bradley, the site director, is at a meeting across town. The regional director is in another county. A record answers a question someone already thought to ask. These three need the other thing: a message that reaches them when they are not looking. This page follows every path an incident could take to reach them, and shows where each one stops.

The short answer​

Nobody is told. PTRS sends no message about an incident to anyone, and nothing elsewhere in PTRS does it on Incidents' behalf.

Two things happen instead, and both are records rather than messages:

  1. Every change adds a timeline entry and an entry in the audit trail.
  2. Every 15 minutes, PTRS sends an OCCL deadline warning to whoever happens to have one particular screen open. That screen is the CACFP real-time feed, and the warning is not stored.

Everything the screens say about notifying people is fixed words.

What creating an incident does​

When Denise presses Next Step on the first screen, PTRS writes three things: the incident itself, with its deadlines if it qualifies; one timeline entry; and one audit trail entry. Nothing in that step is capable of sending a message. Submitting an incident does the same three things again, and so does each OCCL status change.

Inside Incidents, nothing runs on a schedule, nothing waits for events, and nothing sends anything.

The messages that are built and never sent​

PTRS contains the makings of a live signal for incidents: a way to tell every open screen at a site that an incident was created, and another for when one was submitted. Both are fully built. Neither is ever used. Filing an incident produces no live signal of any kind, not even to a colleague sitting at the next computer with PTRS open.

The same thing is true in Attendance, where three similar signals, for ratio changes and absences, are built and never used. It is a pattern across PTRS, not a one-off.

The one path that does fire​

There is exactly one thing PTRS does on its own that is connected to an incident, and it is not part of Incidents.

Every 15 minutes, PTRS looks across every organisation for incidents where all of these are true:

  • OCCL is marked as required;
  • an OCCL deadline is set;
  • that deadline is within the next 4 hours;
  • it has not yet passed;
  • and the OCCL status is still Pending.

For each one it sends two messages to open screens: one to anyone with the compliance page open for that site, and one to every open screen, reading "OCCL deadline approaching" with the hours remaining and the incident reference.

Where those two messages actually land​

The compliance one lands nowhere. The compliance page listens for eight kinds of message, and an OCCL deadline warning is not one of them.

The second one lands in one place, and it is not a place anyone would look. The main dashboard hears it and uses it only as a cue to refresh its own figures. The text is never shown. The only screen in PTRS that shows the text is the CACFP Real-Time Feed, which is headed "Real-Time Feed" and subtitled "Live meal counts, background job status, and system events".

So the complete answer to "who is told that an OCCL deadline is four hours away?" is: someone who has the CACFP meal-count feed open at that moment. It is not stored, so closing the page loses it.

And because the check needs OCCL marked as required, and the wizard can never mark it, an incident filed through the screens never enters this check at all.

The dead twin​

An older version of the same check also exists inside PTRS, doing the same work on the same 15-minute rhythm, and it is switched off. Two more background checks near it, for compliance and document expiry, are switched off the same way. Nothing runs them.

The notification system, and why it never engages​

PTRS has a complete notification system: a dispatcher, in-app and email delivery, quiet hours, translation, delivery tracking, a retry worker and an escalation worker. It is described under Notifications.

Whether Incidents could use it comes down to one question: what asks the dispatcher to send something? The answer is one thing, and it is not Incidents. The emergency alert escalation asks it to re-send to guardians who have not acknowledged an emergency alert, and that can never happen, because nothing in PTRS creates an emergency alert, and the only thing that creates an acknowledgement record marks it acknowledged in the same moment.

Nothing in Incidents refers to the dispatcher, to notification records, or to email. No notification has ever been created for an incident, and there is no route by which one could be.

Parent notification is a field that nothing fills in​

Each incident has room to record whether a parent needed telling, whether they were told, when, and when they acknowledged it. Nothing in PTRS ever fills it in, and the incident page is not even given it. The page fills the gap with a fixed "not required", which is why the Parent Communication panel reads "Parent notification was not required for this incident" for every incident ever filed, whatever happened.

What the submit screen claims​

Step 5 of the wizard offers four switches: Notify the director, Notify parent/guardian, Begin OCCL notification workflow and Create follow-up action items. They live on the screen only. Submitting sends the incident's reference and nothing else.

After submitting, the screen shows a confirmation list:

Site Director notified via push notification Regional Director notified via email Parent notifications sent to N families 4 follow-up action items created and assigned

Every line is fixed text. None of the four things happened. There is no push path, no email path, no parent path, and nothing anywhere in PTRS that creates a follow-up action.

Treat that list as decoration. Read the timeline instead. It shows what was actually recorded, and it is the only thing on the screen that does.

What this means for how you work​

This is not a gap you can work around inside PTRS. It is the whole notification layer. So:

  1. Tell people yourself: phone, radio, in person. PTRS will not do it and will not chase you.
  2. Write what you told whom, and when, into the incident description. It is the only field that persists and the only one that reaches the exported PDF. The Parent Communication panel cannot record it.
  3. Advance the OCCL status as you go, so the timeline shows what was done and when. That is the record that survives being questioned, and it is the one thing here that works. See Advance an OCCL notification.
  4. Keep your own deadline reminder. The 15-minute check cannot see an incident filed through the wizard, and even for one that qualifies, its warning reaches a single unrelated screen.
  5. Do not tell a family that PTRS notified them. It did not.

Checked against PTRS on 7 September 2026.