NATO CEDI Website Demo Requirements
| Type | Level | UID | PREFIX | REFS | Title | Statement | Rationale | Comment |
|---|---|---|---|---|---|---|---|---|
| SECTION | 1 | 1. Content Management |
||||||
| REQUIREMENT | 1.1 | WD-FR-001 | Payload CMS Admin Access |
When an authorised content editor navigates to the /admin path of the NATO CEDI website, the system shall present the Payload CMS v3 administration interface, allowing the editor to create, edit, publish, and delete content across all defined collections without requiring developer intervention. |
The NATO CEDI communications team must be able to operate the website without engineering support for routine content updates. |
|||
| REQUIREMENT | 1.2 | WD-FR-002 | Page Builder Blocks |
When an editor creates or edits a page in Payload CMS, the system shall provide a block-based page builder offering at minimum the following block types: Hero, Rich Text, Call to Action, Image with Caption, Cards Grid, and Embed. Blocks shall be reorderable via drag-and-drop within the admin interface. |
A block-based builder reduces time-to-publish for new pages and eliminates developer involvement for layout changes. |
|||
| REQUIREMENT | 1.3 | WD-FR-003 | Content Lifecycle — Draft, Published, Archived |
All content items (pages, news articles, events, media) shall support three lifecycle states: Draft, Published, and Archived. Only items in the Published state shall be visible to unauthenticated public visitors. Transitioning between states shall be recorded with a UTC timestamp and the identity of the actor performing the transition. |
NATO communications policy requires review and approval before public visibility; lifecycle states enforce this gate. |
|||
| REQUIREMENT | 1.4 | WD-FR-004 | Scheduled Publication |
When an editor sets a future publish date on a content item, the system shall automatically transition that item from Draft to Published at the specified UTC time without requiring manual action at the time of publication. |
Press releases and event announcements have strict embargo times; manual publishing at midnight is not operationally viable. |
|||
| REQUIREMENT | 1.5 | WD-FR-005 | Localisation-Ready Content Fields |
All user-facing text fields in Payload CMS collections shall be defined with the localisation option enabled so that future language variants can be added without schema migration. The default and only active locale at launch shall be English (en). |
NATO operates in two official languages; designing for localisation from day one avoids costly retrofits. |
|||
| SECTION | 2 | 2. News & Blog |
||||||
| REQUIREMENT | 2.1 | WD-FR-006 | News Article Creation |
When an editor creates a news article in the CMS, the system shall capture the following required fields: title, slug (auto-generated from title, editable), author name, publication date, cover image, body (rich text), summary (plain text, max 300 characters), and one or more tags. The article shall not be publicly visible until its lifecycle state is set to Published. |
Consistent metadata fields enable reliable listing, filtering, SEO metadata generation, and OpenGraph card rendering. |
|||
| REQUIREMENT | 2.2 | WD-FR-007 | News Listing Page |
The website shall provide a /news listing page that displays all Published news articles in reverse chronological order, showing for each article the cover image, title, summary, publication date, and tag list. The listing shall paginate at 12 articles per page and provide previous/next navigation. |
Pagination prevents excessive page weight on the listing route and keeps Core Web Vitals within acceptable bounds. |
|||
| REQUIREMENT | 2.3 | WD-FR-008 | Tag-Based Filtering on News Listing |
The news listing page shall provide a tag filter control that, when a visitor selects one or more tags, updates the listing to display only articles that carry all selected tags. The active filter state shall be reflected in the URL query parameters to allow sharing of filtered views. |
URL-reflected filter state supports sharing, bookmarking, and server-side rendering of filtered pages for SEO. |
|||
| REQUIREMENT | 2.4 | WD-FR-009 | Individual News Article Page |
Each published news article shall be accessible at a canonical URL of the form /news/[slug]. The page shall display the article title, author name, publication date, cover image, full rich text body, and tag list. The page shall include structured data (Schema.org NewsArticle) in JSON-LD format for search engine indexing. |
Canonical URLs and structured data improve search discoverability and enable rich results in Google Search. |
|||
| SECTION | 3 | 3. Events |
||||||
| REQUIREMENT | 3.1 | WD-FR-010 | Event Record Creation |
When an editor creates an event in the CMS, the system shall capture the following fields: title, slug, event type (Conference, Workshop, Hackathon, Webinar, Exercise — single choice), start date-time (UTC), end date-time (UTC), location (venue name and/or online meeting link), cover image, description (rich text), and an optional external registration URL. |
Structured event fields drive machine-readable Schema.org Event markup, calendar exports, and listing filters. |
|||
| REQUIREMENT | 3.2 | WD-FR-011 | Events Listing Page |
The website shall provide an /events listing page that displays all Published events sorted by start date ascending (upcoming first). Past events shall appear in a separate "Past Events" section sorted by start date descending. Each card shall show the event title, type badge, start date, location summary, and cover image. |
Separating upcoming from past events preserves the historical record while presenting the most actionable content first. |
|||
| REQUIREMENT | 3.3 | WD-FR-012 | Event Filtering by Type and Date Range |
The events listing page shall provide filter controls for event type and date range. When a visitor applies filters, the listing shall update to show only events matching all active filter criteria. Filter state shall be reflected in URL query parameters. |
Type and date filters are the two primary dimensions by which NATO CEDI audiences segment events. |
|||
| REQUIREMENT | 3.4 | WD-FR-013 | Individual Event Detail Page |
Each published event shall be accessible at /events/[slug]. The page shall display the full event description, date/time (formatted in the visitor's local timezone), location, and, when an external registration URL is present, a clearly labelled "Register" call-to-action button that opens the external URL in a new tab. The page shall include Schema.org Event structured data in JSON-LD format. |
Combining full detail with a single CTA reduces drop-off between discovery and registration. |
|||
| SECTION | 4 | 4. Media Library |
||||||
| REQUIREMENT | 4.1 | WD-FR-014 | Upload Research Papers and Videos |
The Payload CMS media library shall accept uploads of the following file types: PDF (research papers, reports) and MP4/MOV (video recordings). Accepted file size limits shall be 50 MB for PDFs and 2 GB for video files. The system shall reject uploads that exceed these limits with a descriptive error message. |
Centralising uploads in Payload CMS ensures all media is subject to the same lifecycle workflow and metadata standards. |
|||
| REQUIREMENT | 4.2 | WD-FR-015 | Media Metadata Capture |
When an editor uploads a media item, the system shall prompt for and store the following metadata fields: title (required), authors (repeating text field, at least one required), abstract (rich text, required for PDFs, optional for video), media type (Research Paper, Report, Video Recording, Presentation — single choice, required), and published date (required). All metadata shall be editable after upload. |
Rich metadata enables effective search, filtering, and citation by external researchers and partner nations. |
|||
| REQUIREMENT | 4.3 | WD-FR-016 | Media Library Listing with Filters |
The website shall provide a /media listing page displaying all Published media items. The page shall offer filter controls for media type and year of publication. Each listing card shall show the title, type badge, authors, published date, and a download or external link button. Results shall be sortable by published date (newest first by default) and by title (A–Z). |
Filter and sort controls make the library useful as the collection grows beyond a few dozen items. |
|||
| REQUIREMENT | 4.4 | WD-FR-017 | Download and External Link Behaviour |
For media items stored as file uploads, the media detail page shall provide a direct download link using the Content-Disposition: attachment header. For media items with an external URL (e.g. a journal article behind a publisher's DOI), the system shall display an "Access via publisher" link that opens in a new tab. Both link types shall be mutually exclusive per media record. |
Distinguishing hosted downloads from external links prevents broken user expectations about where clicking will lead. |
|||
| SECTION | 5 | 5. Hackathon Hub |
||||||
| REQUIREMENT | 5.1 | WD-FR-018 | Hackathon Edition Landing Page |
The website shall support multiple hackathon editions, each accessible at /hackathon/[edition-slug]. Each landing page shall display the hackathon name, edition year, dates, theme, description (rich text), key dates timeline, sponsors section, and links to the active registration, call for speakers, and project submission forms. The active forms shall be driven by CMS-controlled open/closed flags per form type per edition. |
Per-edition pages allow multiple hackathon editions to coexist on the site without URL conflicts or content pollution. |
|||
| REQUIREMENT | 5.2 | WD-FR-019 | Participant Registration Form |
When the participant registration form is open for a hackathon edition, the website shall present a form collecting: full name (required), email address (required, validated), organisation (required), and role (required, free text). On submission the system shall store the response in the PostgreSQL database and send a confirmation email to the provided address. The form shall display a success message on completion and shall not require account creation. |
Frictionless email-only registration maximises sign-up conversion; email confirmation provides proof of registration to the participant. |
|||
| REQUIREMENT | 5.3 | WD-FR-020 | Call for Speakers Form |
When the call for speakers form is open for a hackathon edition, the website shall present a form collecting: speaker full name (required), email address (required, validated), proposed talk title (required, max 150 characters), abstract (required, min 100 characters, max 1000 characters), and short bio (required, max 500 characters). On submission the system shall store the response and send a confirmation email. Duplicate submissions from the same email address for the same edition shall be rejected with a descriptive error message. |
Character limits and duplicate detection protect the review panel from unusable submissions and reduce manual triage effort. |
|||
| REQUIREMENT | 5.4 | WD-FR-021 | Project Submission Form |
When the project submission form is open for a hackathon edition, the website shall present a form collecting: team name (required), contact email (required, validated), project title (required, max 100 characters), project description (required, min 150 characters, max 2000 characters), repository URL (optional, must be a valid HTTPS URL when provided), and demo URL (optional, must be a valid HTTPS URL when provided). On submission the system shall store the response and send a confirmation email. The form shall enforce a one-submission-per-email-per-edition policy. |
Structured submission with URL validation allows automated ingestion into the judging workflow with minimal data cleaning. |
|||
| REQUIREMENT | 5.5 | WD-FR-022 | Form Open/Closed State |
Each of the three hackathon forms (participant registration, call for speakers, project submission) shall have an independently configurable open/closed state managed in Payload CMS per hackathon edition. When a form is closed, the website shall display an informational message in place of the form, stating whether registration is not yet open or has closed, and shall not accept any new submissions. |
CMS-controlled open/closed flags allow organisers to manage timing independently of the engineering team. |
|||
| REQUIREMENT | 5.6 | WD-FR-023 | Results Showcase |
After a hackathon edition concludes, the website shall display a results showcase section on the edition landing page listing all participating projects ranked by their final placement. Each entry shall show the team name, project title, project description summary, and any award badges (e.g. "1st Place", "Best Innovation", "Audience Choice"). Award badges shall be configurable in Payload CMS per project entry. |
A public results showcase reinforces NATO CEDI's commitment to transparency and encourages future participation. |
|||
| SECTION | 6 | 6. Non-Functional Requirements |
||||||
| REQUIREMENT | 6.1 | WD-NFR-001 | Core Web Vitals — LCP |
All public-facing pages of the NATO CEDI website shall achieve a Largest Contentful Paint (LCP) of 2.5 seconds or less when measured on a simulated mid-range mobile device (Moto G4 equivalent) with a Slow 4G network profile in Google Lighthouse. This target shall be validated in the CI pipeline on every production build. |
Google's "Good" LCP threshold is 2.5 s; failing this threshold has a measurable negative impact on search ranking and user retention. |
|||
| REQUIREMENT | 6.2 | WD-NFR-002 | Core Web Vitals — CLS and INP |
All public-facing pages shall achieve a Cumulative Layout Shift (CLS) score of 0.1 or less and an Interaction to Next Paint (INP) of 200 milliseconds or less, as measured by Google Lighthouse on the same simulated device profile defined in WD-NFR-001. |
CLS and INP round out the Core Web Vitals triad; all three must be in the "Good" band to achieve a passing CWV assessment. |
|||
| REQUIREMENT | 6.3 | WD-NFR-003 | WCAG 2.1 AA Accessibility Compliance |
All public-facing pages and interactive components of the NATO CEDI website shall conform to WCAG 2.1 Level AA success criteria. This includes but is not limited to: sufficient colour contrast ratios (4.5:1 for normal text, 3:1 for large text), keyboard navigability of all interactive elements, visible focus indicators, descriptive alt text on all non-decorative images, and ARIA roles on all custom interactive widgets. |
WCAG 2.1 AA is the internationally recognised accessibility standard and is required by EU Directive 2016/2102 for public sector bodies. |
|||
| REQUIREMENT | 6.4 | WD-NFR-004 | Automated Accessibility Audit in CI |
The CI pipeline shall run an automated accessibility audit using axe-core (or equivalent) on a representative set of rendered pages on every pull request. Any WCAG 2.1 AA violation classified as "critical" or "serious" by axe-core shall cause the pipeline to fail and block merge. |
Automated gating enforces a baseline standard without relying on manual review for every change. |
|||
| REQUIREMENT | 6.5 | WD-NFR-005 | SEO — Page-Level Meta Tags |
Every public-facing page shall render a unique <title> element (max 60 characters), a <meta name="description"> element (max 160 characters), and canonical <link rel="canonical"> element. CMS-managed content pages (news articles, events, media items) shall derive these values from the item's title, summary/abstract, and slug fields. Default fallback values shall be defined for pages without CMS-authored metadata. |
Unique, descriptive meta tags are the foundational on-page SEO signal; missing or duplicated tags negatively impact search ranking. |
|||
| REQUIREMENT | 6.6 | WD-NFR-006 | SEO — OpenGraph and Twitter Card Tags |
Every public-facing page shall render OpenGraph meta tags (og:title, og:description, og:image, og:url, og:type) and Twitter Card meta tags (twitter:card, twitter:title, twitter:description, twitter:image). CMS-managed content shall use the cover image as the og:image value. Pages without a specific cover image shall use a designated NATO CEDI default OpenGraph image. |
OpenGraph tags control the visual preview rendered when URLs are shared on LinkedIn, X/Twitter, and messaging platforms — primary distribution channels for NATO CEDI communications. |
|||
| REQUIREMENT | 6.7 | WD-NFR-007 | SEO — Sitemap and Robots |
The website shall automatically generate a sitemap.xml at /sitemap.xml listing all public Published pages, news articles, events, and media items with their canonical URLs and last-modified dates. A robots.txt file at /robots.txt shall allow indexing of all public pages and shall disallow indexing of /admin and any other non-public paths. Both files shall be regenerated on every production deployment. |
A machine-generated sitemap eliminates manual maintenance and ensures newly published content is discoverable within the next crawl cycle. |
|||
| REQUIREMENT | 6.8 | WD-NFR-008 | Security — No Secrets in Source Control |
The website repository shall not contain any secret values (API keys, database connection strings, JWT secrets, email provider credentials) in source-controlled files. All secrets shall be managed via environment variables injected at build and runtime. A .gitignore rule and a pre-commit hook (e.g. git-secrets or trufflehog) shall be configured to block accidental commit of .env files or known secret patterns. |
A single leaked credential in a public repository can compromise the entire deployment; pre-commit scanning provides an automated safety net. |
|||
| REQUIREMENT | 6.9 | WD-NFR-009 | Security — Content Security Policy Headers |
The Next.js application shall serve a Content-Security-Policy HTTP response header on all pages that restricts script execution to known first-party origins and explicitly approved third-party CDNs. The policy shall include default-src 'self', shall disallow inline event handlers (no unsafe-inline for script-src except for Next.js nonce-based inline scripts), and shall be reviewed and updated as part of any dependency change that introduces new external script sources. |
A strict CSP is the primary browser-side defence against cross-site scripting; Next.js nonce support makes enforcement compatible with framework-generated scripts. |
|||
| REQUIREMENT | 6.10 | WD-NFR-010 | Security — CSRF Protection on Forms |
All form submission endpoints (participant registration, call for speakers, project submission) shall validate a CSRF token tied to the user's session before processing any submitted data. The Next.js server actions or API routes handling form submissions shall reject requests that do not carry a valid token with a 403 Forbidden response. The token shall be rotated on each new page session. |
CSRF protection is a baseline security control for any web form that mutates server-side state, even when authentication is not required. |
|||
| REQUIREMENT | 6.11 | WD-NFR-011 | NATO Visual Identity Compliance |
All public-facing pages shall apply the NATO CEDI design token set defined in libs/design-system, using only the semantic Tailwind CSS tokens (bg-background, text-foreground, bg-primary, etc.) and NATO-specific colour variables from styles.css. Hardcoded hex colour values shall not appear in any component source file. The site shall support the theme-light, theme-dark, and theme-nato CSS class variants defined in the monorepo design system. |
Using shared design tokens from the monorepo design system ensures visual consistency across all NATO CEDI digital products and simplifies future brand updates. |
|||
| REQUIREMENT | 6.12 | WD-NFR-012 | Next.js Static Generation for Public Pages |
All public-facing content pages (news articles, event detail pages, media items) shall be rendered using Next.js Static Site Generation (generateStaticParams) at build time. The site shall support Incremental Static Regeneration (ISR) with a revalidation interval of no more than 60 seconds so that newly published CMS content is reflected on the live site within one minute of publication without a full rebuild. |
ISR combines the performance benefits of static generation with the freshness requirements of a CMS-driven site, eliminating the need to choose between the two. |