What Programs can and cannot measure
PTRS holds four separate, complete, well-designed chains for measuring whether a program worked, plus a fifth for whether it was staffed correctly. Every step in all five is properly modelled and correctly built.
All five are broken at the same kind of link. In each case the definition can be created and the measurement cannot, because the action that would record the measurement is reachable from no screen.
This page traces each chain link by link, so a reader can tell at a glance which figure on which screen is a real number and which is a structural zero.
The five chains
| Chain | Definition | Measurement | Reporting |
|---|---|---|---|
| Goals | goal, then objective, then success measure | a KPI measurement | the five dashboard tiles |
| Learning | a learning outcome | a child's progress | a per-child progress list |
| Assessment | an assessment, before and after | an assessment result | the pre/post comparison |
| Feedback | a survey and its questions | a survey response | survey results |
| Staffing | a certification requirement | a live credential check | the Compliance tab |
Where each chain breaks
Read the reachable column as: is there any control, on any screen, in any role, that would actually cause this to happen?
Goals
| Link | Reachable? |
|---|---|
| Create a goal | Yes, the Goals tab |
| Change its status | No |
| Add an objective | No |
| Set an objective's value and success measures | No |
| Record a KPI measurement | No |
| Read the dashboard | Yes, the Goals tab |
A goal's status is fixed at Not Started when it is created, and the one action that would move it is reachable from no screen. So of the five possible statuses, one has a way to be set and four do not, and the dashboard's Achieved, In Progress, At Risk and Not Achieved counters are zero on every program that has ever existed.
An objective, its success measures and a KPI measurement have no reachable writer at all, so the expanded goal card never shows an objective, a success measure, a progress line, or a KPI count.
Learning
| Link | Reachable? |
|---|---|
| Define the outcomes | No |
| Record a child's progress | No |
| Read a child's progress | No |
This chain has no reachable link at all. No screen writes a learning outcome, records progress against one, or shows either. Both tables exist with no reachable reader and no reachable writer.
The action behind recording progress is well built: it keys on the child, the program and the outcome together, matches the unique combination PTRS expects, checks that the outcome actually belongs to the program, and stamps the date on PTRS's own side.
Assessment
| Link | Reachable? |
|---|---|
| Create an assessment | Yes, the Assessments tab |
| Record a child's score | No |
| Compare pre and post | Yes, the Assessments tab |
The one action that would record a score for a child is reachable from no screen, so the result count reads zero on every assessment card, Total Results reads zero, the pre and post averages on every comparison are both absent, and the improvement figure, the post average minus the pre average, is therefore absent too and never rendered.
A second defect sits behind the first and would survive fixing it: the comparison groups assessments by title with "(Pre)" and "(Post)" stripped off, and the screen matches the result back on the unstripped title, so the naming convention PTRS expects produces a label that matches neither card.
Feedback
| Link | Reachable? |
|---|---|
| Create a survey | Yes, the Survey Builder |
| Correct a survey | Wired up, never actually reached |
| Submit a response | No |
| Read the responses | No |
The Survey Builder is genuinely good: six question types, an options editor, reordering, required flags, all saved correctly. Nothing in PTRS can then answer the survey. There is no fill-in view in the staff application, none in the Parent Portal, and no link to send anybody.
So Responses reads zero on every card, Total Responses reads zero on the tile, and the action that would show a survey's results has no screen and nothing to return.
Staffing
| Link | Reachable? |
|---|---|
| Define the program's required credentials | No |
| Assign a staff member | Yes, the Staff tab |
| Check the assignment against the requirements | Yes, the Staff tab |
Here the definition is the unreachable link and the measurement is reachable, the reverse of the other four, and the outcome is the same. The compliance check returns an empty result as soon as the requirement list is empty, and the requirement list is empty on every program, so the Compliance tab reads "No compliance data" everywhere.
This is the chain worth caring about most, because it is the only place in PTRS that asks whether the people on a particular program hold the credentials that program requires, the form a DELACARE inspection takes.
What this means for a figure on a screen
Every number the four outcome tabs display, and what it actually is.
| Screen | Figure | What it really is |
|---|---|---|
| Goals | Total Goals | a real count |
| Goals | Achieved, In Progress, At Risk | structurally zero |
| Goals | Not Started | always equal to Total Goals |
| Goals | "N KPI measurements recorded" | never rendered, N is always zero |
| Assessments | Total Assessments | a real count |
| Assessments | Active | always equal to Total Assessments, nothing can deactivate one |
| Assessments | Total Results | structurally zero |
| Assessments | Showing Improvement | structurally zero |
| Assessments | Pre Avg, Post Avg, improvement | never rendered |
| Surveys | Total Surveys | a real count |
| Surveys | Active | equal to Total Surveys unless someone integrating directly has deactivated one |
| Surveys | Total Responses | structurally zero |
| Evaluation | all three tiles | structurally zero, the screen does not connect to PTRS at all |
| Staff | Assignments count | a real count |
| Staff | Compliance count | structurally zero |
Nothing in this list is an invented number or a fabricated percentage, which is a better position than Compliance, Incidents and CACFP, each of which shows at least one figure that looks measured and is not. Everything here is either a true count of the things a person can create, or a zero.
Why the zeros are not obvious
Three properties of these screens make the zeros read as "nobody has done this yet" rather than "this cannot be done".
Every empty message is worded as an invitation. "No goals defined yet. Click 'New Goal' to set program objectives and KPIs" describes a control that sets neither. "Assign staff and set certification requirements to see compliance" describes a control that does not exist. "No evaluations recorded yet. Click 'New Evaluation' to add a program review" describes a button that records nothing.
The definitions do save. A goal, an assessment and a survey are all created successfully, with a message confirming it, so the screens behave as if the rest of the flow will work too.
Nothing reports a failure, because nothing is attempted. These are not errors; they are actions that are never taken.
What does not exist at all
Worth stating so a reader stops looking:
- No scheduled task touches any of this. Every recurring job in PTRS belongs to another module, so no goal ever goes overdue on its own, no target date triggers anything, and no survey closes on a date by itself.
- No notification is produced. PTRS has never sent a notification of any kind, anywhere in the product, so nothing tells anybody a target date has passed or a survey is waiting.
- No total across programs. Every one of these actions is scoped to one program. There is no organisation-wide goal dashboard, no cross-program outcome report and no export.
- No delete anywhere in this half. There is no delete action for a goal, an objective, a success measure, a measurement, an outcome, an assessment, a result, a survey, a response or an evaluation. The only deletes in the delivery half are in the curriculum and the resource library.
What is worth protecting
If any of this is repaired, four pieces are already right and should not be rewritten:
- The staff compliance check. Correct credential arithmetic including grace periods, and it treats an optional requirement with no matching credential as compliant rather than failing it.
- The child progress action. A proper save that keys correctly, and checks that the outcome actually belongs to the program before saving.
- The Survey Builder. Six question types, an options editor and reordering, all saved correctly.
- The survey response duplicate guard. One response per child per survey, correctly refused as a duplicate rather than silently overwritten.
Where to go next
Checked against PTRS on 7 September 2026.