Black_History_Trail_Project.pdf
PDF 5 MB Posted
- Solicitation number
- 2624RFP
- Issued by
- Volusia County, Florida
About this file
Summary
This is a comprehensive Scope of Work (SOW) document prepared by the City of Daytona Beach for the development of an Interactive Digital Platform consisting of a cross-platform mobile application (iOS and Android via React Native and Expo), a web-based administrative portal (Next.js or Nuxt.js hosted on Vercel), and a unified Supabase backend infrastructure. The project encompasses multiple integrated components including a real-time notifications system (email via Resend, SMS via Twilio, and push notifications via Expo), an AI-powered chatbot assistant ("Ask Daytona") utilizing OpenAI's GPT-4, geographic information system (GIS) mapping with ArcGIS integration, augmented reality (AR) and virtual reality (VR) capabilities, and dynamic content management systems. The platform integrates with existing City systems including Microsoft SharePoint, multiple third-party applications (SeeClickFix, CivicWeb, Rec1, JustFOIA, and others), and supports offline functionality with automatic synchronization upon reconnection. The project is designed to be completed within an 8-month timeline, leveraging existing prototypes and configured accounts to accelerate development, with parallel development workflows across mobile, web, backend, and design teams using agile sprint methodologies.
The SOW establishes that the City of Daytona Beach retains 100 percent ownership of all intellectual property, source code, databases, designs, and digital assets produced under the contract, with developers prohibited from reusing proprietary components outside this project. All infrastructure, including developer accounts, API keys, repositories, and hosting platforms, must be provisioned under City-owned accounts with City IT retaining full administrative control. The document specifies comprehensive technical requirements including encryption standards (AES-256 at rest, TLS 1.3 in transit), role-based access control via Supabase Row-Level Security, multi-factor authentication for administrative users, and compliance with WCAG 2.1 AA accessibility standards, NIST 800-53 security controls, and applicable Florida data protection laws. The project includes extensive testing requirements (unit, integration, end-to-end, performance, accessibility, and security testing with 70 percent minimum code coverage), a structured User Acceptance Testing (UAT) process, mandatory training and knowledge transfer to City staff across three tracks (administrator, content management, and support), detailed change management procedures, comprehensive documentation deliverables, and a 12-month warranty period following acceptance with ongoing maintenance and support under defined Service Level Agreements targeting 99.9 percent uptime, less than 2-second API response times, and crash-free session rates above 99 percent.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 2624RFP_-_City_of_Daytona_Beach_Interactive_Digital_Platform.pdf | ||
| Demo_Application.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
1. Executive Summary
The City of Daytona Beach is commissioning the development of a comprehensive digital platform that integrates a cross-platform mobile application, a web-based administration portal, and a unified Supabase backend. This initiative is designed to enhance civic engagement, streamline access to public information, and modernize the delivery of city services through mobile, web, and emerging immersive technologies.
The scope covers:
• React Native mobile app deployed with Expo EAS, targeting both iOS and Android.
• Web Administration Portal built in Next.js or Nuxt, hosted on Vercel with CI/CD pipelines linked to GitHub.
• Supabase backend for authentication, data storage, file handling, and real-time synchronization.
• AI Assistant (“Ask Daytona”) integrating OpenAI GPT for context-aware responses limited to city-owned data.
• GIS & AR/VR modules leveraging ArcGIS and Agents of Discovery APIs for interactive park and facility experiences.
• Notification System using Resend (email), Twilio (SMS), and Expo Notifications (push) with full subscription management.
This specification defines the technical architecture, security standards, testing requirements, and delivery milestones necessary for a successful deployment. It merges contractual clarity with deep engineering detail to ensure alignment between the City, development contractors, and internal IT staff.
2. Ownership & Governance
All intellectual property, source code, databases, designs, and digital assets produced under this contract are the exclusive property of the City of Daytona Beach. No third-party vendor, subcontractor, or developer retains ownership or licensing rights to any portion of the final system.
Account Control
All environments will be provisioned in City-owned accounts, including but not limited to:
• Apple Developer Program
• Google Play Console
• Expo.dev (organization workspace)
• GitHub (private repositories)
• Supabase (project instances & storage buckets)
• Vercel (hosting for Admin Portal)
• Resend (email delivery)
• Twilio (A2P SMS & voice services)
• ArcGIS (Esri Developer Account)
• Agents of Discovery (Mission API Access)
• Microsoft Graph API integration for SharePoint data exchange
Governance Framework
• Project Steering Committee: Comprised of City IT, Communications, and Procurement divisions. Approves requirements, milestones, and deliverables.
• Change Management: All scope changes must be submitted as formal change requests with impact analysis on budget and timeline.
• Source Control: All repositories reside under the City’s GitHub organization. Pull requests require review and approval from City-designated maintainers.
• Code Ownership: Every line committed to City repos is licensed to the City under permanent exclusive rights. Developers are prohibited from reusing proprietary components outside this project.
• Audit & Access: City administrators retain the right to review logs, deployment pipelines, and cloud configurations at any time.
Deliverable Transfer Protocol
At project completion, the developer must:
1. Transfer ownership of all accounts, tokens, and certificates to the City’s IT department.
2. Commit final source code to City-owned repositories with documentation and version tags.
3. Deliver a complete asset package (Figma files, source images, icons, fonts, and documentation).
4. Provide credential handover and revocation confirmation.
3. Project Components
The Daytona Beach Civic Engagement Platform consists of three major components and a set of interconnected subsystems. Together, they form a unified architecture designed for scalability, performance, and maintainability.
3.1 Mobile Application (React Native + Expo EAS)
The mobile app delivers civic information, city services, and interactive experiences for residents, visitors, and city staff.
• Framework: React Native (Expo SDK 51+), TypeScript-enabled for type safety.
• Distribution: iOS (App Store) and Android (Play Store) via Expo Application Services
(EAS).
• Offline-first: Core data cached locally with synchronization on reconnect.
• Authentication: Supabase Auth supporting email/password and optional Microsoft login.
• Data Integration: Real-time Supabase subscriptions and REST endpoints for live updates.
• Modules:
o City Highlights (news, alerts, events) o Events Calendar with RSVP and Add-to-Calendar o Parks & Recreation (with AR/VR experiences) o City Services (directory + quick links) o AI Chat Assistant (“Ask Daytona”) o Dynamic Pages under More tab (fetched from Supabase tables) o Push Notifications (Expo SDK integrated)
Device Compatibility:
• iOS: 14.0 and later (optimized for SE → iPhone 15 Pro Max)
• Android: API 24+ (Nougat and above)
3.2 Web Administration Portal (Next.js or Nuxt + Vercel)
A responsive, secure content management portal for internal staff.
• Hosting: Vercel under the City’s organizational account.
• Authentication: Supabase Auth with role-based permissions (Admin, Editor, Viewer).
• Primary Functions:
o Manage city highlights, events, and dynamic pages.
o Upload photos, documents, and video content to Supabase Storage.
o Compose and schedule push, SMS, and email notifications.
o Configure external WebView links for the mobile app.
o Manage subscriptions, AI knowledge base, and site settings.
• UI Framework: TailwindCSS + City Design Tokens from Figma.
• CI/CD: Auto-deployment on commit to main via GitHub Actions + Vercel integration.
3.3 Supabase Backend (Postgres + Edge Functions)
Supabase acts as the unified data backbone.
• Database: PostgreSQL with Row-Level Security (RLS).
• Auth: Email/password, OAuth (optional), JWT-based sessions.
• Storage: Buckets for images, videos, and documents.
• Realtime: WebSocket updates for live event feeds and chat.
• Edge Functions:
o Notification dispatch (Resend, Twilio, Expo) o AI query pre-processing o SharePoint → Supabase sync o Email confirmations and subscription updates o Analytics aggregation for the admin dashboard
• Performance: PostgREST API auto-generated endpoints with caching enabled.
3.4 AI Assistant (“Ask Daytona”)
• Engine: OpenAI GPT-4 (or current stable model).
• Scope: Limited to City of Daytona Beach content only (no open internet access).
• Knowledge Base:
o Data from DaytonaBeach.gov (scraped via controlled crawler).
o City-managed Supabase tables (pages, news, staff directory).
• Functionality:
o Conversational interface with voice input/output.
o Citations to data sources for every response.
o Offline fallback with pre-stored FAQs.
• Privacy: No PII stored in chat history; optional local-only storage per user session.
3.5 Notifications & Communications System
• Email: Resend (transactional + subscription alerts).
• SMS: Twilio (A2P 10DLC registered).
• Push: Expo Notifications.
• Preference Management:
o Users toggle per-channel preferences in the app.
o Stored in Supabase subscriptions and profiles tables.
o Edge Functions handle email verification, STOP/START/HELP compliance, and rate limits.
• Message Templates: Stored in Supabase with variables {first_name}, {event_time}, {cta_link}.
3.6 Third-Party Integrations (WebView Modules)
The mobile app integrates with existing city and partner systems via in-app WebViews.
Each link opens inside the app with navigation controls, offline fallback, and share options.
Examples:
• SeeClickFix (Report Concerns)
• CivicWeb (Agendas & Minutes)
• Utility Services Portal (Billing)
• Recreation Catalog (Rec1)
• Public Records (JustFOIA)
• Land Management System (IMS16)
• and others listed in Appendix D.
All WebViews inherit the city’s theme colors and include navigation and error handling overlays.
4. Data Model & Backend Architecture
Supabase serves as the single source of truth for data flowing between SharePoint, the Admin Portal, and the Mobile App.
All tables enforce Row-Level Security (RLS) and maintain automatic timestamps.
Each service (Resend, Twilio, Expo, OpenAI, ArcGIS) interacts through Edge Functions or authenticated REST calls.
4.1 Core Schema
Table Purpose Key Fields profiles user identity and contact prefs id uuid pk, email, phone_e164, role, email_verified_at, sms_verified_at posts city highlights / blog entries id uuid, title, excerpt, body_html, category, published_at, author_id events calendar data synced from SharePoint id uuid, title, start_time, end_time, location, category, image_url, rsvp_url pages dynamic pages for “More” tab id, slug, title, status, schedule_at, updated_at content_blocks page elements (text, image, video, form) id, page_id, type, content_json, order_index staff staff directory id, name, title, department_id, email, phone, photo_url departments staff hierarchy id, name, color_hex subscriptions user preferences per list profile_id, list_id, email_enabled, sms_enabled, push_enabled subscription_lists definitions of topics id, key, description, default_email, default_sms, priority notification_events messages queued for dispatch id, list_id, title, body_markdown, scheduled_at notification_dispatches per-user delivery log event_id, profile_id, channel, status, sent_at gis_locations coordinates for parks, buildings id, name, lat, lng, category, amenities
Table Purpose Key Fields kb_documents scraped city content for
AI
id, url, title, text_content, last_crawled kb_chunks vectorized embeddings for search id, document_id, embedding vector(1536), content, metadata
4.2 Storage Buckets
public/images → Event & staff photos public/videos → DBTV archives & VR assets public/documents → PDFs and uploaded forms private/user-uploads → Citizen submissions (RLS restricted)
Each file carries a signed URL with expiry tokens managed through Edge Functions.
4.3 Edge Functions
/notify/dispatch Handles queued notifications across email (Resend), SMS (Twilio), and push (Expo).
Includes retry logic and idempotency keys.
/sync/sharepoint Fetches Lists from Microsoft Graph API → normalizes → writes to Supabase tables.
/ai/search Retrieves embeddings from kb_chunks, performs vector similarity + text filter, returns structured context to OpenAI API.
/forms/submit Validates and routes incoming forms; uploads attachments to Supabase Storage and sends email confirmation via Resend.
/analytics/report Aggregates daily events (page views, downloads, notifications sent) for Admin dashboard visualizations.
4.4 Data Flow
1. City Staff Input → SharePoint Lists
2. Automated Sync → Supabase via Graph API
3. Realtime Replication → Mobile App and Admin Portal
4. Edge Functions → Notifications, Search, Forms
5. Cached Offline in SQLite/AsyncStorage
6. User Interaction → Data Updates → Supabase via Auth Session
4.5 Offline and Sync Strategy
• Expo SQLite: Structured caching (events, posts, staff).
• AsyncStorage: Simple key-value (user prefs, theme, session).
• SecureStore: Sensitive tokens (auth, push ID).
• Background Sync: Triggered when network returns; reconciles via timestamp diff.
• Conflict Resolution: “Last write wins” for non-critical data; manual merge for forms.
• Visual Indicator: Offline badge and manual refresh option in UI.
4.6 Performance Targets
• App launch: ≤ 3 s on mid-range device
• API response: ≤ 2 s 95th percentile
• Realtime latency: ≤ 500 ms for event pushes
• Offline cache sync: ≤ 10 s post-reconnect
• Battery impact: ≤ 3 % per hour average use
4.7 Security Implementation
• Row-Level Security on every table with JWT claims.
• Edge Functions authenticated via service role keys.
• All external API calls use server-side proxies to hide credentials.
• Supabase storage signing with 10-minute expiry URLs.
• Logs redact email, phone, address before storage.
5. AI Assistant Architecture (“Ask Daytona”)
5.1 Objective
Deliver an AI assistant that answers resident questions about city services, staff, events, and facilities with contextual accuracy. The system must only use City-authorized data (no external open web queries) and be auditable for accuracy and bias.
5.2 Knowledge Base Composition
Data Sources:
1. City of Daytona Beach official website (daytonabeach.gov)
2. Supabase tables:
o posts (news, highlights) o events (calendar data) o pages (dynamic content) o staff (directory) o gis_locations (facilities and parks)
3. Static municipal datasets (FAQs, emergency procedures)
4. Admin-curated documents (policy PDFs, press releases)
Ingestion Process:
• Nightly crawler runs Edge Function /ai/crawl.
• HTML and SharePoint content are sanitized and converted to plain text.
• Metadata (source URL, title, category) stored in kb_documents.
• Each document segmented into ≤1000 token chunks stored in kb_chunks.
• Chunks vectorized using text-embedding-3-large and indexed in Supabase pgvector.
• Language field (en, es, fr) included for multilingual support.
5.3 Query Flow
1. User input: Text or voice → transcribed locally (Expo Speech API).
2. Edge Function /ai/search:
o Embeds query vector.
o Performs hybrid search: cosine similarity on vectors + full-text match on tsvector.
o Returns top 10 matches with metadata.
3. Context construction:
o Combines chunks into 2,000-token prompt context.
o Appends system guardrails (“respond only with City of Daytona Beach data”).
4. OpenAI call:
o Model: gpt-4-turbo or higher.
o Temperature: 0.3 (low randomness).
o Max tokens: 800 output.
5. Response:
o Returns structured JSON with answer, citations, confidence_score, and sources.
o Displayed in conversational UI with message bubbles and optional text-to-speech playback.
5.4 Offline Behavior
• Pre-loads a mini knowledge set (faqs.json) covering basic topics: hours, utility contacts, event calendar summary.
• Returns canned responses when offline, labeled “Offline Mode.”
5.5 Privacy & Security Controls
Concern Mitigation
Data leakage No external corpus; URLs whitelisted.
Logging Inputs and outputs truncated and anonymized.
PII Names/emails stripped before embedding.
Retention Vector data retained; raw text pruned every 30 days.
Review Admin portal audit tool shows source and response pairs.
Compliance: All AI functionality conforms to City privacy policy and federal Section 508 accessibility requirements.
5.6 Admin Portal – AI Management
In the Admin web app:
• Dashboard shows last crawl date and document count.
• Controls to pause ingestion or re-index data.
• Diff viewer shows text changes since last crawl.
• Button to exclude pages from AI training.
• Regeneration of embeddings triggered on demand.
5.7 Performance Metrics
• Query latency ≤ 3 seconds end-to-end.
• Accuracy target ≥ 85% answer precision on internal QA set.
• 99% uptime for Edge Function /ai/search.
• Crawl process under 15 minutes nightly for ≤10k pages.
5.8 Future Enhancements (Optional)
• Voice Assistant mode (device microphone + text-to-speech).
• Contextual handoff to City staff (link to form or chat agent).
• Topic trend dashboard from anonymized logs.
6. Notifications & Communication System Architecture
6.1 Objective
Provide a unified system that delivers email, SMS, and push notifications to residents, staff, and subscribers.
Each channel must be preference-aware, traceable, and compliant with both TCPA (for SMS) and CAN-SPAM (for email).
6.2 Channels & Providers
Channel Provider Purpose
Email Resend Transactional + subscription communications
SMS Twilio A2P 10DLC Critical alerts + reminders
Push Expo Notifications App-based alerts + event updates
All messages originate from Edge Function /notify/dispatch, which selects the proper provider per user preference.
6.3 Supabase Schema for Notifications
Table Description subscription_lists Definitions of topics (e.g., Emergency Alerts, City News).
subscriptions User preferences per topic and channel.
notification_events Outbound messages (queued or scheduled).
notification_dispatches Per-user log of actual delivery attempts.
Each dispatch record includes status, attempts, and error fields for retry tracking.
6.4 Notification Flow
1. Trigger Event – Manual (admin compose) or automated (system event).
2. Audience Selection – Query subscriptions where channel enabled = true.
3. Queue Creation – Insert rows into notification_dispatches.
4. Delivery Handler /notify/dispatch executes:
o sendEmail() via Resend API.
o sendSMS() via Twilio Messaging Service SID.
o sendPush() via Expo token endpoint.
5. Retry Logic – 3 attempts with exponential backoff (1 min → 5 min → 15 min).
6. Status Update – Mark sent, failed, or skipped.
7. Metrics Aggregation – Edge Function writes daily counts for analytics.
6.5 Preference Management
Residents manage notifications in the mobile app under Settings → Notifications.
Action Result
Toggle a topic off Sets email_enabled/sms_enabled/push_enabled = false in subscriptions.
Unsubscribe from email link
Redirects to hosted preference page (updates Supabase).
Text “STOP” to SMS Twilio webhook updates record → sms_enabled = false.
App reinstall Expo token re-registered and re-linked to profile_id.
6.6 Compliance & Governance
• Email Deliverability: City domain authenticated via SPF/DKIM/DMARC.
• SMS A2P 10DLC: Brand and campaign registered; STOP/START/HELP keywords enabled.
• Privacy: No PII in message bodies; links use short first-party domain.
• Audit Log: All dispatch attempts recorded for 90 days.
• Quiet Hours: Non-critical topics muted 10 p.m.–7 a.m. local time.
6.7 Edge Function Pseudocode (plain text)
for recipient in audience:
key = f"{event_id}:{recipient_id}:{channel}" if alreadySent(key): continue try:
payload = renderTemplate(event, recipient) provider.send(payload) markSent(key) except Exception as e:
logFailure(key, str(e))
6.8 Message Templates
Templates are editable from the Admin Portal.
Each supports placeholders for merge fields (e.g., {first_name}, {event_time}, {cta_link}) and are versioned for rollback.
6.9 Analytics & Reporting
• Open and click tracking for Resend emails.
• Delivery success rate metrics by channel.
• Admin dashboard shows weekly volume and error trend.
• Alerts triggered if success rate < 95 % or latency > 5 minutes.
7. GIS, Mapping & AR/VR Subsystem Design
7.1 Objective
Integrate a geospatial experience across parks, facilities, and landmarks, and enrich it with immersive AR/VR functionality.
This allows residents and visitors to explore Daytona Beach interactively—via map markers, virtual tours, and augmented navigation.
7.2 Mapping Stack
Framework: react-native-maps (Google Maps SDK on Android, MapKit on iOS).
Provider: ArcGIS REST API + Calcite Design System for data and overlays.
Core Functions:
• Current location tracking and marker clustering.
• Custom icons for categories (parks, libraries, facilities, events).
• Detail popups with description, hours, and links to appointment booking.
• Directions via device-native navigation intents.
• Offline tile cache for City limits region (reduces dependency on live map tiles).
Data Source:
Table gis_locations in Supabase containing:
Field Type Description id uuid unique location ID name text facility name lat/lng numeric coordinates category enum('park','building','event','parking') classification description text summary image_url text thumbnail image amenities jsonb attributes (e.g., wifi, restrooms)
7.3 AR Experience (Augmented Reality)
Framework: ViroReact (Expo-compatible wrapper).
Device Modes:
• Marker-based: Recognizes QR or AR markers placed at buildings or park signs.
• GPS-based: Anchors objects using geolocation when markers unavailable.
Features:
• On-screen 3D overlays for building labels, directions, or park info.
• Accessibility overlays for routes (e.g., wheelchair-friendly paths).
• Pop-up info cards showing metadata from gis_locations.
• AR camera fallback: gracefully disables on unsupported devices.
Content Management:
• AR scene definitions stored in ar_scenes table:
Field Type Description id uuid scene ID location_id uuid FK to gis_locations assets_url text 3D/360 assets (stored in Supabase Storage) triggers jsonb AR markers or GPS triggers last_updated timestamp sync marker
Performance Considerations:
• Progressive asset loading; 360° media streamed or cached locally.
• Asset resolution capped at 2048×1024 to minimize memory use.
• LRU caching for AR scenes on device (max 300 MB).
7.4 Virtual Tours (VR)
Implementation: 360° photos + info overlays using expo-av video player.
Use Cases:
• Park trails with hotspots for distance and elevation data.
• City Hall, libraries, and community centers with interactive labels.
• Historical building tours with embedded captions.
Table: vr_tours
Field Description id unique tour ID name tour title category type (park/building/history)
Field Description assets list of 360° images/videos metadata descriptions, captions, tags is_downloadable boolean for offline mode
7.5 Offline Capability
• Caches selected map tiles, facility data, and VR assets.
• Background service checks connectivity before downloading heavy files.
• Users can manually “preload park tour” in settings.
7.6 GIS Integration Flow
ArcGIS Feature Service → Supabase (gis_locations) → Mobile Map Component → AR/VR Modules → User Interaction/Navigation
Edge Function /gis/sync:
• Polls ArcGIS API nightly for changes.
• Upserts into gis_locations with updated coordinates and metadata.
• Notifies admin dashboard of sync status.
7.7 Accessibility
• Map icons meet 3:1 contrast ratio.
• Voice-over for AR elements (“You are near City Hall, tap to view details”).
• Screen-reader hints for AR markers and VR hotspots.
• Supports both touch and voice navigation.
7.8 Future Extensions
• Heatmap for parking availability.
• 3D building extrusions (Esri SceneLayer integration).
• Dynamic AR scavenger hunts linked to Agents of Discovery missions.
• Offline route guidance using cached GPX data.
8. Dynamic Pages System (Supabase-Backed CMS)
8.1 Objective
Enable non-technical staff to publish, schedule, and iterate content without redeploying the app. All new pages live under the More tab and are assembled from reusable content blocks. Pages render identically across iOS and Android and honor City branding/accessibility requirements.
8.2 Information Architecture
• Fixed tabs remain code-defined: Home, Events, Parks, Services, More.
• Dynamic surface: The More tab reads page menus and external links from Supabase in real time.
• Routing: Each page is addressed by a slug and displayed via a single DynamicPageScreen that renders ordered blocks.
8.3 Supabase Schema (Core CMS Tables)
pages
• id uuid pk
• slug text unique not null (e.g., beach-safety, after-storm-guidance)
• title text not null
• description text (short summary, used in search)
• icon text (optional, name from icon set)
• category text (e.g., “Public Safety,” “Parks & Rec”)
• status enum('draft','review','scheduled','published','archived') default 'draft'
• scheduled_publish_at timestamptz
• author_id uuid (FK → profiles.id)
• reviewer_id uuid (FK → profiles.id)
• created_at/updated_at timestamptz content_blocks
• id uuid pk
• page_id uuid (FK → pages.id on delete cascade)
• type enum('text','image','video','gallery','link','list','faq','event','staff','form','map','html') not null
• content jsonb not null (schema depends on type)
• "order" int not null
• created_at/updated_at timestamptz page_categories (optional taxonomy)
• key text pk (e.g., public-safety)
• label text
• "order" int external_links
• id uuid pk
• label text not null
• url text not null
• provider enum('seeclickfix','justfoia','rec1','utility','civicweb','other') default 'other'
• icon text
• category text
• require_webview boolean default true
• sort int default 0
• is_featured boolean default false
• created_at/updated_at timestamptz page_versions (version history)
• id uuid pk
• page_id uuid
• version int
• delta jsonb (diff payload)
• created_at timestamptz
• created_by uuid
RLS
• anon can select only pages.status in ('published') and their related content_blocks.
• authenticated authors can CRUD drafts and submit for review.
• admin/reviewer roles can approve, schedule, publish, and archive.
• All writes logged via Postgres triggers to an audit_log table.
8.4 Block Payload Templates (plain text examples)
Text Block
"style": "body|lead|caption", "markdown": "Hurricane season runs June–November. Sign up for alerts...", "alignment": "left|center|right"
Image Block
Gallery Block
Link Block
"src": "https://supabase.storage/public/images/beach-flag.png", "alt": "Beach warning flags", "caption": "Beach safety flags"
"items": [ {"src":".../img1.jpg","alt":"Boardwalk"}, {"src":".../img2.jpg","alt":"Pier at sunset"}
"label": "Pay Utility Bill", "url": "https://cc.codb.us/payutilitybill", "require_webview": true
List Block
FAQ Block
Event Block
"variant": "bulleted|numbered|check", "items": ["Bring ID", "Arrive 10 minutes early", "Check parking"]
"items": [ {"q":"How do I request public records?","a":"Use JustFOIA at ..."}, {"q":"Where can I report a pothole?","a":"SeeClickFix link ..."}
"event_id": "uuid", "show_map": true, "cta": {"label": "Add to Calendar", "deep_link": "app://events/123"}
Staff Block
Form Block
Map Block
"staff_id": "uuid", "show_contact": true
"fields": [ {"type":"text","name":"full_name","label":"Full Name","required":true}, {"type":"email","name":"email","label":"Email","required":true}, {"type":"select","name":"topic","label":"Department","options":["Parks","Utilities","FOIA"]}, {"type":"file","name":"attachment","label":"Attachment (optional)"} "submit": {"label":"Send","endpoint":"/forms/submit","success_message":"Thanks! We received your message."}
"center": {"lat":29.2108,"lng":-81.0228}, "zoom": 13, "markers": [{"lat":29.22,"lng":-81.01,"label":"City Hall"}]
HTML Block (sanitized server-side)
8.5 Admin Workflow (Web Portal)
1. Create Draft: Author creates pages record; adds content_blocks via block editor.
2. Preview: Live preview pulls the draft as the app would render it.
3. Review: Status → review. Reviewer comments inline and approves or requests changes.
4. Schedule or Publish:
o Immediate publish sets status to published.
o Scheduled publish sets scheduled_publish_at.
5. Versioning: Publishing writes a snapshot into page_versions with diff against prior version.
6. Archive: Retire outdated content while retaining history.
8.6 Mobile Rendering Pipeline
• Menu assembly:
o SELECT * FROM pages WHERE status='published' ORDER BY category, title;
o SELECT * FROM external_links ORDER BY is_featured DESC, sort ASC;
• Page view:
o Fetch content_blocks for selected page_id, sorted by "order".
o Switch-render components by type.
• Brand compliance: Typography, spacing, and colors applied at component level to prevent off-brand content.
{"html": "<div><strong>Parade Route:</strong> ...</div>"}
• WebView: For link blocks or external_links flagged require_webview=true, open in-app WebView with progress, error, share, and back affordance.
8.7 Offline Strategy
• Cache up to 100 recently viewed pages and associated block assets.
• Stale-while-revalidate: display cached content instantly while refreshing in background.
• “Offline” banner and retry affordance when network unavailable.
• Preload “Critical Info” pages (e.g., emergency procedures) flagged via pages.category='Public Safety'.
8.8 Search & Discovery
• Hybrid search across pages.title, description, and a generated tsvector from text blocks.
• The AI assistant also consumes page content via kb_documents and kb_chunks to provide grounded answers with links back to slug routes.
8.9 Localization (Optional)
• Add locale column to pages and content_blocks, or maintain sibling pages per language with shared group_id.
• Admin portal filters by language; mobile auto-selects based on device locale with manual override.
8.10 Validation & Sanitization
• Server-side Zod validation for block content shapes per type.
• HTML blocks sanitized using a server-side allowlist before persisting.
• File uploads scanned and restricted to approved MIME types.
• Maximum per-page payload guard (e.g., 1.5 MB of media references) to protect low-end devices.
8.11 Observability & Audit
• audit_log table records who changed what and when (page status, block adds/removes).
• Metrics: page impressions, time-on-page, link taps, WebView errors.
• Admin dashboard: top pages, broken link detector, and “orphaned page” reports.
8.12 Acceptance Criteria
• Creating, reviewing, scheduling, and publishing pages requires no app redeploy.
• Dynamic pages render block types: text, image, video, gallery, list, link, faq, event, staff, form, map, html.
• Published content appears in-app within 60 seconds (realtime or polling).
• Offline revisit works for last viewed pages; emergency pages preloaded.
• All HTML sanitized; pages meet WCAG 2.1 AA; tap targets ≥44 px; contrast ≥4.5:1.
• Version history accessible; rollback restores a prior snapshot in ≤2 clicks.
8.13 API Contracts (plain text)
GET /pages?status=published&category={key}&q={search}&limit={n}&offset={m} Returns page list with metadata.
GET /pages/{slug} Returns page metadata + ordered content_blocks.
POST /pages (auth: editor+) Create draft; returns new id and slug.
PATCH /pages/{id} (auth: editor+/reviewer+) Update metadata or status; schedule publish.
POST /pages/{id}/blocks (auth: editor+) Upsert content blocks with "order" and type.
POST /pages/{id}/publish (auth: reviewer+) Publishes immediately; records version snapshot.
9. Integration Architecture and Data Flow
9.1 Objective
Unify the City’s existing public-facing systems under one mobile experience without rebuilding those systems.
Integrations use Supabase Edge Functions and in-app WebViews, providing secure hand-off and consistent branding.
9.2 Integration Model
Integration Type Mechanism Notes
Real-time / API Edge Function → JSON feed → Supabase table
Events, news, GIS data
Interactive Web In-app WebView with secure navigation Utility billing, records, FOIA
Data Sync Nightly pull via Microsoft Graph API SharePoint Lists
Notification Trigger
Edge Function or webhook Event reminders, alerts
All integrations are read-only unless explicitly approved for form submission (e.g., JustFOIA, SeeClickFix).
9.3 Key Third-Party Systems
Service Description Access Type
Integration Endpoint
SeeClickFi x
Citizen issue reporting
WebView + deep link https://seeclickfix.com/web_portal/...
CivicWeb City meeting agendas/minu tes
WebView https://codb.civicweb.net/portal/
Utility Portal
Billing & payments
WebView (secure session) https://cc.codb.us/
Recreation Catalog (Rec1)
Event & facility registration
WebView
+ SSO
option https://secure.rec1.com/FL/daytona-beach-leisure-services/catalog
JustFOIA Public records requests
WebView + form submissi on https://daytonabeachfl.justfoia.com/publicportal/h ome/track
Land Manageme nt (IMS16)
Permitting and zoning
WebView (login required) https://daytonabeach.ims16.com/ims/Account/Log in
Agents of Discovery
AR scavenger hunt API
REST https://agentsofdiscovery.com/mission-data-api
ArcGIS Geospatial data services
REST +
tiles https://codb.maps.arcgis.com/
Microsoft Graph API
SharePoint and Outlook integration
REST +
OAuth2 https://graph.microsoft.com/v1.0/sites/{siteId}/lists /{listId} https://seeclickfix.com/web_portal/ https://codb.civicweb.net/portal/ https://cc.codb.us/ https://secure.rec1.com/FL/daytona-beach-leisure-services/catalog https://secure.rec1.com/FL/daytona-beach-leisure-services/catalog https://daytonabeachfl.justfoia.com/publicportal/home/track https://daytonabeachfl.justfoia.com/publicportal/home/track https://daytonabeach.ims16.com/ims/Account/Login https://daytonabeach.ims16.com/ims/Account/Login https://agentsofdiscovery.com/mission-data-api https://codb.maps.arcgis.com/
Service Description Access Type
Integration Endpoint
Resend Email delivery REST https://api.resend.com
Twilio
SMS / A2P
10DLC
REST https://api.twilio.com
OpenAI AI query completion
REST https://api.openai.com/v1/chat/completions
9.4 WebView Behavior
• Opens in-app modal with navigation toolbar (Back, Forward, Share).
• Shows loading progress indicator (City Blue).
• Displays custom “Offline” message if unreachable.
• Option to open in device browser.
• SSL validation enforced; no mixed-content allowed.
• Session cookies isolated to each service (no cross-site persistence).
Example configuration:
<WebView source={{ uri: 'https://cc.codb.us/' }} startInLoadingState={true} onError={handleWebError} injectedJavaScript={themeInjector} https://api.openai.com/v1/chat/completions
9.5 Theme Injection
Every WebView injects the City’s brand colors and disables pinch-zoom for UI consistency:
9.6 Data Sync: SharePoint → Supabase
Process:
1. Edge Function /sync/sharepoint runs nightly via cron.
2. Queries Microsoft Graph API for each configured List (Events, News, Parks).
3. Maps fields to Supabase schema; upserts using insert ... on conflict.
4. Flags outdated items as archived.
5. Writes sync logs to integration_log table.
integration_log table
Field Description id uuid source e.g., 'SharePoint' items_processed integer items_updated integer duration_ms integer success boolean const themeInjector = ` document.body.style.setProperty('--primary','#154777');
document.body.style.setProperty('--accent','#6FC5D8');
document.body.style.setProperty('--font-family','Century Gothic');
document.querySelectorAll('a').forEach(a=>a.style.color='#6FC5D8');
Field Description message text created_at timestamptz
9.7 Data Flow Diagram (plain text)
[SharePoint Lists]
↓ (Graph API)
[Supabase tables: events, posts, pages]
↓ (Realtime / REST)
[Mobile App & Admin Portal]
↔ (User actions)
[Edge Functions → External APIs (Resend, Twilio, Expo, ArcGIS)]
9.8 Security & Access Control
• OAuth tokens for Microsoft Graph and other APIs stored in Supabase Vault/Secrets.
• Refresh handled by background job; never exposed to clients.
• All outbound requests use city-owned service credentials.
• WebViews restricted to https://*.codb.us, *.daytonabeachfl.justfoia.com, and whitelisted domains.
• Content-Security-Policy enforced via injected headers.
9.9 Error Handling
• Retry policy: 3 exponential retries for API calls; exponential backoff (1 s → 10 s → 30 s).
• Logs written to integration_log and forwarded to Sentry.
• User-facing fallback messages (“Service temporarily unavailable”).
• Admin alert if failure > 3 consecutive runs.
9.10 Performance Targets
• API response < 2 s average.
• WebView load < 4 s over LTE.
• Sync job completion < 10 min for ≤10 k records.
• Zero unauthenticated write access from client apps.
9.11 Acceptance Criteria
• All integrations functional and theme-consistent inside the app.
• APIs reach ≥ 99 % availability.
• Sync operations succeed without manual intervention.
• Admin logs show < 1 % error rate.
• All third-party endpoints documented in Appendix D.
10. Continuous Integration / Continuous Deployment (CI/CD)
10.1 Objective
Ensure that every code change, configuration update, and content migration moves from development → preview → production through a repeatable, automated process.
All automation runs in City-owned GitHub Actions pipelines and deploys to Expo EAS and Vercel.
10.2 Environments
Environment Purpose Branch Build Type Distribution
Development local + internal testing dev/* debug Expo Go & Vercel preview
Environment Purpose Branch Build Type Distribution
Preview stakeholder review main (pre-release) release-candidate
EAS preview channel / Vercel preview URL
Production public deployment tagged release (vX.Y.Z) signed production
App Store / Play Store / live Vercel domain
10.3 GitHub Actions Workflow
Trigger Events
• push to main or dev/*
• pull_request opened / merged
• manual dispatch for hotfix builds
Pipeline Stages (yaml)
Artifacts
• EAS build URLs for iOS/Android
• Vercel deployment preview link
• Test reports (Jest coverage ≥ 70 %) jobs:
lint_test:
run: npm run lint && npm run test build_mobile:
run: eas build --profile ${PROFILE} deploy_web:
run: vercel --prod --token ${VERCEL_TOKEN} migrate_db:
run: supabase db push
• Supabase migration log
10.4 Expo EAS Configuration
eas.json
Profiles
• Development: debug APK/IPA for internal QA
• Preview: pre-release builds with OTA enabled
• Production: signed AAB / IPA with manual store submission
OTA Updates
• Non-breaking JS/asset changes via expo publish.
• Each channel mapped to matching build profile.
10.5 Vercel Deployment Pipeline
• GitHub → Vercel integration (auto-deploy on merge).
• Branch preview URLs: branch-name.citydaytona.vercel.app.
• Environment Variables: stored per environment (Dev/Preview/Prod).
• Automated previews for pull requests; approved PR → production promote.
"build": { "development": { "distribution": "internal", "channel": "dev" }, "preview": { "distribution": "internal", "channel": "preview" }, "production": { "distribution": "store", "channel": "stable" }
• Rollback via Vercel dashboard (one-click revert).
10.6 Supabase Deployment
• Schema migrations checked into supabase/migrations/.
• Apply migrations automatically in CI via supabase db push.
• Seed data for development in supabase/seed.sql.
• Edge Functions deployed via supabase functions deploy *.
• RLS Policies tested in CI to prevent accidental privilege escalation.
10.7 Environment Variables & Secrets
Validated via Zod schema at runtime; missing key fails build. (nginx)
Secrets Storage
• GitHub Secrets for CI.
• Vercel Env Manager for web.
• Expo EAS Secrets for mobile.
RESEND_API_KEY
TWILIO_ACCOUNT_SID
TWILIO_AUTH_TOKEN
TWILIO_MESSAGING_SERVICE_SID
OPENAI_API_KEY
SUPABASE_URL
SUPABASE_ANON_KEY
SUPABASE_SERVICE_ROLE_KEY
ARCGIS_API_KEY
AGENTS_OF_DISCOVERY_API_KEY
VERCEL_TOKEN
• Supabase Vault for runtime tokens.
10.8 Versioning & Tagging
• Semantic versioning vMAJOR.MINOR.PATCH.
• Automatic tagging on main merge after tests pass.
• Each build injects version metadata (appVersion, buildDate, commitHash) into About screen and API headers.
10.9 Rollbacks & Recovery
• Web: Vercel instant revert (1-click).
• Mobile: Publish prior OTA bundle channel revert.
• Database: pg_dump nightly snapshot + point-in-time restore (24 h window).
• AI Embeddings: retain last two vector sets for fallback search.
10.10 Security & Access
• Branch protection rules: PR review + checks required before merge.
• CI runners ephemeral (no persistent secrets).
• Build signing keys stored in City Keychain only.
• Post-deploy smoke tests verify API and push notifications before marking “green.”
10.11 Monitoring & Alerting
• Sentry: captures errors for mobile, web, and Edge Functions.
• UptimeRobot / Vercel Insights: availability monitoring.
• Supabase Logs: query latency + error rate tracking.
• Slack/email alerts to City IT on pipeline failure or uptime drop.
10.12 Acceptance Criteria
• Commit → build → deploy pipeline runs < 10 min.
• 100 % of source under CI coverage.
• Rollback tested and documented.
• All credentials in City-owned secrets managers.
• Each build automatically logged and auditable for 30 days.
11. Testing & Quality Assurance Framework
11.1 Objective
Guarantee that every component—from Edge Functions to mobile UI—meets reliability, accessibility, and performance targets before deployment. Testing runs automatically in CI/CD and manually during User Acceptance Testing (UAT).
11.2 Testing Layers
Layer Tools / Frameworks Focus
Unit Tests Jest, React Testing Library Component logic, utility functions
Integration Tests Cypress (web), Detox (mobile) API interaction, auth flow, navigation
End-to-End Tests Playwright + Expo E2E Full user journeys and offline behaviors
Performance Tests
Lighthouse (web), Expo Profiler Launch times, FPS, memory usage
Accessibility Tests axe-core, react-native-accessibility-engine
WCAG 2.1 AA compliance
Security Tests npm audit, OWASP ZAP scans Dependency & API vulnerability detection
Layer Tools / Frameworks Focus
Load Tests k6 (Edge Functions & Supabase) Simulated concurrent users
11.3 Unit Testing Standards
• Coverage Target: ≥70% for utilities and API functions.
• Test Cases: Each function tested for both success and failure paths.
• Snapshots: UI components snapshot-tested per theme (light/dark).
• Mocking: External APIs (Supabase, Twilio, OpenAI) stubbed via MSW (Mock Service Worker).
• Naming Convention: *.test.ts(x) colocated with source.
Example Unit Test (plain text)
11.4 Integration Testing
• Validate Supabase Auth, data queries, and offline caching.
• Mock Supabase API with replayed JSON fixtures.
• Test “More” tab rendering for all block types (text, image, form, map, etc.).
• Confirm external links open in WebView and return safely to app.
• Validate notification subscriptions update correctly in backend.
11.5 End-to-End (E2E) Testing
describe('formatEventDate', () => { it('returns localized string', () => { expect(formatEventDate('2025-07-04T19:00Z')).toContain('July 4, 2025');
Scope
• Full user login → browse → subscribe → receive notification → log out.
• Offline/online transitions.
• Multilingual toggles.
• Accessibility navigation (screen reader, large text).
Tools
• Detox: Mobile test runner integrated with Expo builds.
• Playwright: For web admin (Next.js portal).
• CI triggers nightly regression suite.
Example (plain text)
11.6 Accessibility (A11y) Testing
Compliance with WCAG 2.1 AA is mandatory.
Checklist:
Category Requirement
Color contrast ≥ 4.5:1 for text, ≥ 3:1 for large text
Tap targets ≥ 44 × 44 px
Keyboard navigation Supported in web admin scenario('User subscribes to event alerts', async () => { await login('test@user.com', 'password');
await tap('Settings');
await toggle('Emergency Alerts');
await expect(Toast('Preferences updated')).toBeVisible();
Category Requirement
Voice control Compatible with iOS VoiceOver & Android TalkBack
Dynamic text System font scaling respected
Alt text All images & AR markers include alt/description fields
Motion sensitivity Reduced motion toggle disables animations
Accessibility audits run per release using axe-core and React Native Accessibility Engine.
11.7 Performance Testing
Targets
• App launch ≤ 3 s.
• Screen transitions ≤ 500 ms.
• API round-trip ≤ 2 s p95.
• Battery drain ≤ 3 % per hour continuous use.
• Crash-free sessions ≥ 99 %.
Method
• Automated via Expo Profiler (CPU/memory/FPS).
• Web via Lighthouse (performance score ≥ 90).
• Load testing of Edge Functions with k6 simulating 1,000 concurrent users.
11.8 Security & Penetration Testing
• Dependency scanning: npm audit --production on every CI run.
• API fuzzing: k6 scripts simulate malformed payloads.
• Static Analysis: ESLint + TypeScript strict mode + dependency review.
• Penetration test: Annual audit using OWASP Top 10 methodology.
• Vulnerability Disclosure Program: optional extension for public bug reports.
11.9 User Acceptance Testing (UAT)
Conducted by City IT and Communications staff with real data.
Test cases mirror resident workflows and accessibility needs.
Process
1. Build deployed to EAS “preview” channel.
2. UAT script executed and documented.
3. Issues tracked in GitHub Projects board.
4. Fixes merged and re-verified before production release.
Acceptance Gate
• All critical and high-severity defects resolved.
• Accessibility and performance thresholds met.
• Stakeholder sign-off recorded in meeting minutes.
11.10 Regression Testing
• Run nightly using CI on main branch.
• Auto-generated test matrix covers major devices (iPhone SE, iPad, Pixel 7).
• Failure triggers Slack/email alert to development lead.
11.11 Test Data & Environments
• Separate Supabase instances for Dev, QA, and Prod.
• Masked datasets (no personal info).
• Synthetic users for notifications and AI testing.
• Fixtures version-controlled (/tests/fixtures/).
11.12 Acceptance Criteria
• 100% of defined test cases executed and documented.
• All blocking defects resolved before go-live.
• Crash-free session rate ≥ 99 %.
• Accessibility audit passed (axe-core score ≥ 95).
• Automated CI tests run successfully before each deployment.
12. Figma Design System, Components & Branding Enforcement
12.1 Objective
Establish a consistent, reusable, and WCAG-compliant design system for all app interfaces.
This ensures that updates, accessibility fixes, and branding changes cascade automatically across mobile and web assets.
12.2 Figma Workspace Structure
Figma Team: City of Daytona Beach – Digital Experience
Files:
1. Design System (Master Library) o Color tokens, typography, icons, elevation, grid system.
o Reused across Mobile App and Admin Portal files.
2. Mobile App (React Native Prototype) o Screen flows for Home, Events, Parks, Services, More, Chat, and Notifications.
3. Admin Portal (Next.js Prototype) o Layouts for Dashboard, Posts, Events, Pages, Notifications, and Settings.
Version Control:
Design tokens (JSON export) committed to packages/ui-tokens/ in the GitHub monorepo.
Developers sync using figma-tokens plugin or REST API.
12.3 Design Tokens
Color Palette
Token Hex Usage color-primary-red #EF3E3D Alerts, destructive buttons color-primary-orange #FAA21B Warnings, highlights color-primary-blue #6FC5D8 Links, accents color-secondary-blue #154777 Headers, nav backgrounds color-light-gray #F1F2F2 Card backgrounds, borders color-text-dark #1E1E1E Body text color-text-light #FFFFFF On dark backgrounds
Typography
Style Font Weight Use
Display Dunbar Text Extra Bold 800 Banners, titles
Heading Century Gothic 700 Section headers
Body Century Gothic 400 General text
Accent Yellowtail Regular 400 Decorative headings
Spacing
• 4 px base grid.
• 8 px rhythm for padding/margins.
• Components adhere to 8/16/24 px intervals for consistent spacing.
Elevation
• elevation-1: subtle 2 dp shadow for cards.
• elevation-2: 4 dp for modals and FABs.
Border Radius
• Buttons: 8 px
• Cards: 12 px
• Modal corners: 16 px
12.4 Component Library
Core Components (shared React Native + Web)
Component Description
Button Primary, Secondary, Destructive, Disabled variants
Card Rounded container with shadow + padding
TabBar Bottom nav with icons (24–28 px)
InputField Label, helper text, error states
Switch Toggle for subscription preferences
ListItem Avatar, title, description layout
Modal For confirmation dialogs
Toast Inline confirmation alerts
Badge Status indicators (color-coded)
FormBlock Composite component rendering forms from schema
State Variants
• Default / Hover / Active / Disabled / Loading.
Interactive Tokens
• Hover states lighten 5%.
• Pressed states darken 10%.
• Focus ring: 2 px Primary Blue outline.
12.5 Accessibility Integration
All components meet WCAG 2.1 AA and are tested for:
• Contrast ratio compliance.
• Keyboard and screen reader focus order.
• Font scaling (Dynamic Type / Android font scaling).
• ARIA role annotation in Admin Portal (e.g., role="dialog", aria-live="polite").
12.6 Mobile Screen Prototypes
Each Figma screen maps directly to a React Native route.
Screen Groups:
• Home: Carousel banners, featured news, quick actions.
• Events: Calendar, list, and event details.
• Parks: Map view, details, AR/VR entry points.
• Services: Category cards, service directory.
• More: Dynamic pages list + external links.
• AI Chat: Conversational layout with mic + playback buttons.
• Notifications: Preferences toggles per topic.
• WebView: Loader, retry, share overlay.
• System: Splash, Login, Profile, 404.
Prototype flows link across tab navigation and modals.
12.7 Admin Portal Design
Layout:
• Sidebar (Secondary Blue background).
• Top bar with user avatar + breadcrumbs.
• Content area with card grid (Light Gray).
• Font: Century Gothic.
• Primary CTAs: Secondary Blue background, white text.
Core Screens
Screen Description
Dashboard Metrics, sync logs, notifications overview
Posts CRUD table with preview
Events Calendar + list + event editor
Pages Drag-and-drop block editor
Links Manage external links and featured shortcuts
Notifications Compose + schedule system
AI Knowledge View indexed docs and reindex crawler
Settings Branding tokens, environment keys
12.8 Figma-to-Code Mapping
Figma Component React Native Component Notes
Button / Primary <Button variant="primary" /> color = Secondary Blue
Card / Default <Card /> elevation = 2dp
Input / Text <TextInput /> autoFocus optional
Figma Component React Native Component Notes
ListItem / Icon <ListItem icon={<Icon />}/> align with RN Paper style
Tab / Navigation <BottomTabNavigator /> colors via Design Tokens
Tokens sync weekly via figma-tokens CLI.
12.9 Branding Enforcement
• Any visual changes (fonts, colors, spacing) must be updated in the Figma Design System file, not directly in code.
• City Communications must approve design modifications before release.
• QA verifies pixel parity between design mockups and running builds.
• Branding diff report generated using visual regression testing (Percy/Screener).
12.10 Deliverables
• .fig source files for all design assets.
• JSON exports of tokens (tokens/color.json, tokens/typography.json).
• PNG assets for app stores (icons, splash, feature graphics).
• Accessibility audit report per release.
• Figma link to interactive prototype showing all navigation paths.
13. Security, Privacy & Compliance Framework
13.1 Objective
Ensure all data, systems, and integrations related to the Daytona Beach Civic Engagement Platform are secured by design, in line with CJIS, NIST 800-53, and OWASP Mobile Top 10 standards.
The goal is to deliver transparency, data integrity, and strong privacy for all users while maintaining system resilience and auditability.
13.2 Security Principles
1. Least Privilege:
Every user, function, and API key is granted only the permissions absolutely necessary for its role.
2. Defense in Depth:
Layered protection—encryption, firewalls, authentication, and RLS (Row Level Security) policies.
3. Zero Trust Posture:
No system or user is inherently trusted; continuous authentication and session validation are enforced.
4. Auditability:
All administrative actions and data access events are logged and immutable for 12 months minimum.
5. Fail-Safe Defaults:
Unauthenticated or invalid requests are denied by default.
13.3 Authentication & Access Control
Supabase Auth:
• Supports Email/Password, Microsoft Single Sign-On, and optional Social (Google, Apple) logins.
• Tokens: short-lived JWTs (max 1 hr) with automatic refresh via secure refresh tokens.
• Multi-Factor Authentication (MFA) optional for admin and staff accounts.
• All API routes validated via server-side JWT middleware.
Role-Based Access Model
Role Permissions
Anonymous Read-only access to public content
Authenticated User Access personal subscriptions, preferences, RSVP
Role Permissions
Content Editor CRUD on pages, posts, events
Reviewer Approve and schedule content
Administrator Manage users, notifications, integrations
System Execute Edge Functions (Resend, Twilio, AI)
Session Management
• Idle session timeout: 30 min for admin portal, 1 hr for mobile app.
• Device sessions revocable by user or admin.
• Supabase refresh_token invalidated on logout.
13.4 Encryption & Data Security
Layer Technology Notes
Transport HTTPS (TLS 1.3) All traffic encrypted end-to-end
Storage AES-256 at rest (Supabase Postgres + Storage)
Managed…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .