The incident log: what gets written, who can read it, how long it lives

A safeguarding incident log is the club's record of a concern raised about a child: what was observed, by whom, when, and what was done about it. Its purpose is reconstruction — someone who was not there, who may know none of the people involved, has to read it 8 months later and understand what was known at each point in time. That requirement decides the fields, the write rules and the access list, and it is why this cannot be a notes box on a member record.

It is not a judgement engine, and it decides nothing. Categories, escalation thresholds and the decision to refer a concern onward belong to the club and its governing body. Software builds the record, the access control and the reminders. That boundary holds without exception across our sports and fitness work.

The 10 fields, and the 3 that most forms omit

The 3 routinely missing are others-present, the review date and the access list: the fields with no payoff on the night, whose value appears only when somebody else reads the record. Splitting fact from interpretation is the other habit to enforce in the schema rather than in training — give the reporter 2 boxes and label them, for the reason the free-text coach note is the best field in the schema sets out: unconstrained text earns its place when its status is unambiguous.

Write it for someone who has never met the child

Most incident records fail on legibility, not completeness: written in the shorthand of people who were in the room, they are unreadable to the next welfare officer or the same coach 2 seasons on. The general version is an audit record that still makes sense a year later.

• Name the source of every fact. 'I saw' and 'a parent told me she saw' are different claims and the sentence must say which.
• Quote rather than summarise. A summary of what a child said is the reporter's interpretation wearing the child's voice.
• No initials, no nicknames, no squad shorthand. Every person is a record link or a full name with a stated role.
• Absolute times, 1 timezone. 'After training' is not a time; the session ended at a known hour.
• Write before discussing. An account composed after talking to 3 other people is merged, and no later reader can unmerge it.

The read list sits below the administrator role, not above it

Everywhere else the administrator sees most: rosters, attendance, dues, contacts. This object inverts that. Readers are the 2 people the club has appointed to the welfare role — an officer and a named deputy — plus anyone added to a specific record because they are handling it. Membership of the admin group grants nothing, and neither does having set the software up.

• Evaluate access per record, not per role, so an adult named in one cannot read it by virtue of their job.
• Log reads as well as writes. Who opened a record and why is part of its history.
• Guardian access is a separate decision with a redaction problem attached: a parent's request to see or erase a child's record.
• In a split household, who may be told what must not be settled by whoever logged in last — precedence rules in one household, 3 children, 2 guardians with different consents.

Nothing is edited: how a correction gets recorded

1. The reporter writes the account and saves it. The server stamps the time; the form offers no date field for that stamp.
2. The welfare officer acknowledges as a new entry with its own actor and time, not a status flag overwritten on the record.
3. Every action appends as it happens: a call made, a conversation held, a referral sent, a decision that nothing further is needed.
4. A referral appends recipient, time and the reference given back. No reference given is itself recorded.
5. A correction is a new entry naming what it corrects. The original text stays exactly as written.
6. A review date creates a task with an owner, and stays visible as overdue when nobody does it.

A record you can edit answers the question 'what do we say happened'. A record you can only append to answers 'what did we know, and when' — and that is the question anyone actually asks.

It outlives the membership, the season and usually the platform

Retention here runs on its own clock, normally far longer than anything else the club holds and long after the member record would ordinarily be purged. The period is set by the club under its governing body's policy and its own legal advice; what software owes them is that the period is a stored field with a stated source rather than an assumption in somebody's head. The engineering consequence is direct. The deletion job needs an explicit exclusion for this class and the exclusion needs a test, because a sweep that quietly takes safeguarding records along with an erased member is the worst bug available here — see building deletion that actually runs in a youth club system.

One boundary is tempting to cross. A concern sometimes first shows up as a change in the data — a child who stops turning up, a household whose payments start failing — but those are commercial signals, and what visit frequency or a failed payment actually tells you is a retention question. Routing that inference into a welfare record puts unfounded suspicion into the one object that must hold only observed fact.

We build the record; the club owns the judgement

Say this out loud with a club before any of it is built. They own the categories, the thresholds, the referral routes and every decision about a specific concern. The build owns the schema, the access model, the append-only guarantee, the review reminders, the retention field and the tests proving all of it survives the next release — the shape of most internal tools and operations work. One overlap catches clubs out: an image published against a restriction is usually reportable under their own policy as well as being a defect, so tracing the leak, covered in the restricted child who appeared in the published clip, often ends with an entry in this log. The rest of the model for under-18s sits in guardians, minors and safeguarding.

• safeguarding
• record keeping
• access control
• youth sport