Design decisions register
Append-only log of design decisions and the guidance behind them (PRD/SDD citations included). Superseded entries are dimmed and linked to their replacement.
Source feedback — Gokhan, 2026-08-04 (verbatim; drove DD-120 through DD-127 below)
No changes should be made to the main page design. Ensure that everything aligns with the requirements and follows them exactly as specified. Keep the existing menu and make it compact. The hamburger menu (three-line menu) should remain as it is. There is no need for a ribbon. The ribbon should only appear on the page displaying the map, as it takes up valuable screen space. If I need it, I can access it there. There should also be a button linking to the requirements. The dashboard should follow good UI/UX design principles, such as the 60-30-10 (or 70-20-10) layout principle. Around 60% of the screen should be dedicated to the main purpose of the page. Since the map is the primary focus, it should occupy most of the available space. Remove the ribbon so the dashboard presents a clean map interface. Ensure that every feature is directly justified by the requirements. Forecast: This is fine. Menu: Keep the existing menu. Impact-Based Forecast: Check that it aligns with the requirements. Alert Page: There are too many items, and it is difficult to understand how they relate to the requirements. Some of the features appear to be isolated ideas rather than requirement-driven. Review the requirements carefully and determine what should actually be displayed on this screen. Drafting and Dissemination: This looks good, but we still need to discuss it. I do not know why the Risk section was removed. Risk and Impact should remain as separate sections. All text-based content should be placed under the Knowledge section. The language selection should be moved to the Settings menu. Group related menu items together to make the navigation more compact and organized. In the repository you shared, there are several skills that I approved. However, every feature and design decision must be based on the requirements. The AI Report, Dissemination, and Admin sections can be placed under the user menu. Finally, be precise with terminology. When referring to alerts or reports, clearly distinguish between Alert Dissemination and Report Distribution, and use the correct term consistently throughout the application.
Open decisions — not built
A different register from the one below. The log below records decisions already made and applied to the mockup. These six are contradictions between the user-scenario document and the requirements register: each adds developer responsibility beyond the requirements, so none of them is built, and each is surfaced on the screen where it would otherwise land so the gap is visible at the point of work rather than only here.
| # | Decision | The contradiction | Would land on | State |
|---|---|---|---|---|
| D-1 | Duty model | The user scenario names Reviewer, Release Authority, Data Manager, Threshold Maintainer and Verification duties. FR-44 defines three roles only — Viewer / Analyst / Admin. Journeys J2, J3, J6 and O2 do not run as written under three roles. Either the duties become assignable grants on top of the three roles, or the journeys are rewritten to fit FR-44. | AD-5 Users & Roles | Not built — highest priority |
| D-2 | Externally-declared severity route | For cyclone and earthquake the severity is declared by the responsible authority (RSMC La Réunion; USGS PAGER). Carrying it in unedited and attributed is not covered by FR-8A, which concerns forecast values, not declared severity. Without it the platform either recomputes a severity the authority already set, or blocks the hazard. Occasional journey O2 depends on it. | EW-1, EW-2 | Not built |
| D-3 | Two-tier trigger naming | Readiness / Activation is built as a label on the existing
open → escalated lifecycle (FR-19). If it must instead be a stored
tier field, that is a schema change — a column on EW-1 rather than a label. |
EW-1, EW-2 | Built as a label only |
| D-4 | Drill / dry-run mode | Journey J0 includes running a scheduled dry run against retained data. Not in the requirements. Genuinely useful for the per-hazard case studies planned next — and a real build cost. It is the one testing capability the register does not already cover. | EW-1 | Not built |
| D-5 | Sub-6-hour activation | Where activation lead is under 6 hours (flash flood), a maker–checker gate is not achievable. Either the response is pre-authorised for defined conditions, or the platform issues an internal notice only. A governance decision, not a UI one — must be settled before any flash-flood hazard is onboarded. | EW-1 | Not built |
| D-6 | Public surface scope | Journey J5 sends recipients to a public read-only view. FR-49 and NFR-8 require login before any platform data is accessible. The public CAP feed, the published report list (SR-17) and the Methodology page (SR-18) are the presumed carve-out — but the carve-out has never been stated explicitly, and J5 as written goes further than those three. | OT-1, KA-1 | Partially built — carve-out not confirmed |
Also open from the design documentation: whether the national disaster authority approves alerts inside the platform, whether a composite risk index is sufficient for vulnerability, and the multi-tenancy implications of scoping an Analyst to a country or organisation.