Public Site Requirements

Site

A customer’s public website, run on a CMS, connected to one EMS organisation.

Multi-event site

A site for an organisation or a series that lists and presents many events.

Single-event site

A site devoted to one event, whose home page is that event.

Event page

The site’s page for one EMS event: page parts showing EMS data, placed by default from a template and arranged by the editor, with the editor’s own content anywhere between them.

Page part

A reusable element that shows EMS data on a page (for example the categories table or the register button). Each implementation offers the same parts with the same properties.

Registration portal

The EMS web application where entrants enter events and join or renew memberships, reached through a portal tenant linked to the site’s organisation.

Payment provider

Whatever takes the payment for an order: today a WooCommerce store on the site, later EMS itself.

Operator

The person who sets up and runs sites on the platform.

PS-ST-01

A site serves either one EMS organisation with many events (multi-event site) or a single event (single-event site).

PS-ST-02

A single-event site’s home page is the event page of its event, and its other pages (for example a course or a contact page) may use the same page parts.

PS-ST-03

A multi-event site may restrict the events it shows to a series, a discipline, an event type or an explicit selection.

PS-EP-01

Each published event on the site has one event page, linked to one EMS event, at a stable URL of the form /event/<slug>/.

PS-EP-02

An event page is composed of page parts and the editor’s own content. There is no fixed area: every part, including the event header and details, can be moved or removed, and content can be placed anywhere between parts.

PS-EP-03

A new event page starts from a template that places the usual parts in the usual order: event header, event details (date and time, venue, organiser and contacts, add to calendar), map, register button, and below them categories, fees, program, courses and event navigation. The site can define its own template.

PS-EP-04

Parts show EMS data for the page’s event; the page holds no copy of it. A change in EMS appears on the page without editing it.

PS-EP-05

Removing a part from a page removes only that part; nothing else on the page depends on it.

PS-EP-06

A page part shows nothing, or a short neutral note, when EMS holds no data for it; it never shows an error to a visitor.

PS-EP-07

An event page shows when its event has passed, and then gives prominence to results and start lists rather than registration.

PS-EP-08

A site may keep pages for events that were never in EMS (archived events). An archived event keeps its date, venue and organiser as a stored snapshot, is shown in the same layout, and offers no registration.

PS-PP-01

Event header

Name, date, venue line, registration status

PS-PP-02

Event details

Date and time, venue and address, organiser and contacts, add to calendar

PS-PP-03

Map

Venue location, with a link to directions

PS-PP-04

Categories

Categories with age or birth-year ranges, gender, and the races each offers

PS-PP-05

Fees

Entry fees per category or product, with closing dates and late-entry fees

PS-PP-06

Program

The schedule of races and activities by day and time

PS-PP-07

Courses

Courses or routes with distance and elevation; the route map is the embedded map of the course’s route at the route provider (RideWithGPS), identified by its route id

PS-PP-08

Start lists

Published start lists, with release time and download

PS-PP-09

Results

Published results, linking to full result sets

PS-PP-10

Register button

The entry or membership hand-over (see Registration)

PS-PP-11

Event list

Events as a list, grid or calendar, filtered and sorted (see Event lists)

PS-PP-12

Featured events

A small set of highlighted upcoming events, for example on a home page

PS-PP-13

Event navigation

Links to the previous and next event and back to the event list (multi-event sites)

PS-PP-20

An editor can place any part on any page, not only on event pages, by naming the event.

PS-PP-21

An editor can add a short note of their own to a part (for example a remark under the fees) without replacing the EMS data.

PS-PP-22

Parts render on the server: the content is in the page sent to the browser, readable without JavaScript and visible to search engines.

PS-EL-01

The site lists its upcoming events, soonest first, each with name, date, venue, registration status and a link to its event page.

PS-EL-02

The list can show past events (most recent first), filtered by year.

PS-EL-03

The list can be filtered by series, discipline or event type, and offered as list, grid or month calendar.

PS-EL-04

An empty list says so in plain words (for example "No upcoming events") and links to past events.

PS-EL-05

The site offers a subscribable calendar feed of its events.

PS-RG-01

The register button sends the visitor to the registration portal’s process flow for the event, or to the membership registration page for a membership.

PS-RG-02

A visitor who is signed in on the site arrives in the portal signed in, with the people they manage available. The hand-over uses a signed, personal, short-lived link that is created when the visitor clicks, never stored in the page.

PS-RG-03

The site can offer a visitor who is not signed in the choice between signing in and continuing as a guest, explaining what signing in gives them. A failed sign-in returns them to the page with the choice offered again.

PS-RG-04

