Programs

Tom Bradley, the site director at Claymont, is setting up Homework Help for the fall. He needs a program record with a room, a season, an age band and a capacity, and he needs Maya Reyes, age nine, on the roll before the first Monday. Every other part of PTRS leans on what he sets up here: attendance sessions are meant to attach to this program's schedule, the compliance file asks which children were in which program, and Maya's own record shows her programs on its own tab.

What Programs is for

A club's day is built out of programs, not a vague sense of who is "at the club". Maya is not simply present. She is in Homework Help until 4:30, then in the STEM club, in a specific room, with a staff member who is supposed to be there. This module holds the record that says so: a program's type, season, age band, capacity, lifecycle status and its roll of children.

The failure this module exists to prevent is a club that knows how many children walked in the door but not what any of them signed up for: a roll kept in a spreadsheet, a waitlist kept in somebody's head, and a site that quietly runs past the number of children its licence permits.

Who uses it

Who can do this

• Site director
• Organisation admin
• Super admin

management

Site directors, organisation administrators and super admins can use every Programs screen. A regional director sees the same menu and cannot open a program at all: the list itself refuses them with "Failed to load programs", and every tab inside a program does the same. Two screens still work for that role: the Resource Library, which sits outside a specific program, and the Program Calendar, which is linked from nowhere and permanently empty anyway.

A staff member is refused everywhere in this module, including the twelve places that would otherwise admit them. One Programs screen works for a staff member anyway: the AI brainstorm tools, reached from the sidebar, because that screen belongs to the AI module and checks a different setting. Guardians, OCCL auditors and read-only accounts are admitted nowhere.

Unlike most of PTRS, a failed permission here is visible: the screen says "Failed to load programs" rather than showing an empty list, so if you cannot see any programs at all, read that message literally rather than assuming there simply are none.

A regional director can approve almost nothing here

Approving a program charter is meant to be open to organisation administrators, super admins and regional directors alike. In practice a regional director can never reach the Charter tab at all, because the program overview refuses them first. So charter approval works out, in practice, to organisation administrators and super admins only.

Reading a grant is open to more people than creating one

Creating or changing a funding source or a grant is limited to organisation administrators, regional directors and super admins, and reading one carries no such limit. A site director can open every grant amount, grant number, award date and funder contact in the organisation, unpaged and unfiltered, even though the same site director cannot create or edit a single one.

A day in the life

Tom opens Quick Add → Program and creates Homework Help: type, season, delivery mode, an age band, a capacity of 20, a start and end date. The program appears with a grey Draft badge. He moves it through the lifecycle himself, one step at a time, until it reads Active.

Denise Okafor, on the front desk, opens the program and enrols Maya from the overview screen. PTRS checks the club's licensed capacity before it lets the enrolment through, the one enrolment path in the whole product that does. Maya appears on the roll.

A week later Tom wants to set Homework Help's actual meeting days and times. He opens the Schedule tab, builds a recurring pattern, and presses Save. Nothing happens: no message, no error, the screen simply does not save it. He keeps the schedule on the club's shared paper calendar instead, the way the club always has.

What PTRS does for you

• Holds a detailed program record: its type, season, delivery mode, age band, capacity, waitlist setting, date range, BGCA pillars and free-text tags, created from one dialog and edited from another
• Stops a site going over its OCCL licensed capacity, on the one enrolment path that checks it: the Enroll button on a program's overview. This is one of the few real regulatory controls in PTRS, and it works
• Walks a program through a seven-state lifecycle in order, always showing the legal next step or steps and refusing anything else
• Enrols a whole group of children in one request with Bulk Enroll
• Runs a waitlist once you turn it on, and lets you promote children off it when a seat frees up
• Lets you snapshot a program's settings before a big change, and read that snapshot back later
• Clones a program into a fresh draft for next season, carrying its type, dates, pillars and tags
• Lets you assign, list and remove staff on a program

Numbers this page does not carry

"Programme fill rate", "average time from draft to live", "waitlist conversion" and "sessions delivered against sessions planned" are the figures an evaluator asks for here. None is published, and the last cannot be: no session can be created through the interface at all, so there is nothing to count sessions delivered against.

The Goals, Assessments, Surveys and Evaluation tabs are the other place an evaluator looks, and every figure on all four is either a count of the definitions a person can create, or a structural zero. No goal has ever changed status, no assessment score has ever been recorded, no survey has ever been answered and no program evaluation has ever been saved, not because nobody has tried, but because no control exists that would let them. What Programs can and cannot measure traces each of those chains in full.

