Notes & Audit

Two written records that never meet each other. Denise Okafor jots down something the next shift needs to know that does not fit any field on any form. Tom Bradley, getting ready for an OCCL visit, needs to show that a record says what it said and was changed by the person it names. Both live here, and this page covers both, along with the one integrity check in PTRS that actually works and is actually reachable.

What Notes & Audit is for

A note is something a staff member needs the next shift to know, written down where a colleague will actually see it. The audit trail is evidence, for an OCCL inspection or an internal review, that a record has not been quietly altered after the fact.

Who uses it

Who can do this

• Front-line staff
• Site director
• Regional director
• Organisation admin
• Super admin

Both screens are wider than the rule behind them. The wider, first check lets the four administrator roles plus Staff and a read-only account reach both screens. The audit screen's own check then admits a read-only account too, a role the actual rule refuses. The notes screen applies no check of its own beyond hiding the New Note button and the per-card controls, so a regional director and a read-only account both reach the screen and every request fails. Both screens show a clear error rather than an empty list, so at least the failure itself is visible.

Screen	Rule	Who it admits
Notes	The note-management rule	Staff, a site director, an organisation administrator or a super admin
The audit trail	The reporting rule	A site director, a regional director, an organisation administrator or a super admin

The two audiences barely overlap. A regional director can read the audit trail and cannot write a note; Staff can write a note and cannot read the audit trail.

Editing or deleting a note has a third, narrower rule that no written policy actually expresses: the note's own owner, or a super admin. The one attempt to widen that rule to any administrator names a role PTRS does not have, so an organisation administrator cannot edit or delete a note written by someone who has since left.

A day in the life

Denise writes a note about a change in a child's pickup arrangement before she leaves for the day, so the next shift sees it the moment they open the screen. Anyone else with access to notes can see it too, and anyone can pin or unpin it, including someone else's note, because that one action has no ownership check at all.

Weeks later, ahead of an OCCL visit, Tom opens the audit trail and presses Verify Integrity to confirm nothing has been tampered with. On a real, single-organisation installation with real activity in it, a clean result is a real and meaningful answer. On the development copy of PTRS he tested it on first, the same button reported a broken chain on the very first entry, because the copy's own starter data was never run through the same process real activity is.

What PTRS does for you

• Lets staff create, edit, pin, search and remove a note, with the whole flow working end to end.
• Stops one person editing or removing another person's note, checked on PTRS's own side, not just hidden from view.
• Records every change made through PTRS by a signed-in person: what changed, what it changed from and to, and chains each record to the one before it so a removed or reordered record leaves visible evidence.
• Lets anyone who can read the audit trail verify that chain themselves, from inside the product, using the very same method that built it.
• Searches the audit trail by its written description, the resolved person's name, or a record's own id, across the whole log rather than only what is currently on screen.

What stays your job

• Do not rely on the note screen to keep anything private. Every note is visible to everyone who can manage members, and there is no way to mark one confidential; write it on the child's own record instead if it needs to be restricted.
• Do not treat a red result from Verify Integrity as proof of tampering by itself. A few ordinary, harmless conditions produce the exact same red result; read the audit hash chain before drawing a conclusion from it.
• Do not expect the audit trail to show what a scheduled background process did. Anything done outside a signed-in person's own request leaves no trace here at all.
• Do not expect a note written on the notes screen to show up on a child's own record, or the reverse. They are two separate records that never read each other.

What has been built

Screen	What it is	What it can do today
Notes	Every note in the organisation, searchable and filterable by category, with create, edit, remove and pin	The whole flow works; the author's name never resolves, and anyone can pin or unpin any note
The audit trail	A searchable, date-filtered table with a Verify Integrity button	Search and dates reach the whole log; the two dropdown filters only ever look at what is already on screen
Settings	A placeholder heading	Nothing behind it yet

What happens on its own

Nothing here runs on a schedule; none of PTRS's background jobs belong to either of these two screens. One thing happens on every single save anywhere in PTRS, and it belongs here: a record of the change is captured and written after the fact, in a way that cannot undo the change itself even if writing the record fails.

What it connects to

Module	The connection
Every module	The audit record captures a change made anywhere in PTRS. What appears on the audit trail is produced by the whole product, not just this one
Members	A child's own record keeps a second, richer kind of note, with a confidentiality flag and follow-up tracking. Neither this module nor that one reads the other's notes. See Members
Incidents	An incident's own detail screen has its own audit panel, built from this same audit trail filtered to that one incident. See Incidents
Administration	A user's own record shows an activity log built from this same table, and every row of it currently reads "ACTIVITY" rather than a specific action. See Administration
AI Assistant	Sixteen assistant actions write an audit entry alongside their own record. The audit table is also one of the record types the assistant's plain-English data question can reach. See AI Assistant

Not yet available

A working settings screen

The settings screen is ten lines: a heading and a sentence saying configuration is coming. It belongs to no module, checks nothing, and reaches nothing. Every signed-in account, including a guardian or a read-only account, can open it.

Knowing who actually wrote a note

The name behind every note fails to resolve, in all three places PTRS tries. The result is that every author line renders blank, and searching for a colleague's name by typing it in can never find their notes.

The audit trail resolves the same kind of identity correctly in one of its own three read paths and gets it wrong in the other two, the same underlying mistake in a different place. See who can do what on Notes & Audit.

Attaching a note to a child from the notes screen

Every note created from this screen is saved unattached to anything, no matter what you were looking at beforehand. The screen's own subtitle promises notes across members, incidents and programs, and nothing you create here can ever produce one.

The list here is also unfiltered, so notes actually written against a member or an incident elsewhere do appear here too, mixed in with the unattached ones.

Marking a note confidential

This kind of note has no confidentiality flag at all. A child's own record keeps a separate, richer kind of note that does have one. A note about a child written here is readable by everyone who can manage members, with no way to restrict it.

A fully trustworthy answer from Verify Integrity, every time

Three separate, ordinary conditions can each produce a red result with nothing actually wrong.

The record is written as one continuous sequence across every organisation on the installation, and checked one organisation at a time; on an installation shared by more than one organisation, the check breaks on the very first entry that follows another organisation's last one.

Records written together in the same save share the exact same timestamp, and both the writing and the checking rely on that timestamp to decide order; a tie can be replayed in a different order than it was written in.

The starter data any development copy of PTRS is built with was written directly, without the hashing step real activity goes through, so the very first check on a development copy reports the chain as broken from the start.

The check itself is real, and it is the first integrity control found anywhere in PTRS that is both fully built and reachable from a screen. See the audit hash chain.

Filtering the whole audit trail by action or record type

Searching and the date range both reach the whole log, on PTRS's own side. The two dropdown filters for action and record type do not; they only ever look at what has already loaded onto the screen, so a value that is not on the current page is not even offered as a choice, and the total count keeps describing the whole, unfiltered log regardless of what you pick.

Where to go next

• Write something down → Write a note
• Look something up for an inspection → Read the audit trail
• What the chain proves, and what it does not → The audit hash chain
• Who can reach each action → Who can do what on Notes & Audit
• Something is not working → Notes & Audit troubleshooting