Incident Records, Comments, Sightings & Attachments

Audience: Reporters and reviewers working with submitted incidents.
Read first: Incident reporting for how the record is created.
Companion: Review workflow for moderation decisions.
Mindset: This page is operational history — treat it like an audit log, not a chat thread.

Purpose

The incident detail page is the durable operating record for one event. Everything connected to the incident — narrative, moderation decisions, follow-up sightings, supporting files, and comments — lives on this page so future readers can reconstruct what happened and why.

Use the page like an issue tracker entry, not a chat room. The audience includes people who were not present when the event occurred and may read it months later.

Record anatomy

An incident record is organized into structured fields and freeform content. Knowing which is which helps you decide where to put information.

Structured fields

Field	Source	Changes after submission?
Title	Reporter	Reviewer may request changes.
Occurred at	Reporter	Reviewer may correct after clarification.
Mapped site & location detail	Reporter	Reviewer may correct.
Severity	Reporter, adjusted by reviewer	Yes — reviewer may up- or down-grade with a comment.
Operational status	Reporter, adjusted by reviewer	Yes — moves between open, monitoring, resolved.
Visibility	Reporter, adjusted by reviewer	Yes — reviewer may narrow or broaden during moderation.
Tags	Reporter, augmented by reviewer	Reviewer may add or correct tags.
Moderation state	System & reviewer actions	Yes — transitions through submitted, under review, verified, etc.
Reviewer assignment	Claim action	Yes — reassignment is allowed.

Freeform content

Narrative — the reporter's structured description.
Comments — reviewer and team discussion threaded under the record.
Sightings — operational follow-up events along the timeline.
Attachments — supporting files.

Treat the record as operational history. Avoid casual discussion that would not help a future reviewer, administrator, or partner understand the event.

Comments

Comments appear under the incident body like an issue-tracker thread. Use them for reviewer context, clarification notes, operational observations, and decisions that should remain tied to the incident. Comments should explain why something was done, not just that it happened.

Comment when

Visibility is narrowed or broadened — record the reason.
A reviewer verifies a report after resolving ambiguity — note what was clarified.
A partner or internal team member needs context for later action.
Severity is adjusted — explain the basis for the change.
A duplicate or related incident is identified — link by ID.

Don't comment for

Asking the reporter to fix something — use request changes in the review workflow instead.
Unrelated team chatter — use your internal coordination channel.
Operational follow-up observations — log a sighting instead.

Sightings & timeline

Use the timeline to log follow-up sightings: patrol confirmations, witness updates, recurrence of the same subject or vehicle, or later operational observations. A sighting should include what was observed, where, and when.

Sighting fields

Field	What to enter
Observed at	The time of the new observation, not the time of logging.
Location detail	Where on the site or in the surrounding area; mapped site if applicable.
Description	What was observed and how it connects to the original report.
Reporter	The Castlewatch user who observed or logged the sighting.

The timeline is not the place for broad discussion — use comments for discussion and sightings for event updates.

Attachments

Attachments can support the incident record with documents, photos, exported evidence, or other files. Only upload files that are appropriate for the organization to retain and review. Avoid unnecessary sensitive material, and use the smallest file set that supports the operational need.

Good practices

Name files clearly before upload: north-lot-14-20-vehicle-1.jpg, not IMG_4839.jpg.
Do not upload unrelated evidence just because it exists.
Remove incorrect attachments promptly if your role allows it.
Crop personally identifying information out of images when it is not operationally relevant.
Prefer exported reports (PDF) over raw screenshots when possible — smaller and easier to review.

What not to attach

Photos of minors without explicit authorization.
Documents containing unrelated personal data.
Large unprocessed video files — export a clip or still frame instead.

Record maintenance

Keep comments factual and concise.
Use timeline sightings for observed follow-up events.
Use attachments only when they add operational value.
Review tags and classification if a report becomes part of a larger pattern.
Return to the review workflow when facts or visibility need formal moderation.
Resolve operational status (open → monitoring → resolved) as the situation evolves.

Common scenarios

The same vehicle returns the next week

Log a sighting on the original incident timeline rather than filing a new report. Include the new observation time, location, and a brief note connecting it to the original event. If the pattern becomes substantial, escalate via comment and consider re-visibility.

You realized the narrative had an error after submission

If a reviewer has not yet claimed it, you can edit limited fields directly. Otherwise, comment with the correction and ask the reviewer to request changes so you can amend the narrative cleanly.

A partner asks for the original report

Confirm the partner is connected and visibility includes them. If not, broaden visibility deliberately via the review workflow — do not paste the narrative into a partner message.

An attachment was uploaded by mistake

Remove it if your role allows, then comment briefly noting the removal. If you cannot remove it yourself, ask a reviewer or administrator.

Frequently asked questions

Can incidents be deleted?

Not as a general user action. Reports can be rejected during review or marked rejected later by an authorized reviewer. Genuine deletion is rare and reserved for accidental submissions or legal-compliance requirements; ask your administrator.

How long are records kept?

Indefinitely by default. Your organization's data retention policy should govern when records are archived or removed. Discuss with your administrator if you have specific retention requirements.

Can comments be edited or deleted?

Authors may edit or delete their own comments shortly after posting. Older comments are part of the audit record and should not be edited — post a follow-up correction instead.

Who can add sightings?

Reviewers and members with access to the incident. Subject to your organization's role configuration.

Will partners see comments?

Comments are visible to the same audience that can see the incident record. If you want a comment to remain internal, mention that explicitly in the text and consider whether visibility should be narrowed.