- Audience
- Reporters and members who occasionally submit incidents.
- Time
- ~10 minutes for a complete report; under 2 minutes once familiar.
- Read first
- Workspace orientation from your administrator.
- Read next
- Incident records for what happens after submission.
Purpose
The reporting form captures an incident in a consistent structure so reviewers can decide what happened, what still needs clarification, and who should see the record. It is not just a free-text note. The structured fields power the dashboard, search, review queue, trusted partner visibility, and later incident history.
A well-written report saves the reviewer time, reduces back-and-forth, and produces a record future readers can actually use. A rushed report tends to come back as "request changes" and consume more time than it saved.
Required fields
| Field | What to enter | Example |
|---|---|---|
| Title | A short label describing the operational issue. | "Suspicious vehicle near north entrance" |
| Summary | One paragraph: what happened and why it matters. | "At ~9:15 a black sedan circled the north lot three times. Driver photographed the entrance, then left when approached." |
| Detailed narrative | Chronology, observations, staff response, follow-up needs. | See Narrative writing below. |
| Incident type | Structured category for search and pattern recognition. | "Suspicious surveillance" |
| Occurred at | The event time, not the submission time. | "2026-05-18 09:15" |
| Mapped site | The saved site closest to the event. | "Main Campus — North Lot" |
| Severity | Potential impact and urgency. See Severity & status. | Medium |
| Visibility | Audience scope for the verified report. See Visibility. | Origin only |
| Tags | Searchable labels for patterns. | vehicle, photo, surveillance |
Severity & operational status
Severity describes potential impact and urgency. Operational status describes what is still happening or needed. They are independent: a medium-severity report can still be open, and a high-severity report can be in monitoring if immediate action has already been taken.
| Severity | Use when | Examples |
|---|---|---|
| Low | Notable but limited concern, usually no immediate escalation. | Lost item that may indicate a minor pattern; a brief verbal disagreement that was de-escalated. |
| Medium | Meaningful security concern requiring review or follow-up. | Suspicious surveillance; recurring trespasser; unusual after-hours access attempt. |
| High | Serious concern that may affect operations, safety posture, or partner awareness. | Threats made on premises; weapon sighting that did not escalate; significant trespass with evasive behavior. |
| Critical | Immediate or severe issue requiring expedited attention. | Active threat-of-violence statements; intrusion in progress; partner-facing safety alert. |
When unsure between two levels, pick the higher one and let the reviewer adjust. Under-reporting severity is harder to recover from than over-reporting.
Location & mapped sites
Use a saved mapped site whenever possible. Saved sites provide coordinates for the dashboard map and reduce ambiguity for reviewers. The campus or location detail should still describe the exact place involved: north entrance, children's wing, west parking lot, lobby, or off-site event location.
- Pick the closest mapped site that matches the event.
- Add a free-text location detail to specify which entrance, lot, or room.
- If the event happened off-site (transit, partner location), still record the closest meaningful site and explain the off-site context in the narrative.
If no saved site is selected, the report can still be submitted, but it may not appear on the incident map until a mapped site exists. See Organization settings → Mapped sites to add one.
Visibility choices
Visibility controls who should eventually be able to read the report after review. Use the narrowest option that supports the operational need. Reviewers can still narrow further during moderation.
| Visibility | Audience | Use for |
|---|---|---|
| Origin only | Members of your organization with read access. | Internal-only events; events that need narrative clarity before any sharing. |
| Selected partners | Specific connected organizations. | Events directly relevant to one or two named partners (shared event, shared facility). |
| Trust group | All members of a named coalition. | Regional patterns: vehicle descriptions, recurring trespassers, coordinated activity across sites. |
| Region | Broader regional awareness audience. | Rare; reserved for events your administrator has agreed warrant region-wide awareness. |
Narrative writing
The narrative is where most reviewer time is spent. A good narrative answers three questions in order: what was observed, what staff did, and what is still needed. Stick to direct observations; label assumptions clearly.
Template
- Timeline: brief chronology with timestamps where possible.
- Direct observations: what was seen, heard, or measured — not interpretation.
- Staff response: who responded, what they did, who was notified internally.
- External involvement: law enforcement, partner staff, EMS, or facility management contact.
- Follow-up needs: what should happen next, by whom, by when.
Good vs. weak narratives
Weak: "A guy was acting weird in the lot today."
No timeline, no observable detail, no response, no follow-up. The reviewer cannot decide severity or visibility from this.
Better: structured narrative
"At ~14:20 a male individual (estimated 30s, dark hoodie, no visible affiliation) circled the south lot on foot for 6–8 minutes, stopping near each of three doors. When greeter A approached at 14:28 he walked toward Maple Ave and left on foot. No verbal contact was made. Greeter A notified the lead usher and logged this report. Suggested follow-up: review camera footage 14:15–14:35; flag if pattern recurs Saturday evenings."
This narrative gives a reviewer enough to verify, assign tags, and decide on visibility.
Quality checklist
- State only what was observed directly; label assumptions as assumptions.
- Include event time, location, and staff response.
- Avoid unnecessary personal identifiers unless they are operationally relevant.
- Add tags a future reviewer would search for.
- Choose visibility intentionally rather than leaving broad sharing on by habit.
- Re-read the narrative once before submitting — you will catch most ambiguity yourself.
Common scenarios
You are reporting after the fact (yesterday's event)
Use the actual occurred-at time, not today's date. Note in the narrative why the report is late ("noticed pattern when reviewing footage today"). Reviewers handle late reports differently than active ones.
You witnessed a partner organization's event
File the report in your own workspace with origin-only visibility, then use partner messages to notify the affected partner. Let the partner decide whether to escalate within their workspace.
The event involved a member of your own team
Submit using neutral, factual language. Use origin-only visibility. Avoid speculative personal commentary. A reviewer will decide how to handle the record from there.
Severity feels ambiguous
Pick the higher level. Add a comment after submission explaining the uncertainty so the reviewer can downgrade with context.
Frequently asked questions
What if I don't know the exact occurred-at time?
Use the best approximation and note the uncertainty in the narrative ("~14:20, between 2:15 and 2:30"). Do not leave the field blank or use the submission time as a stand-in.
Can I edit a report after submitting?
Limited fields can be edited before a reviewer claims the report. After review starts, ask the reviewer to request changes, which returns the report to you for edits.
Should I attach photos?
Yes when they materially clarify the event. Avoid attaching general or sensitive material. See Incident records → Attachments.
Will the subject of my report see it?
No. Castlewatch does not notify report subjects. Visibility controls who in your workspace and partner network can read the verified record.
The submit button isn't working — what now?
Check for a red field validation message or a toast at the top of the page. The most common cause is a missing required field. If the form is otherwise complete, see Troubleshooting → Blocked reports.