The button reflects the registration status: before opening it states the opening date; after closing it states that entries are closed; for a past event it is not shown.

PS-RG-05

The site accepts only an event that the page actually offers when building the hand-over link.

PS-RG-06

The button’s wording and style are set by the editor; its behaviour is not.

PS-PY-01

EMS creates and owns the order. The payment provider takes payment for it and reports the outcome to EMS.

PS-PY-02

A paid order is never moved back to unpaid, failed or cancelled by an automatic process. Only a refund or an operator action changes a paid order.

PS-PY-03

A payment message that fails its authenticity check changes nothing and is recorded for the operator.

PS-PY-04

Each order uses one payment transaction; returning to the payment page reuses it rather than starting another.

PS-PY-05

Every change of payment state is reported to EMS within a minute, with the provider’s transaction reference, and a failed report is retried.

PS-PY-10

A site with its own store keeps its own checkout configuration (gateways, branding, order email) under the customer’s control.

PS-PY-11

A cancelled store order is reported to EMS as cancelled. Deleting or trashing an order that EMS still tracks is refused, or warned against, until EMS has been told.

PS-PY-12

The store offers its products to EMS so that EMS products can be mapped to them in EMS, without a limit on the number of products.

PS-PY-13

Removing the store from a site (when EMS becomes the payment provider) requires no change to event pages, page parts or registration.

PS-ED-01

An editor creates an event page by choosing an EMS event; the template’s parts fill from EMS at once.

PS-ED-02

An editor inserts page parts through the CMS’s own editor (blocks where the CMS has them, and a text form such as a shortcode where it does not), choosing properties from lists rather than typing identifiers.

PS-ED-03

A preview shows the page as it will appear, including EMS data.

PS-ED-04

The editor can move, remove and add parts and content freely after the template has placed them, and can choose another template.

PS-CF-01

A setting can come from a part’s properties, from the event page, from the site’s settings screen, or from the hosting environment. The more specific source wins, in that order, except that a value set by the hosting environment cannot be changed from the settings screen, which shows it as fixed.

PS-CF-02

Secrets (keys, signing secrets) are never shown, logged or exported, and can be set from the hosting environment.

PS-CF-03

The site’s EMS organisation follows from its connection to EMS; nobody types an organisation id.

PS-ON-01

A guided set-up connects a new site to EMS: the operator obtains an enrolment code in EMS and enters it on the site, or follows a hand-off to EMS that returns to the site.

PS-ON-02

Set-up creates or links the registration portal tenant and the registration system for the site, issues the credentials in both directions (site to EMS and EMS to site), and records the site’s callback address in EMS. No key is copied by hand.

PS-ON-03

When the site has a store, set-up also registers the store with EMS as its payment provider.

PS-ON-04

Set-up ends with a check that proves each direction works (the site can read the event list, EMS can reach the site) and reports anything missing in plain words.

PS-ON-05

Credentials can be rotated from EMS without editing the site by hand, and the change takes effect without restarting any service.

PS-OB-01

The site reports its logs and metrics (requests to EMS and their outcome, hand-overs, payment callbacks, errors) to the platform’s observability stack under its own identity.

PS-OB-02

The site offers an authenticated interface for remote operation: status and version, effective configuration (without secrets), recent errors, clearing its caches, and re-synchronising with EMS.

PS-OB-03

Remote operation is usable from an AI assistant over MCP, through EMS, with the same permissions the operator has.

PS-OB-04

Anything the site rejects (a bad signature, an unknown event, a failed payment message) is recorded with enough context for the operator to act, and without secrets.

PS-OB-05

The site traces its requests. A trace continues across calls between the site and EMS in both directions (the trace context travels with each call), so one request can be followed from the site into EMS and back.

PS-OB-06

Every log line the site writes while handling a traced request carries the trace and span id, so a log line leads to its trace and a trace to its log lines.

PS-OB-07

Tracing can be switched on or off, and its sampling rate set. A sampling decision made upstream (an incoming call that is already traced) is honoured.

PS-OB-08

A debug mode raises logging to the most detailed level and samples every request. It is switched on for a limited time and switches itself off when that time ends.

PS-OB-09

Sending telemetry never slows a visitor’s request: it is sent after the response or by a separate process.

PS-OB-10

A site that runs outside the platform sends its telemetry over the standard OpenTelemetry protocol to the platform’s authenticated intake. Onboarding sets up the site’s telemetry credential where the transport allows it.

PS-OB-11

The site can measure what visitors experience in their browser (real user monitoring): page load and responsiveness, errors, and the browser side of a trace into the site and the portal. It is configurable per site, sampled, and subject to the visitor’s consent where the law requires it.