digital-safety-reporting

Jake Ducharme

Prompt 1 — Establish the project and requirements I’m building ClearSignal, a digital-safety reporting and learning workspace, starting from a separate experimental copy of my existing GuardAd prototype. This is a contained product experiment that may become a working product if the result is strong. Shared product brief ClearSignal helps people document and understand digital experiences that may affect safety or wellbeing, then share useful, reviewed information when they choose. A concern might involve advertising, suspicious contact, scams, privacy practices, risky product features, or harmful content. The first version should stay focused on one complete workflow: Document a concern → review it → make a decision → optionally share a redacted summary. The reporter controls whether a submission stays private or is considered for public sharing. Submissions and evidence are private by default. Nothing becomes public automatically. This is an educational and reporting tool, not an emergency service, law-enforcement system, clinical tool, or way to monitor a child. Do not claim that a report proves wrongdoing. Do not make legal or safety determinations automatically. Initial user roles Visitor: reads public, approved summaries and product information. Reporter: submits concerns, manages their own reports, and controls sharing consent. Reviewer: reviews assigned reports, requests clarification, redacts information, and recommends a decision. Administrator: manages reviewer access, report categories, and escalations. First-version scope Include account creation and sign-in, a guided report form, private evidence attachments, reporter report history, reviewer queue, clarification requests and replies, review decisions, redacted public summaries, and a public library of approved summaries. Include realistic demo records clearly labeled as fictional. Do not build company accounts, public comments, community voting, reputation scores, automated investigations, external agency submissions, payment features, or social networking in this version. Your task Create the System Requirements Document for this exact first version. Define user needs, functional requirements, nonfunctional requirements, role permissions, report states, privacy defaults, and acceptance criteria. Identify assumptions and unresolved decisions separately. Keep requirements testable and keep the build small enough for a one-month platform experiment. Do not implement code yet. Present the requirements for review and approval before proceeding. Prompt 2 — Map user flows and permissions Continue the ClearSignal project using the approved requirements as the source of truth. The product purpose is to help people document digital-safety concerns, have them reviewed, and optionally share redacted summaries. Reports and evidence are private by default; no submission is published automatically. Do not expand the approved first-version scope. Map the complete flows for: A visitor reading public summaries. A reporter creating an account and submitting a concern. A reporter submitting without public-sharing consent. A reporter opting in to consideration for a redacted public summary. A reviewer requesting clarification and receiving the reporter’s reply. A reviewer recommending a decision and an administrator approving or returning it. A reporter viewing the status and history of their own report. An administrator managing reviewer access. For every flow, show the screens, actions, validation, success states, errors, and permission checks. Define what each role can view and change. Include edge cases such as a withdrawn report, a failed evidence upload, a reporter changing sharing consent, duplicate submissions, and a report rejected from publication. Preserve the rule that only an administrator-approved, redacted summary with explicit reporter consent may appear publicly. Do not expose private evidence, identifying details, reviewer notes, or reporter identity in the public library. Produce screen-by-screen user flows and an updated permission matrix for review. Do not implement until approved. Prompt 3 — Design the experience Continue ClearSignal from its approved requirements and user flows. Keep the same scope and privacy rules: reports and evidence are private by default; public sharing requires explicit reporter consent, redaction, and administrator approval. Design a calm, trustworthy, accessible responsive web application for adults reporting digital-safety concerns. Avoid alarmist colors, fear-based copy, surveillance imagery, child-targeted engagement patterns, and gamification. The interface should communicate that a concern can be documented without proving intent or wrongdoing. Create and review designs for: Public landing page and approved-summary library. Sign-up and sign-in. Guided report submission, including category selection, narrative, optional link, optional evidence upload, and sharing-consent choice. Reporter dashboard and report detail/history. Reviewer queue, report review, clarification request, redaction, and decision recommendation. Administrator review and approval of a proposed public summary. Empty, loading, error, upload-failure, and access-denied states. Use plain language, clear progress indicators, keyboard-accessible controls, readable contrast, mobile layouts, and explicit privacy explanations at the point of choice. Mark all synthetic reports and public examples as fictional demo data. Deliver clickable designs and a concise design system. Do not invent new features or start implementation until the designs are approved. Prompt 4 — Plan architecture and data Continue ClearSignal using only the approved requirements, flows, and designs. Before implementation, propose the simplest maintainable architecture supported by 8080 and the imported repository. Explain any recommended changes to the starter code before making them. Define the data model for users and roles, reports, evidence metadata and private file storage, clarification exchanges, review assignments, review events, redactions, consent history, and public summaries. Every report should have a traceable status history. Store consent changes as auditable events. Specify server-side authorization rules. Reporters may access only their own reports and evidence. Reviewers may access only reports assigned to them. Administrators may manage the queue. Public users may access only approved public summaries. Never rely on hiding interface elements as the only permission check. Specify file validation, size limits, safe storage, error handling, and protections against exposing private files through public URLs. Identify authentication, database, storage, and deployment services the project requires; do not assume credentials or external integrations are available. Keep personal information to the minimum needed for this workflow. Produce architecture diagrams, the data model, API or backend-function boundaries, security rules, environment-variable requirements, and a phased task plan with dependencies and acceptance criteria. Flag anything that could create cost or require my account setup. Wait for approval before building.