What a CACFP review asks for
A CACFP administrative review is an evidence exercise. The state agency arrives with a list, and for each item on the list a sponsor either produces a record or does not.
PTRS builds four mechanisms for that exercise: a self-audit, a corrective action plan, a readiness score and a DENARS package. This page describes what each one computes, and then says which of them a person can actually reach.
Three of the four have no working way in, and the fourth produces no document.
- A self-audit can be created only through direct system access, and its results, the seven areas it exists to score, can be submitted by nothing at all.
- A corrective action plan cannot be created from its form for five separate reasons, and cannot be updated, verified or closed from any screen.
- The readiness score is real, complete and correct, and its only screen asks for "every site" where PTRS needs one real site, so it has never appeared.
- The DENARS package writes a row marked Generated and produces no file.
The one part of the chain that works is the audit trail underneath it, every write on every one of these paths is recorded in PTRS's tamper-evident chain.
The chain, as designed
The design runs in one direction: a site monitoring review, a self-audit check, or a claim edit check can each raise a finding. A finding becomes a corrective action plan, which is worked through to verified or closed. Separately, the review readiness score draws on all of it across eight categories, and the readiness picture feeds into a DENARS package.
PTRS names five sources for a corrective action exactly: Sponsor Monitoring Review, DDOE Admin Review, Self-Audit, Claim Edit Check and Complaint Investigation. The design is coherent. Every link in it is broken at a different point.
1. The self-audit
A self-audit check covers a site, an audit date, an audit period and a program year, and holds one result per check area.
Seven check areas:
| Area | What a reviewer tests with it |
|---|---|
| Meal count accuracy | Do the counted meals match the served meals |
| Meal pattern compliance | Did every meal meet its component requirements |
| Enrolment records | Is every participant enrolled and current |
| Attendance records | Does attendance support the meals claimed |
| Food service agreement | Is the vendor or hub agreement in force |
| Prior findings | Were the last review's findings corrected |
| Civil rights compliance | Poster, training, complaint log, demographics |
Each is scored Pass, Fail or Not Reviewed, and the overall verdict follows from those, honestly worked out rather than typed in: any Fail makes the result Critical Issues; otherwise any Not Reviewed makes it Needs Attention; otherwise it is Ready for Review.
That is sound logic, and submitting the results genuinely writes: one row per result, marked complete, timestamped, recorded in the audit trail.
And nothing calls it. No screen submits results, and the screen pieces built for a checklist and a finding card are used by no page; there is no detail screen either. A check created outside the interface stays Needs Attention and not complete for its whole life, because those are the values creating one assigns and nothing else changes them.
The path to create one at all cannot be reached either, Self-Audit Dashboard sends a blank site where PTRS needs a real one.
Consequence for the review chain: Self-Audit is one of the five valid corrective-action sources, and a self-audit can never produce a finding.
2. The corrective action plan
A corrective action plan records a source, a category, a description, a severity, the action required, a responsible staff member, a due date and whether DDOE needs to be told. Its intended life is Open, then In Progress, then Pending Verification, then Verified, then Closed, with Overdue meant to be applied automatically on a schedule.
Nothing applies Overdue automatically. CACFP schedules no task of any kind on any timetable. Overdue is set by no code anywhere; the only place a plan is shown as overdue is the card itself, which compares the due date to today in your browser and adds the word to the due-date line without changing the stored status.
The two actions that move a plan forward are correct. Adding an update records the previous and new status and moves the plan; verifying stamps the verification date and verifier, moves the plan to Verified, and escalates it to Closed when closure notes are given. Neither has a screen, and the screen pieces built for them are used by no page.
So every corrective action plan that exists is permanently Open, which is also the value creating one assigns by default.
The create form fails five ways, listed in full on work the review and corrective action screens. The one worth repeating here is the severity dropdown: it offers Minor, Major and Critical, and PTRS's own three severities are Observation, Finding and Serious Deficiency, the three USDA finding classes. None of the three offered values is one PTRS recognises. A finding cannot be classified in the vocabulary a reviewer uses.
Nothing is sent when a plan is created
Whether DDOE needs to be told is on the create form and on the record itself, and is read by no code. No CACFP path sends email at all, a finding confirmed across all four parts of this module, and PTRS's email sending only ever logs a message rather than delivering one, in every copy of PTRS, because no mail server is configured anywhere. See who learns that an incident happened for the same mechanism documented in full.
3. The readiness score
Two checks, both genuinely worked out against live data. This is the most substantial reporting work in the subset, and no screen has ever shown either of them, the only page that calls them asks for "every site" where PTRS needs one and gets nothing back.
Readiness: nineteen checks in eight categories
PTRS counts records and reports what is missing. Each category has a fixed number of checks; a category is Green at 100%, Yellow at 50% or more, and Red below that.
| Category | Checks | What each check tests |
|---|---|---|
| Enrolment & Eligibility | 3 | Any enrolment, any income application, any active enrolment |
| Meal Counts & Attendance | 2 | Any meal record in 30 days, any per-child daily meal log in 30 days |
| Menu & Food Service | 3 | Any food item in the catalogue, any production record in 30 days, any meal pattern rule set |
| Civil Rights | 3 | Any poster record, any civil rights training record, any demographic record |
| Training & Staffing | 3 | Any staff training record, any role assignment for the site, any food safety certification |
| Financial & Claims | 2 | Any claim, any reimbursement rate |
| Health & Safety | 2 | Any temperature log in 30 days, no open corrective action plan |
| Administrative Records | 1 | Any document attachment for the site |
The overall score is completed checks divided by 19, as a percentage, to one decimal place, not weighted.
Not because the site is unready, but because nothing in the product can create the record the check counts:
| Check | Why it can never pass |
|---|---|
| Any food item in the catalogue | Adding one has no screen and nothing gives PTRS a starting set |
| Any meal pattern rule set | Only ever filled in when PTRS starts up in its development setting, for one fixed organisation |
| Any production record in 30 days | The create form fails on every submit |
| Any income application | The action exists and has no screen |
| Any per-child daily meal log | The table has readers and no writer |
| Any claim | No claim can be created |
| Any reimbursement rate | None of the three ways to add one has a screen |
| Any document attachment | None of the four document actions has a screen |
So Menu & Food Service is 0 of 3, Financial & Claims is 0 of 2 and Administrative Records is 0 of 1 in every installed copy of PTRS, permanently, and three more categories are capped below full marks. A perfectly run site could not score above 11 of 19, 57.9%, Yellow, and only if its role assignments, demographics, poster records and civil rights training were entered through direct system access.
One check is scored backwards. Health & Safety awards its second point for having no open corrective action plan. A site that has never recorded a corrective action scores the same as one that has closed every one of them, and a site that honestly records an open finding loses half the category.
The compliance score, the same data, weighted
A second calculation scores the same eight categories from 0 to 100 each and combines them with a set of weights:
| Category | Weight |
|---|---|
| Meal Counts & Attendance | 0.20 |
| Enrolment & Eligibility | 0.15 |
| Menu & Food Service | 0.15 |
| Financial & Claims | 0.15 |
| Civil Rights | 0.10 |
| Training & Staffing | 0.10 |
| Health & Safety | 0.10 |
| Administrative Records | 0.05 |
| Total | 1.00 |
Worked out The eight weights sum to exactly 1.00, matching PTRS's own intention for them. The overall score is each category's score multiplied by its weight, summed, and graded A at 90 or above, B at 80, C at 70, D at 60, and F below that.
This is worth noting against the rest of PTRS. The DELACARE compliance engine fails before it stores anything, divides by 1.20 rather than 1.00, and holds two disagreeing weight tables. This one has a single table, correct arithmetic and no such failure. It is the better piece of work, and it is the one nothing displays.
Note that it is a third weight table in the product, over different categories from either compliance table, and the two are never reconciled.
4. The DENARS package
Two buttons ask PTRS to generate a package, one on Recordkeeping & Document Retention and one on Review Readiness. Both send "every site" where PTRS needs one real site, and both fail before PTRS reads the rest of the request.
If either reached PTRS, it would write a package record marked Generated and leave its document blank. Nothing in PTRS assembles a document, a PDF, or a file to hand to a reviewer. Documented in full on Who can do what with enrolment and records.
The document checklist, the closest thing PTRS has to a reviewer's own list, checks twelve documents across the same eight categories and reports whether each is present. It is built with the plumbing a screen would need, has no screen, and the screen piece built for it expects a different shape of answer than PTRS sends.
What a review would ask for, and what PTRS could produce
| A reviewer asks for | PTRS holds it | A person can produce it |
|---|---|---|
| Enrolment forms | Yes | Yes, the one CACFP flow that completes |
| Income eligibility applications | Yes, and the arithmetic is correct | No, the action has no screen |
| Daily meal count records | Yes | Yes, through the header's Quick Add dialog only |
| Daily attendance supporting the counts | No, the per-child log has no writer | No |
| Menus and production records | Production records: the design holds them | No, the form fails on every submit |
| Temperature logs | Log headers yes, readings no | Partly, a log can be created, a reading cannot |
| Civil rights poster documentation | Two separate records, both unreachable | No |
| Civil rights training records | Yes | No, no screen |
| The annual complaint log, certified | Yes | No, no screen, and certifying would count zero |
| FNS-101 racial and ethnic participation | Yes, worked out correctly | No, nothing collects the data, and the breakdown table does not appear |
| Staff training documentation | Yes | No, no screen |
| Food safety certifications | Two separate records | No, no screen on either |
| Claim submissions | Yes | No, no claim can be created |
| Prior findings and their corrective actions | Yes | No, the form fails five ways |
| Self-audit results | Yes, with honest scoring | No, nothing submits results |
| A readiness assessment | Yes, and it is good | No, the only screen fails every time |
| A packaged submission | A row only | No, no file is ever produced |
Two regulated figures this module does not hold
Training hours
PTRS applies exactly one rule to CACFP training hours: the hours recorded must be greater than 0. There is no annual minimum, no per-role minimum, and nothing recording an hours requirement on the table that lists what training each role requires; that table records a role, a required training type, whether it is mandatory, a program year and whether a food safety certificate is required, and nothing about duration.
So the product cannot tell you whether a staff member has met an annual training hour requirement, and this page cannot print the requirement, because PTRS does not hold one.
What PTRS does compute is the expiry of a training record, 30 September of the program year's end year, which is the federal program year boundary.
Poster requirements
The poster form number is free text on both poster records. No poster form number, version or title appears anywhere in PTRS. The only structured field is the condition, Good, Damaged, Faded, Covered or Missing, and only Good is treated as compliant.
The two figures the module does hold, and this documentation prints in full, are the temperature safe ranges (temperature and production fields) and the USDA meal pattern serving sizes (what makes a meal reimbursable). Of those two, only the meal pattern table carries PTRS's own regulatory citations.
What does work, and is worth protecting
- The audit trail. Every write on all four mechanisms is recorded, by record type, id, action and description, into a cryptographic chain. It is tamper-evident and it is complete.
- The readiness and compliance-score checks. Nineteen honest checks, eight weights that sum to 1.00, correct arithmetic, a named missing item for every failed check. They need a site id and a screen.
- Submitting self-audit results. It checks what it is given, records one row per result, and works out its own verdict from the results rather than accepting one typed in. Very few "submit" actions in this module do all three.
- The corrective-action update actions. Both record the previous status alongside the new one, which is what makes a corrective action's history defensible.
- The temperature safe-range calculation. It runs the moment a reading is written, cannot be overridden by whoever sends it, and rolls up onto the parent log.
Every one of the five is reachable only through direct system access.
Related
Checked against PTRS on 7 September 2026.