A program's age band is a label, not a rule

Every program carries one of five age tiers, and their bands appear in three different places in PTRS, agreeing with each other, which is worth noting because it is rarer in this product than it should be:

Tier	Band	Age range the create form writes
Juniors	Ages 6 to 8	6 to 8
Tweens	Ages 9 to 12	9 to 12
Teens	Ages 13 to 15	13 to 15
Senior Teens	Ages 16 to 18	16 to 18
Mixed	All ages	5 to 18

No regulation is cited for any of these bands anywhere in PTRS. Treat them as the product's own label, not a licensed age range, because that is also how PTRS treats them: nothing in PTRS ever compares a child's age with either the tier or the age range, at enrolment or at any other point. See What happens when a child is enrolled.

The edit screen also lets a program's age range be set independently of its tier, and nothing keeps the two in step. A program can be saved as Juniors with an age range of 16 to 18, and nothing in PTRS will object, because nothing checks either figure against anything.

Programs adds no staff-to-child ratio

Attendance already found three disagreeing ratio calculations in PTRS, none of which reads real-time occupancy correctly. A reader coming here should know that Programs adds no fourth: no program, schedule, cohort or booking record carries a staff-to-child figure of any kind. The two capacity numbers this module holds, the program's own capacity and its schedule's capacity, are plain headcounts, and only the first is ever read by anything.

What stays your job

• Set and track a program's actual meeting schedule yourself, on paper or in a shared calendar. PTRS cannot save a recurring schedule, generate a session from one, book a room, or record a schedule conflict, so nothing about a program's day-to-day timing lives on the screen
• Keep collecting and filing signed consent forms the way the club always has. The Consent tab's Record button always fails, so a guardian's consent for a specific program is never actually captured in PTRS
• Track who is really in a group yourself. A cohort can be named and capped, and nobody can be put in one from any screen
• Check a child's age and eligibility against a program by hand before you enrol them. PTRS never runs that check itself, even where a rule has been typed in
• Treat every enrolment as permanent once made, and note a mistake on paper rather than expecting to undo it. There is no way to remove a child from a program anywhere in the product
• Track grants, funders and partner organisations outside PTRS, in a spreadsheet or on paper. Nothing in the product can create one
• Keep your own record of a program's approved budget and its real spending. The Budget tab's own totals do not add up to anything reliable, for reasons set out below
• Keep a paper or shared-drive copy of a signed program charter and of any compliance and funding documents. The corresponding tabs record a name and a typed web address, not a real uploaded file, and none of it moves through a real approval workflow

What has been built

Twenty screens make up Programs.

Screen	What it is	What it can do today
The program list	Every program at your site or organisation, with status tabs and four stat tiles	Works
A program's overview	Capacity, dates, age range, waitlist, roll, tags, lifecycle and version history	Mostly works. A snapshot can be read back and never restored
The Schedule tab	The recurrence editor, the session list, and exceptions	Loads and looks complete. Nothing on it can actually be saved
The Enrollment tab	The roll, the waitlist, Bulk Enroll, and the eligibility rule builder	Enrolling and bulk enrolling both work. A typed eligibility rule is stored and never checked
The Cohorts tab	Create and cap a named group	Creating works. Nobody can be put in one
The Consent tab	Build a consent form, and a queue of who still needs to sign	Building a form works. Recording a signed consent always fails
The Program Calendar	A month grid of room bookings	Loads and is permanently empty, and is linked from nowhere in the product
The Curriculum Builder	Build a curriculum out of units and sessions	Creating and publishing work. Nothing inside a unit or session can be renamed, reordered, or filled in
The Resource Library	A searchable, organisation-wide library of teaching materials	Adding and searching both work. Nothing can be attached to a session
The Staff tab	Assign staff to a program, and check their credentials against it	Assigning, listing and removing staff all work. The credential check can never run
The Goals tab	Set goals for a program and track them on a dashboard	Creating a goal works. Its status can never change, and every dashboard tile but one reads zero
The Assessments tab	Create an assessment and compare results before and after	Creating an assessment works. No score can ever be recorded for any child
The Surveys tab	Build a survey with several question types	Building a survey works. Nobody can answer one, anywhere in PTRS
The Evaluation tab	Record a program evaluation	Loads and does nothing. Its Create button closes the dialog and saves nothing
The Charter tab	Draft and approve a program charter	The one Programs screen that runs start to finish
The Budget tab	Track a program's budget and its expenses	Creates a budget and records expenses. Its running totals do not update
The Partnerships tab	Track a partner organisation and its agreements	Nothing in PTRS can create a partner, so this tab has nothing to show
The Compliance tab	Track a program's DELACARE, OCCL and federal requirements	Shows a red 0% Compliant on every program and checks nothing
The Documents tab	File a program's compliance and funding documents	Records a document's name and a typed web address, not a real file
The AI brainstorm tools	Seven AI drafting helpers for a program's charter, curriculum and more	Works, from the sidebar and from inside a program

