Skip to content

Privacy And Retention

This page explains how OpenFloodAI should handle local proof-of-concept data.

Simple meaning: keep only what we need, avoid private data, and delete local test files when they are no longer useful.

OpenFloodAI is not a public warning system yet. The current local POC is for learning, testing, and review.

What Can Be Kept Locally

Local POC runs may keep small structured records, such as:

  • JSON Lines records from a site outputs/ folder
  • camera health records
  • frame metadata records
  • simple visual signal records
  • risk-state records from the test rule engine
  • local replay summary output
  • a few local review images for debugging, when needed

Simple example: it is okay to keep a local .jsonl file that says a video had 100 frames and one NORMAL risk-state record.

These records help developers answer basic questions:

  • Did the video open?
  • How many frames were read?
  • Did the POC create visual signal records?
  • Were any records UNKNOWN or degraded?

What Must Not Be Committed To GitHub

Do not commit:

  • real camera footage
  • real images or snapshots from private cameras
  • exact private GPS coordinates
  • private camera stream URLs
  • passwords, keys, tokens, or certificates
  • personal phone numbers or email addresses
  • private field notes that identify people, homes, or restricted locations

Simple example: do not commit a real rtsp://... camera URL. Use a fake example like camera-demo-01 instead.

Raw Video And Images

By default, do not keep full raw video.

Raw video or snapshots may be kept only when they are needed for review, debugging, or field validation. If they are kept, they should be:

  • stored locally, not committed to GitHub
  • as short as possible
  • limited to a few useful files, not every frame
  • removed when review is finished
  • shared only with people who are allowed to see them

Simple example: if a test fails because a video cannot be opened, a developer may keep a short local clip while debugging. After the fix is confirmed, the clip should be deleted.

Review images are similar. A developer may generate review-baseline.png, review-changed.png, review-comparison.png, and *-overlay.png images to understand one local POC run. Those files should stay local and should be deleted when no longer needed.

The reference-region selector is also local only. It lets a developer open an image in their browser and draw the watched area. The image is not uploaded by the tool. Only the percentage box values should be copied into config.

Simple example: it is okay to copy this safe config-style value:

{
  "reference_region": {
    "x": 40,
    "y": 50,
    "width": 20,
    "height": 30
  }
}

Do not commit the real frame used to choose that box unless it is synthetic or clearly approved for public use.

Validation Dataset Structure

Future validation data should use data/sites/.

Use one folder per site so different rivers and cameras do not get mixed together.

Simple example:

data/sites/colorado-river-windy-gap/
  configs/
  inputs/videos/
  inputs/other/
  labels/
  human-evidence/
    flood-images/
    notes/
  outputs/
    records.jsonl
    summary.md
    operator-notes.txt
    review-images/

human-evidence/flood-images/ is for images that a person selected as possible flood or high-water evidence. outputs/review-images/ is for images generated by OpenFloodAI.

Simple meaning: keep "what the human saw" separate from "what the system generated" so they can be compared later.

Real videos, human-selected images, and generated outputs from real footage should stay local unless they are clearly approved for public sharing.

Hard-case metadata may be committed only when it is safe and broad.

Simple example: camera shake made the view unclear is okay. A note with a private camera URL, exact GPS point, or details about a nearby home is not okay.

Location Privacy

Exact GPS coordinates can be sensitive.

They may reveal the location of a private camera, a home, a bridge, a restricted site, or a vulnerable community. For early POC work, use broad public location text instead.

Good example:

Demo River near Example Town

Avoid committing:

27.123456, 85.123456

If exact GPS is needed in a future field pilot, it should be treated as private data unless the site owner and project maintainers agree it can be public.

Camera URLs And Contacts

Real camera URLs and contact details are private.

Do not commit them in config files, docs, tests, examples, or screenshots.

Good example:

camera_id: camera-demo-01

Do not commit:

camera_url: rtsp://real-user:real-password@example-camera/live

People, Vehicles, And Sensitive Scene Content

OpenFloodAI must not perform face recognition, person tracking, vehicle recognition, or license-plate recognition. If people, homes, roads, vehicles, or license plates appear in the scene, consider masking or cropping before public deployment. Access to stored video or event evidence should be limited, auditable, and documented (who can access it and why).

Simple example: if a road is visible beside the river, OpenFloodAI should not analyze license plates. The project is about river risk, not tracking people.

Public Versus Restricted Fields In Event/Audit Records

Event and audit records should split fields by sensitivity:

  • Public fields: coarse site name, river name, broad risk state, general timestamp, non-sensitive reason codes.
  • Restricted fields: exact GPS, camera placement notes, raw video references, private contact details, sensitive infrastructure details. These should require access control in a future implementation.

Simple example: a public dashboard might show "Example River near Old footbridge: HIGH candidate." It should not show the camera password or exact camera pole location.

Default POC Retention

Use these defaults for local POC work:

  • Keep local JSON Lines records only while they are useful for debugging or review.
  • Delete local POC outputs when the issue or review is finished.
  • Do not keep raw video by default.
  • Keep short clips or snapshots only when needed.
  • Review local files before sharing a branch, patch, screenshot, or report.

Simple rule: if the file came from a real place or a real camera, pause before sharing it.

How To Delete Local Test Outputs

Local POC outputs should live under the matching site outputs/ folder.

To inspect them:

ls data/sites/example-site/outputs

To delete one local output file:

rm data/sites/example-site/outputs/poc-records.jsonl

To delete all local POC outputs:

rm -rf data/sites/example-site/outputs/*

Only run delete commands when you are sure you no longer need the files.

Future Field Pilots

Before collecting real camera data, a field pilot should have permission from the camera owner or responsible local partner.

The pilot plan should explain:

  • what data will be collected
  • why it is needed
  • who can access it
  • how long it will be kept
  • how it will be deleted
  • whether any location details can be public

Simple example: if a school, bridge owner, local government, or community group provides a camera, they should understand what OpenFloodAI will record and what it will not publish.

Safe GitHub Examples

Good to keep in GitHub:

  • synthetic test records
  • generated test frames
  • fake site and camera IDs
  • broad public demo locations
  • documentation examples

Do not keep in GitHub:

  • real camera footage
  • private stream URLs
  • passwords
  • exact private GPS coordinates
  • personal phone numbers or emails

Current Boundary

This policy does not add cloud upload, public sharing, tracking, a database, alerting, or flood detection logic.

It only explains how contributors should handle local POC data safely.