The file's text, extracted by GovTribe without its formatting.
VI. Exhibit 1 – CDFW Recreational Fishing Regulations Requirements Project Need California Department of Fish and Wildlife (CDFW) is responsible for providing clear and accessible information about recreational fishing regulations to the public. In recent years, CDFW transitioned several regulatory materials from paper to online resources. As part of this effort to go electronic, fishing regulations booklets became available online-only in 2021. CDFW also hosts several online regulatory tools including the Freshwater Regulations Map, Ocean Sport Fishing Map, and the Ocean Sport Regulations Web Page.
While these tools provide valuable information, they have limitations. Many require an internet connection and do not present all applicable fishing regulations in a single location. Recreational fishing regulations in California are complex, involving overlapping management areas, waterbody-specific rules, segmented inland waters, and species-specific restrictions.
To address these challenges, CDFW proposes to develop an interactive, map-based mobile application that allows users to more easily view all relevant recreational marine and inland fishing regulations for a given location. By presenting regulations within a geospatial interface and enabling offline functionality, the application will improve public understanding of these regulations and support responsible fishing activity.
User Requirement Collection Data Technologies Division’s (DTD) Marine and Fisheries Unit conducted outreach to several internal programs to identify technical and functional features to include in the application.
DTD staff consulted with representatives from Marine Region, Inland Fisheries, Recruit Retain Reactivate (R3), Law Enforcement Devising (LED) and Biogeographical Data Branch (BDB) to get their input on several technical and functional features to include in the application. These discussions helped identify features that would benefit both marine and inland anglers, and informed priorities for the application’s initial release as well as potential future enhancements.
Project Goal and Scope The primary goal of this project is to develop a free application that allows the public to easily access current recreational fishing regulations throughout California. The application will be available as a native mobile app on both Android and Apple iOS devices, and as a web-based interface accessible from desktop and laptop computers. The tool will provide a map-based interface that enables users to view applicable inland and marine regulations based on their geographic location, helping anglers better understand complex regulatory boundaries and waterbody-specific rules. To ensure accessibility in the field, the application will function both online and offline, allowing users to reference regulations even in areas without cellular connectivity.
A centralized regulations database has been developed to support this effort and is currently in active use. The database houses spatial and regulatory information needed to power the application, including geospatial management areas, waterbody-specific regulations, and species-related rules. This project includes additional enhancements to the database and supporting Content Management Interface (CMI) to support new application features. A regulation staging and promotion workflow will also be implemented to provide authorized users with a controlled, auditable mechanism to draft, review, and publish regulatory changes before they are released to the public-facing application. The project will also explore opportunities to apply artificial intelligence (AI) across both the data pipeline and the user-facing application, from streamlining how regulatory content is ingested and maintained to enabling users to ask plain-language questions and receive regulation summaries without navigating the map interface directly.
Phase 1 (Completed 2024) Phase 1 established the core infrastructure of the Fishing Regulations Data Management platform, delivering a role-controlled web-based Content Management System (CMS) backed by a structured database. The system enables authorized users to create, edit, and manage recreational fishing regulations, associated rules, and reference lookup tables. All current fishing regulation codes and regulatory language were loaded as the authoritative baseline for future editorial and publication activity.
With the foundation in place, fishing rules were configured, and prototype queries and reports were developed to validate the data model and demonstrate the platform's ability to support public-facing outputs. Subject matter experts have remained actively engaged since initial deployment, using the CMS to refine data, resolve edge cases, and confirm the system's operational fitness. The platform has also been integrated as a live data source for the Inland Sport Fishing web application, marking its first production consumer and validating the database architecture for public-facing workloads.
Requirements The following table lists the key functional/non-functional requirements. Collectively, these requirements define the functional/non-functional aspects of the proposed solution.
Requirements are prioritized as follows:
M (Mandatory) – The requirement is absolutely vital to the project. The project shall be canceled if the requirement is not included. This category is reserved for functionality that is directly required by regulation and not functionality that is simply important or highly desired.
R (Required) –The requirement is not individually essential to the project, but requirements in this category collectively affect the viability of the project. This category covers additional functionality beyond what regulation specifies. These can be features that may be optional, deferred to a later system enhancement, or that represent a category of capability the project should include but where individual items carry some flexibility.
D (Desired) – One or more requirements in this category could be omitted without affecting the overall viability of the project. These are nice-to-have features (bells and whistles, or high-cost requirements unique to a specific use case) that would add value but are not essential to a successful delivery.
| 1.00 |
| General Requirements |
| 1.01 |
| The application shall be designed to function as a native mobile application on both Android and Apple mobile devices and include a web-based interface that is accessible from desktop and laptop computers. The web-based interface shall achieve feature parity with mobile versions, excluding offline map caching. |
| M |
| 1.02 |
| The application shall be available to the public free of charge. |
| M |
| 1.03 |
| The application shall allow access to all current recreational fishing regulations (Inland and Marine). |
| M |
| 1.04 |
| The application shall remain fully functional with or without an internet connection. See Section 16.00 for data synchronization, offline caching, and staleness-notification requirements. |
| M |
| 1.05 |
| Advertisements shall not be displayed anywhere in the app. |
| M |
| 1.06 |
| The application shall identify fishing regulations based on the date and the device’s current location or based on a California location determined by the user. |
| M |
| 1.07 |
| Content displayed on the application shall be driven by the Centralized Regulations Database |
| M |
| 1.08 |
| The application shall address recreational fishing only; commercial fishing regulations are out of scope for the current release. |
| R |
| 1.09 |
| The application shall be built on a platform that enables DTD to maintain core functionality and support future enhancements within Android and iOS ecosystems. Example platforms under consideration include cross-platform frameworks such as Flutter, React Native, or .NET MAUI, as well as native development using Swift (iOS) and Kotlin (Android). |
| M |
| 1.10 |
| The application shall display applicable regulations in a simplified, user-centered format that clearly communicates key information (including bag limits, gear restrictions, open/closed status, etc.) without requiring the user to interpret source regulatory text or navigate multiple screens to reach a determination. |
| R |
| 1.11 |
| The application shall apply rule-based logic to determine applicable regulations based on location, season, species, and waterbody-specific exceptions, and return only the regulations relevant to the user's context. |
| M |
| 1.12 |
| The application shall cache mapping service data locally on the device for offline use, consistent with the basemap download options defined in Section 6.00. |
| M |
| 1.13 |
| The application shall include clear disclaimers and user guidance indicating that displayed summaries are informational and that official regulations govern in cases of discrepancy. |
| M |
| 1.14 |
| The application shall provide views to the full legal regulation language stored in the Centralized Regulations Database to ensure legal defensibility and provide access to complete regulatory context. |
| M |
| 1.15 |
| The application shall provide external hyperlinks to recreational Regulatory repositories including, but not limited to CCR Title 14, CFR Title 15, and California Fish and Game Code. |
| M |
| 1.16 |
| The application shall be separate from the existing CDFW License App |
| R |
| 1.17 |
| The data system and application shall be designed with sufficient flexibility to support the inclusion of hunting and other wildlife-related regulations in future releases. |
| R |
| 1.18 |
| The application shall include analytics capabilities to track user engagement, search behavior, and feature utilization to inform future improvements and outreach strategies. |
| D |
| 1.19 |
| The application shall request the user's consent before accessing device location and shall remain functional using a user-selected location when location access is denied or unavailable. |
| M |
| 1.20 |
| Analytics collection shall comply with applicable privacy laws and CDFW data-handling policies and shall not capture personally identifiable information without user consent. |
| M |
| 1.21 |
| The application user interface across all supported mobile devices (iOS, Android) shall comply with California Government Code Section 11135, Web Content Accessibility Guidelines (WCAG) 2.1 Level AA mobile standards, and Section 508 accessibility standards. |
| R |
| 1.22 |
| The application shall process user location telemetry ephemerally to resolve local regulations and shall not retain, log, track, or transmit historical user location telemetry or coordinates to external servers. |
| R |
| 2.00 |
| App UI - Core Interface and Navigation |
| 2.01 |
| The primary view of the application shall be an interactive map containing persistent on-screen quick access controls and an expandable navigation drawer or side panels to access secondary application features. |
| R |
| 2.01.01 |
| In addition to the map-based workflow, the application shall provide a natural-language query interface as an alternate means of exploring applicable regulations. See Section 10.00 for AI-Driven Query requirements. |
| D |
| 2.02 |
| The application shall display an introductory welcome interface upon first initialization that presents required legal disclaimers, guidance on interpreting overlapping regulations, positional accuracy limitations, data synchronization status, and an interactive navigation guide. |
| R |
| 2.03 |
| The application shall provide an option within the welcome interface allowing users to suppress the introduction on subsequent launches and shall make this introductory content permanently accessible for retrieval via the primary navigation panel. |
| R |
| 2.04 |
| The application shall prompt the user upon initialization to select either "Inland Waters" or "Ocean Waters" to configure the appropriate regulatory viewing module, spatial data layers, and rule-based logic model. |
| R |
| 2.05 |
| The application shall automatically determine the waterbody type of the resolved location upon launch and render the Regulation Summary results directly. |
| R |
| 2.05.01 |
| Where the resolved location is associated with a named waterbody (e.g., a Lake, River, or Marine Protected Area), the Regulation Summary results shall prominently display the waterbody name. |
| D |
| 2.06 |
| The application shall feature a persistent, high visibility "Locate Me" control on the map interface that centers the map view on the user's real-time geographic coordinates and initiates a regulatory query for that location. |
| R |
| 2.07 |
| The default map shall display established Department spatial layers outlining the general regulatory regions of California's Inland and Marine areas. |
| R |
| 2.08 |
| When a user selects a location on the map, the app shall drop a pin, highlight the boundaries of features, and display current Regulation Summary results for features that intersect with the selected location. |
| R |
| 2.08.01 |
| When a user selects a location on the map, the app shall automatically pan and zoom the map view to fit, within the device screen bounds, the largest intersecting feature boundary that is not the statewide boundary. |
| D |
| 2.09 |
| Where a single geographic coordinate intersects multiple overlapping regulatory features, the application shall generate an interactive species list within the Regulation Summary view. Selecting a specific species or species group from this list shall dynamically highlight all corresponding spatial boundaries on the map associated with that selection. |
| R |
| 2.10 |
| The map interface shall support native mobile touch gestures, including pinch-to-zoom, two-finger rotation, panning, and tap-to-select, with smooth rendering transitions executing at a minimum of 30 frames per second (FPS). |
| R |
| 2.11 |
| The application UI shall provide visual feedback indicating when the device is operating offline, explicitly signaling to the user that the displayed map tiles and regulatory lookups are pulling from local cached storage. |
| R |
| 3.00 |
| App UI - Regulation Rule Summary |
| 3.01 |
| The Regulation Rule Summary interface shall display an interactive, vertically scrollable accordion list of collapsed Species Cards matching the active geographic query |
| R |
| 3.02 |
| The Regulation Rule Summary shall display a collapsed list of Regulation Code Cards, positioned below the list of Species Cards, for regulations applicable to the active geographic query that are not represented by a Species Card |
| R |
| 3.03 |
| The interface shall include an inline search bar that filters the displayed Species Cards and Regulation Code Cards in real time using a fuzzy-match search, hiding cards that do not match the search input. |
| R |
| 3.03.01 |
| The search shall match against the Species Card Title (3.04.01), the Fishing Rule(s) Summary content of each Species Card (3.05.02), and the regulatory language displayed on each Regulation Code Card (3.07.02). |
| R |
| 3.04 |
| Species Card (Collapsed) |
| 3.04.01 |
| The Species Card Title shall display be the common name of the individual fish Species or the designated Species Group Name retrieved from the Centralized Regulations Database. |
| D |
| 3.04.02 |
| Each collapsed Species Card shall display a visual status indicator. The visual rendering, color-coding, icon mapping, and screen-reader accessibility rules for this indicator shall strictly conform to the standards defined in Section 4.00. |
| R |
| 3.05 |
| Species Card (Expanded) |
| 3.05.01 |
| The expanded Species card header shall continue to display all metadata, alerts, and status indicators established in the collapsed state (3.04). |
| D |
| 3.05.02 |
| The expanded view shall display a structured Fishing Rule(s) Summary compiled from the Centralized Regulations Database, including dates of the season, bag limits, sub-bag limits, possession, gear restrictions, size limits, depth restrictions, report card requirements, and relevant Regulation Codes |
| R |
| 3.05.03 |
| Relevant Regulation Codes: shall be rendered as interactive in-app hyperlinks that route the user directly to the corresponding section within the Regulation Report interface (Section 5.00) |
| R |
| 3.06 |
| Regulation Code Card (Collapsed) |
| 3.06.01 |
| Each collapsed Regulation Code Card shall display the Regulation Code. And the first 10 words of the regulatory language, truncated with an ellipsis. |
| R |
| 3.06.02 |
| Each collapsed Regulation Code Card shall be able to display a visual status indicator to alert users if the Regulation is flagged as an Advisory or with Yellow Flag =TRUE. The visual rendering, color-coding, icon mapping, and screen-reader accessibility rules for this indicator shall strictly conform to the standards defined in Section 4.00. |
| R |
| 3.07 |
| Regulation Code Card (Expanded) |
| 3.07.01 |
| The card header shall continue to display the same Code and Status Indicator(s) as the collapsed state. |
| D |
| 3.07.02 |
| The expanded card shall display the full verbatim regulatory language for the Regulation Code. |
| R |
| 3.07.03 |
| The Regulation Code shall be displayed as a link to that section of the Regulation Report (consistent with 3.05.03 and 5.05). |
| R |
| 4.00 |
| Visual Status Indicators |
| 4.01 |
| Visual Status Indicators shall be determined dynamically based on location, date, applicable regulations |
| R |
| 4.02 |
| The application shall use distinct, standardized visual indicators (pairing unique geometric symbols with specific color fills) to represent: Open, Closed, Restricted, Advisory and Emergency closure, etc. |
| R |
| 4.03 |
| Visual indicators shall not rely solely on color variations to convey regulatory meaning, ensuring full interface accessibility for color-blind users in compliance with Section 9.00. |
| M |
| 4.04 |
| The calculated visual status indicators shall be rendered uniformly across the Regulation Summary results and individual Species Cards. |
| R |
| 5.00 |
| App UI - Regulation Report |
| 5.01 |
| The application shall generate independent, standalone Regulation Reports partitioned by authoritative regulatory source, including California Code of Regulations (CCR) Title 14, California Fish and Game Code, Code of Federal Regulations (CFR) Title 15, CFR Title 50, and General Statewide Regulations. |
| R |
| 5.02 |
| Each Regulation Report shall display authoritative regulatory codes alongside their complete, unedited verbatim legal text, sorted sequentially by Regulation Code identifier. |
| M |
| 5.03 |
| Each Regulation Report shall programmatically group regulatory text by regulatory chapter and section, with each grouping introduced by a clear, accessible section header. |
| R |
| 5.04 |
| All textual data and structures within the Regulation Reports shall be rendered exclusively from the database payload cached locally on the device, ensuring full offline functionality. |
| R |
| 5.05 |
| The application shall support internal deep-linking, allowing any regulation code referenced within the summary views to instantly launch the specific section of the target Regulation Report. |
| D |
| 5.06 |
| Each Regulation Report shall include two search bars: a Code Search providing fuzzy matching on regulation codes, and a Text Search providing fuzzy matching on regulation text. |
| D |
| 6.00 |
| App UI - Map Interface |
| 6.01 |
| The application's map shall visually represent management areas (including MPAs and spatial fisheries management areas such as Rockfish Conservation Areas), currently active RCA fathom lines and waypoints, and anadromous and other inland waters subject to restrictive regulations. |
| R |
| 6.01.01 |
| The map shall support categorical layer symbology so that map classifications (e.g., area types) are visually distinguishable before the user drills into regulation-specific detail. |
| R |
| 6.02 |
| The map interface shall feature a persistent, quick-access telemetry control that toggles an on-screen heads-up display showing the user's real-time positional data, including Latitude/Longitude formatted in Degrees Decimal Minutes (DDM), and compass heading. |
| R |
| 6.03 |
| The application shall utilize differentiated baseline offline map styles optimized by waterbody module: |
Ocean Module: A hybrid basemap blending nautical bathymetry, coastal road networks, and low-altitude satellite imagery.
Inland Module: A hybrid basemap blending topographic contours, waterbody centerlines, and local street networks, matching the visual standards of the Department’s BIOS mapping application.
D
| 6.04 |
| The local storage allocation for offline map tiles shall be optimized using vector tile packages (VTPKs) to enforce strict scale-range constraints and maximum level-of-detail thresholds, limiting total device storage footprints. |
| D |
| 6.05 |
| The application settings interface shall provide users with configurable preset options (e.g., High Definition, Standard Definition, Low Storage) to manage local offline map storage sizes. |
| D |
| 6.06 |
| When active cellular or Wi-Fi connectivity is detected, the map interface shall allow the user to dynamically swap the basemap layer with live-streamed alternative formats, including Pure Nautical Charts, Topographical, Standard Street Maps, and High-Resolution Satellite Imagery. |
| D |
| 6.07 |
| Spatial features, boundaries, and points of interest shall be architected as discrete, isolated GIS layers within the map engine client. |
| R |
| 6.08 |
| The map interface shall dynamically add, remove, or alter the color styling of spatial boundary polygons in real time based on the active system date and seasonal regulation dates. |
| R |
| 6.09 |
| Inland Only - The map shall feature an optional, user-toggleable overlay layer that highlights all inland waters completely closed to fishing for the active system date dynamically driven by Centralized Regulations Database and current date. |
| D |
| 6.10 |
| The map shall feature a dedicated overlay layer to highlight anadromous waters and inland boundaries subject to highly restrictive or special take regulations. |
| D |
| 6.11 |
| The map interface shall provide an accessible layer-control drawer enabling users to independently toggle the visibility of every optional spatial layer on or off. |
| D |
| 6.12 |
| The map interface shall allow users to save their custom layer visibility configurations as their personal default view for subsequent application launches. |
| D |
| 6.13 |
| The map interface shall include a collapsible legend identifying map elements, symbols, and active layers displayed within the application. |
| R |
| 6.14 |
| The map interface shall display icons identifying piers and jetties where a fishing license is not required (“Free Fishing Piers”). These locations may be provided as a separate, user-toggleable map layer. Spatial data for these locations is already available. |
| R |
| 6.15 |
| The map interface shall feature a unified location search bar backed by a fuzzy searchable index of cities, counties, named waterbodies, and marine management zones. Search results for overlapping duplicate place names shall include county or regional qualifiers. Upon selection, the map engine shall smoothly pan and auto-zoom to fit the complete geometric boundary of the selected entity within the device viewport. |
| D |
| 6.16 |
| The map interface shall persistently render a text string displaying the current real-time horizontal GPS positional accuracy calculated in feet (e.g., "GPS Accuracy: +/- 15 feet"). |
| R |
| 6.17 |
| The map interface shall display a persistent text disclaimer in the legend or layer-control panel indicating that minor tributaries may not be visible at all zoom scales due to cartographic constraints or hydrographic scale limitations. |
| R |
| 7.00 |
| App UI – Side Panel & Navigation |
| 7.01 |
| The application shall feature a persistent global navigation drawer (side panel) accessible via a hamburger menu button or edge-swipe gesture, providing centralized access to core resources, secondary modules, and external secure references. |
| R |
| 7.02 |
| The navigation drawer shall include a direct-action control that launches the local. Regulation Report interface (5.00). |
| D |
| 7.03 |
| The navigation drawer shall include a verified external hyperlink that launches the device's native browser to the secure Department Online License Sales and Services portal. |
| R |
| 7.04 |
| The navigation drawer shall include an action item routing to an internal, locally cached informational screen detailing instructions on how to submit law-enforcement reports regarding poaching or environmental pollution via the Department's CalTIP program, including a direct-dial action trigger for the CalTIP hotline. |
| D |
| 7.05 |
| The navigation drawer shall feature an expandable section titled "Recreational Fishing Resources" that serves locally cached, non-textual or rich text content for educational outreach programs, including: "Fishing Challenges," "CDFW Fishing Opportunities," and "Learn to Fish. " |
| D |
| 7.06 |
| The navigation drawer shall provide a menu control that opens an external, secure user feedback questionnaire webform optimized for mobile viewports. |
| D |
| 8.01 |
| The settings interface shall feature a user toggle switch that enables or disables the automatic display of the initial Welcome Splash Screen displayed during subsequent application initializations. |
| D |
| 8.02 |
| The settings interface shall include a dedicated storage management utility allowing users to view total disk space consumed by cached files, delete downloaded basemap regions, and configure their preferred default offline mapping profile. |
| R |
| 9.00 |
| App UI - Accessibility |
| 9.01 |
| The user interface, typography, and iconography across all mobile deployment channels shall comply with the Department's official style guide standards approved by the Office of Communications, Education and Outreach (OCEO) |
| M |
| 9.02 |
| The application shall strictly conform to California Government Code Section 11135 and Department accessibility standards, incorporating programmatic labels (e.g., accessibility labels, traits, and hints) enabling native iOS VoiceOver and Android TalkBack screen readers to accurately verbalize all text, interface boundaries, and map element states. |
| M |
| 9.03 |
| All text layers, UI components, status indicators, and map legend icons shall pass standard contrast checkers by maintaining a minimum contrast ratio of 4.5:1 against their relative background fields. |
| M |
| 9.04 |
| The Application’s interface, menus, and local cached help guides shall support multi-languages localization. At a minimum, the Application shall provide support for Spanish, Vietnamese, Tagalog, and Mandarin Chinese. All language string tables shall be compiled locally on the device to maintain full multi-language capabilities while offline. |
| R |
| 10.00 |
| App UI - AI-Driven Queries |
| 10.01 |
| The application shall feature a natural-language query interface allowing users to inquire about recreational fishing regulations using conversational speech or free-form text (e.g., "What can I fish for under the Watt Ave. Bridge?") |
| D |
| 10.02 |
| The query interface shall accept user input via both text entry and voice-to-text transcription. |
| D |
| 10.03 |
| The application shall interpret user queries using a large language model (LLM) configured to resolve fishing-related questions against the Centralized Regulations Database. To prevent hallucinations, the LLM shall be strictly sandboxed drawing exclusively on the RFR Database with no reliance on external knowledge bases when formulating regulation responses. |
| D |
| 10.04 |
| Query responses shall be generated exclusively from regulation data stored in the Centralized Regulations Database and shall reflect the current published state of that data. |
| R |
| 10.05 |
| The LLM shall map location references within a query including informal or colloquial references such as landmark names, bridge names, or neighborhood references to the corresponding RFR spatial feature or regulation scope. |
| D |
| 10.06 |
| To maintain a consistent user experience, query responses shall be formatted using the same Regulation Code Card and Species Card UI presentation models used throughout the application. |
| R |
| 10.07 |
| If a user query cannot be successfully resolved to a specific location or species within the RFR Database, the application shall display a clear error message and suggest alternative search terms or navigation pathways. |
| R |
| 10.08 |
| The application shall include a disclaimer within the query interface stating that AI-generated responses are informational summaries and that official regulations govern in cases of discrepancy. This disclaimer shall be consistent with the disclaimer requirement in Section 1.13. |
| M |
| 10.09 |
| AI-driven query responses shall be subject to the same offline caching constraints as standard regulation content. When operating offline, the interface shall notify the user that query results are drawn on locally cached data and may not reflect real-time regulatory updates. |
| M |
| 11.00 |
| Notifications and Alerts |
| 11.01 |
| When the device's real-time coordinates enter a designated marine buffer zone adjacent to the international border with California–Mexico border or in waters outside California jurisdiction, the application shall trigger a persistent localized notification informing the user that customs or fishing declaration requirements may apply. |
| D |
| 11.02 |
| The application shall monitor real-time location telemetry in the background while the application is active; when the device crosses a boundary separating different regulatory zones, the application shall flash a non-disruptive on- screen alert to the user indicating that that the applicable regulations have changed. |
| D |
| 11.03 |
| In marine regions, the application shall notify the user as they navigate across a defined boundary. The set of notifying boundaries shall be determined by CDFW and includes, but is not limited to, MPAs, general management zones, and state and international borders. |
| R |
| 11.04 |
| The application shall support push notifications (leveraging Apple Push Notification service and Firebase Cloud Messaging) to inform users of relevant regulatory updates, emergency closures, and time-sensitive changes based on user preferences and location. |
| R |
| 12.00 |
| RFR Content Management Interface (CMI) |
| 12.01 |
| The existing RFR Content Management Interface completed during Phase 1 shall be modified to support the administrative workflows, data expansions and structural model required by the public mobile application client. |
| D |
| 12.02 |
| A new administration module section shall be integrated into the RFR Content Management Interface allowing the authorized users to manage - author, format, update, and categorize the “Recreational Fishing Resources” data feed. The CMI shall expose this managed content through the API endpoint for ingestion and offline caching by the mobile client. . |
| R |
| 13.00 |
| AI-Driven Regulation Data Pipeline |
| 13.01 |
| The structured regulation data captured in this database shall serve as a baseline training dataset for a large language model (LLM) designed to interpret raw regulatory source text and translate it into structured database records. |
| D |
| 13.02 |
| The LLM shall be trained to recognize regulatory patterns (including seasonal restrictions, species-specific rules, and jurisdictional boundaries) and automatically populate or update the database as source regulations change, enabling the application to serve summarized, user-ready content without manual data entry for each regulatory cycle. |
| D |
| 13.03 |
| The current database build is not required to serve as the runtime data source for the public-facing application. The application's production data pipeline may be LLM-driven, with the curated database serving as the ground truth against which model outputs are validated prior to publication. |
| D |
| 13.04 |
| The LLM pipeline shall support automated retrieval of regulatory updates from authoritative legal and regulatory services (e.g., Westlaw) to detect and ingest changes to fishing regulations without reliance on manual monitoring or user-submitted source text. |
| D |
| 13.05 |
| All database changes proposed by the LLM pipeline shall require mandatory review and formal approval by a subject matter expert (SME) before publication. Proposed changes shall enter the existing RFR Content Management Interface (CMI) staging and approval process, following the same Draft → Staged → Published promotion workflow as manually authored content. |
| D |
| 14.00 |
| Regulation Database |
| 14.01 |
| The existing Azure SQL Server Regulation Database shall be enhanced with updated schemas, indexing structures, and spatial query tracking tables necessary to optimize data serving performance for the public mobile application client. |
| R |
| 14.02 |
| The database schema shall support granular, row-level state tracking enabling approved Subject Matter Experts to stage , update and approve changes to designated fields through the Content Management Interface. |
| M |
| 14.03 |
| The database engine shall support cross-year date formatting strings, allowing fishing season parameters to span across calendar years , (e.g., opening October 15 and closing March 15 of the following year) without breaking date comparison logic. |
| M |
| 14.04 |
| The database schema shall feature dedicated structural tables to capture, flag, and prioritize temporary Emergency Regulations and regional consumption Advisories, linking them dynamically to impacted species and waterbody features. |
| M |
| 14.05 |
| Relational database tables shall be added to capture, map and track text assets, images and lookup links associated with the Recreational Fishing Resources. |
| R |
| 15.00 |
| GIS Features and Management |
| 15.01 |
| All Application spatial features, management zones and regulatory boundary shapes shall be managed and published through CDFW’s Arc GIS Online service. |
| R |
| 15.02 |
| When creating, modifying, or deleting a spatial feature, the system shall require a workflow-based approval process that supports staging, review, and publishing of changes prior to release to production. The workflow shall ensure that proposed changes can be validated and approved by authorized users before becoming publicly available or distributed to the client application. |
| R |
| 15.03 |
| Additional geographic features shall be created and configured to support detailed Trout, Salmon, and Black Bass regulations under Title 14, Sections 5.00, 7.00, 7.40, and 7.50, in the initial release. (Marine features are largely complete while inland features currently support general regulations only.) See Exhibit A – Inland Selection of Regulations for additional detail on the current state of Inland GIS data, known limitations, and proposed solutions. |
| R |
| 15.04 |
| Federal and state MPAs and other complementary boundary layers shall be displayed as persistent reference layers, remaining visible across all map views at all times. |
| R |
| 15.04.01 |
| Where adjacent jurisdictional areas share related regulations, the application shall be presented side by side (e.g., Federal Rockfish Conservation Areas alongside state groundfish regulations). |
| R |
| 16.01 |
| The application shall utilize API calls to the Centralized Regulations Database and ArcGIS Service to fetch and locally cache regulation and spatial data. |
| R |
| 16.02 |
| Upon launch, the application shall automatically fetch the latest data from the Centralized Regulations Database and ArcGIS Service when a network connection is available, cache all fetched data locally on the device, and serve this cached data to the user when operating offline. |
| M |
| 16.03 |
| An on-screen indicator shall display whether the application is operating online or offline. When offline, a warning icon shall link to a notification showing the time elapsed since the last sync, accompanied by a disclaimer that regulations may be out of date and are not guaranteed to be accurate. |
| R |
| 16.04 |
| The application shall provide a manual refresh option, allowing users to force a data update without having to restart the application |
| R |
| 17.00 |
| Staging Data Edits and Promoting to Application Front End |
| 17.01 |
| The platform shall implement a controlled, auditable promotion workflow that allows authorized users to author and revise regulation and rule content without affecting publicly visible data, stage approved changes for review and publish finalized content to the public-facing application. |
| M |
| 17.01.01 |
| Detailed functional and technical requirements for this workflow are defined in Exhibit B: Record Promotion — Single-Database Status Lifecycle Model. |
| M |
| 17.02 |
| The staging process shall give approved reviewers the opportunity to provide feedback on the correctness of the application's content before publication. |
| M |