What happens on its own

No background task or scheduled job of any kind touches this module. A program whose end date passed months ago stays Active until somebody changes it by hand, a waitlist is never worked unless somebody opens the tab, and no enrolment, promotion or consent produces a notification, an email or any other message. That last part is true across all of PTRS: PTRS has never sent a notification of any kind, anywhere in the product.

What it connects to

Connects to	How
Members	Enrolling a child into a program, and the licensed-capacity check that runs when you do, both happen here, not on the child's record. The child's own Programs tab reads this module's tables, and the link is solid, with one caveat: the consent status that tab shows is never written by anything
Centers	Enrolling a child checks the site's licensed capacity, held on the site's own profile in Centers. This is the only place in PTRS that check is ever consulted
Attendance	An attendance session is meant to attach to a program's schedule. Structural only: no session can be created here, so there is nothing for an attendance session to attach to
CACFP	A meal count is taken against children on a roll, and CACFP keeps an entirely separate enrolment of its own with no shared identifier
Notifications	Not connected. Nothing in Programs sends a message of any kind
Staff	Assigning a staff member to a program, and checking their credentials against it, are both meant to work together. Assigning, listing and removing all work; the credential check, the only one in PTRS that runs against a specific program, can never actually run

Not yet available

A program's schedule, sessions and exceptions cannot be saved

The Schedule tab's recurrence editor looks complete: pick a frequency, days of the week, start and end times, and it prints back a plain sentence describing what you built. Pressing Save does nothing at all. No request is sent, no message appears, and the panel stays open.

Generate Sessions and Add Exception fail for a related reason: both need the identifier of the schedule they are working against, and both try to read it from the program's existing list of sessions. With no sessions yet, that identifier is blank, and the request goes nowhere. PTRS reports a plain, unhelpful error and nothing is created.

So a program's actual meeting days, times, holidays and closures cannot be recorded anywhere in PTRS today.

A room cannot be booked, and a booking can never be confirmed or cancelled

Booking a room for a program session is built correctly on the server, and checks for a clashing booking in the same room. Nothing in the interface calls it, so the Program Calendar's month grid is permanently empty and its conflict warnings never appear.

A booking also has three possible states, tentative, confirmed and cancelled, and only the first is ever set by anything in PTRS. There is no way to confirm or cancel a booking from any screen, even though both states are shown in the calendar's own legend.

A guardian's consent for a specific program cannot be recorded, and a consent form cannot be corrected

The Consent tab's pending queue lists every child who still needs to sign a form, and its Record button opens a real signing dialog: grant or deny, a drawable signature, an optional expiry date, and it always fails. The screen sends a blank guardian identifier, and PTRS refuses the request before it is even read. The same dialog also fails to show the form's actual wording, so a guardian would be asked to sign something they cannot read on screen.

A consent form also cannot be edited or turned off once created. The Inactive badge on a form's card describes a state nothing in PTRS can ever set.

Because of this, the count of children still needing to sign never falls, and the consent status shown on a child's own Programs tab reads Pending for every program, for every child, permanently, because nothing in PTRS ever writes anything else there.

Two consent records also exist in PTRS with no connection to each other: one kept by Members, on a child's own record, and one kept here, for a specific program. A consent recorded on one side is invisible on the other, so do not assume a consent captured on a child's Overview tab satisfies a specific program's Consent tab, or the other way round.

Nobody can be put in a cohort

A cohort can be created, named and capped from the Cohorts tab, and that is as far as it goes. Putting a child into one, and taking a child out of one, are both built correctly and reachable from no screen anywhere. Every cohort's member count reads zero, permanently, and a child's cohort never shows on her Programs tab.

There is also no way to rename, resize or delete a cohort once created.

A child cannot be withdrawn from a program

Removing a child from a program's roll is built correctly and complete, and no button, menu or control anywhere in PTRS reaches it. There is no delete option either. Once a child is enrolled, she stays on the roll, occupying a seat against the program's capacity and against the site's licensed capacity, permanently. Check a child carefully before you press Enroll.

A typed eligibility rule is never actually checked

The Enrollment tab's rule builder writes a real, typed rule: an age limit, a grade requirement, a gender restriction and several other kinds, each with its own comparison, and nothing in PTRS ever runs it. Enrolling a child does not consult it, and the one screen that would let somebody run the check by hand does not exist either.

Even setting that aside, most of the rule types the builder offers are not actually implemented behind the scenes: only an age rule and a grade rule are evaluated in full, and every other rule type is reported as satisfied no matter what it says. A rule reading "must not be male" would, if it ever ran, let every child through regardless.

A program snapshot cannot be restored, and its history of status changes is never read

The Snapshot button on a program's overview correctly saves the program's full settings as a numbered version, and that version can be opened and read at any time. There is no way to turn a snapshot back into the program's live settings; if something needs undoing, somebody has to read the old snapshot and retype the values by hand.

Every time a program moves from one lifecycle status to the next, PTRS also writes down the previous status, the new one, who made the change and why. Nothing in PTRS ever reads that record back. Treat the reason box on a status change as a note for nobody: it is saved and never shown again.

The Program Calendar is linked from nowhere

The Program Calendar renders correctly and no menu, tab or link anywhere in PTRS points at it. The only way to reach it is to type its address directly, and once there, it has nothing to show anyway, because no room booking can be created.

A curriculum unit or session cannot be renamed, reordered, or filled in

Adding a unit or a session to a curriculum always uses the same fixed name, New Unit or New Session, and there is no way to rename either one afterward. Every unit and session in every curriculum in your organisation carries the same name.

Dragging a unit or session into a new position always fails with a red error naming the wrong technical term for what you dragged, and the row snaps back to where it was. And once a session exists, nothing can actually be put inside it: its three sub-tabs for activities, materials and assessments are all read-only, with no way to add anything to any of them. This is also why a resource library item can never be attached to a session: attaching one is the one thing that would put something inside a session, and it is unreachable the same way.

No program can be given a certification requirement, so its Staff credential check is permanently empty

Checking a staff member's credentials against a specific program is real and correct, including the grace period it allows before a credential is treated as expired, and it is the only credential check in PTRS that works against a specific program rather than a person's file in general. It can never actually run, because the certification requirements it is meant to check against cannot be created anywhere in the product. So the Staff tab's compliance section reads "No compliance data" on every program, whether a requirement has been met or none was ever set.

A goal's status can never change, and nothing about it can be measured

A goal can be created for a program and stays in its starting status forever: nothing in PTRS ever moves it forward. So the Goals dashboard's tiles for achieved, in progress and at-risk goals all read zero on every program, no matter how many goals exist or how long ago they were set.

Adding an objective, a measurable success criterion, or a single measurement toward a goal's target are all built and reachable from no screen. A goal's expanded card never shows a target, a current figure, or a checklist of what was supposed to happen, because nothing can ever put one there.

No assessment score can be recorded for any child, and nobody can answer a survey

An assessment can be created for a program, and no score for any child can ever be recorded against it. The Assessments tab's result counts, and its comparison of scores before and after, all read zero and stay that way.

A survey can be built with several question types and stored correctly. There is no screen anywhere in PTRS, including the Parent Portal, where a guardian or a child can actually answer one. Every survey reads zero responses, permanently. A survey also cannot be edited once created.

What Programs can and cannot measure follows each of these chains in full, alongside the goals gap above and the evaluation gap below.

The Evaluation tab does nothing at all

Recording a program evaluation loads a screen that looks complete and does not actually connect to anything in PTRS. Its list of past evaluations is always empty, and pressing Create simply closes the dialog without saving anything, on every program, regardless of what is typed in.

A resource library item cannot be corrected once added, or attached to anything

Fixing a wrong title or a broken web address on a library item is built and reachable from no screen, so the only fix is deleting the item and adding it again. The library's own stated purpose, making material available to a curriculum session, cannot actually be carried out either, because attaching an item to a session is unreachable for the same reason a curriculum session cannot hold anything at all, described above.

PTRS has no grant management screen of any kind

Recording a funder, a grant against it with an amount and an award date, a reporting requirement with a due date, and an allocation of that money to a specific program are all built correctly, on the server, as a complete set that fits together, and none of it has a screen. There is no funders screen, no grants screen and no allocations panel anywhere in the product.

So a program's budget cannot be connected to where its money actually came from, and a funder's reporting deadline cannot be recorded at all. Since nothing in Programs runs on a schedule, nothing could remind anyone of that deadline even if it were recorded.

Nothing in PTRS can create a partner organisation

The Partnerships tab's New Partnership dialog offers a dropdown of partner organisations to choose from, and that dropdown is always empty, because creating a partner organisation is built and reachable from no screen. Pressing Create with no partner selected does nothing at all: no request, no message.

A partnership is also created in a starting status with no way to move it forward, so an agreement can never be marked signed and a contribution's value is stored and never actually totalled or reported anywhere.

The Compliance tab shows every program as 0% Compliant, whatever the truth is

The Compliance tab does not connect to PTRS at all: its list of requirements is always empty and its score, shown as a red 0% Compliant badge, is worked out from that empty list every single time. It looks exactly the same whether every DELACARE, OCCL or federal requirement for a program has genuinely been met or none was ever recorded.

The two checks behind this tab work correctly and have no screen calling them either, so a program's compliance requirements cannot be recorded in PTRS at all, by any path.

A budget cannot be allocated, approved, or reconciled

Approving a budget, and rolling up its line items into an allocated total, are both built and reachable from no screen. So a budget's Allocated figure reads $0.00 on every program, and no budget has ever actually been marked approved, even though PTRS would allow one to be saved as approved with no approver and no date recorded at all.

Every expense also stays in its starting, pending status forever: nothing moves an expense to approved, rejected, paid or voided. So a budget's Spent figure means only "entered", not "approved", and nothing recalculates it from the expenses on file.

A charter is fixed the moment it is created, and its approval workflow does not run

A program charter's title, mission, vision and scope can only be set once, at creation. There is no way to correct any of them afterward, and a charter's effective and expiration dates can never be set either, so a charter never expires on its own. A rejected charter is also a dead end: there is no way to revise and resubmit it from any screen.

The configurable, multi-step approval workflow the charter's own data implies exists as a shape in the database and nowhere else: nothing in PTRS ever reads or writes it. Approving a charter is a single yes-or-no action, not the staged workflow it appears to support.

A document cannot actually be uploaded, versioned, or archived

The Documents tab's Upload Document button has no file picker. It asks for a web address and a file name, typed in as plain text, so a document record points at whatever was typed rather than an actual uploaded file.

Version history is also always empty, for two separate reasons: creating a document does not create its first version record, and the control that would add a new version afterward is built and reachable from no screen. And once a document is marked active, nothing in PTRS ever archives it, so the Archived count on this tab reads zero forever.

The national program pillars are empty outside a development copy of PTRS

The six national program pillars, Academic Success, Good Character and Citizenship, Healthy Lifestyles, Career Readiness, Arts and Culture, and STEM, are only ever given to a copy of PTRS built for the development team. A live, installed copy of PTRS starts with none of them, and there is no screen anywhere that can add one, so a program's pillar tags resolve to nothing.

This is the third table in PTRS found so far whose only source is a development-only starting set, after two similar gaps found in CACFP.

Where to go next

Do a task:

• Set up a program, create it, move it through the lifecycle, tag it and snapshot it
• Enrol a child into a program, the one path with a working capacity check, and the two that skip it
• Work the schedule and calendar screens, what each control does, and which of them do nothing
• Work the cohort and consent screens
• Build a program curriculum, what the Curriculum Builder can create, and the four things it cannot
• Work the resource library, the one Programs screen a regional director can use
• Assign staff to a program, and why the credential check beside it can never show anything
• Work the goals, assessment and survey screens
• Approve your first program charter, the one Programs workflow that runs start to finish
• Work the charter and budget screens, which figures on the Budget tab are real
• Work the partnerships, compliance and documents screens
• Work the AI brainstorm screens, the one Programs screen a staff member can use

Look something up:

• Who can do what with a program's setup, schedule and enrolment, and whether anything in the product actually reaches it
• Who can do what with curriculum, staffing, goals, assessments and surveys
• Who can do what with money and governance and what a program's funding and charter approval require
• Program and enrolment fields, what goes in each box, and which boxes have no rule at all
• Curriculum and goal fields, the same for the delivery screens

Understand why:

• What happens when a child is enrolled, the one chain in PTRS with a working regulatory check in it, traced across three modules
• What Programs can and cannot measure, five chains, and where each one breaks
• What Programs can and cannot account for, where a program's money is recorded, and why no figure reconciles with another

When something goes wrong: Programs troubleshooting.