SOREADY™ · IN DETAIL
The platform, screen by screen.
Everything the homepage summarises lives here in full: the portal, its modules, and what each output format actually allows.
This page brings together what used to slow down a first pass on the homepage: the portal screens, the module-by-module detail, and the table of output formats and usage rights. Nothing has been removed from the site — only moved, for anyone who wants to go further than a first executive pass.
OPERATIONAL TRUTH · 20 SCREENS
The SoReady™ portal, at the depth of a world programme.
Screens reconstructed from the advanced functional model and the product demonstrators. The scenario deliberately mixes different disciplines to preserve anonymity. All values are fictional but consistent across screens.
This demonstration uses a composite scenario designed by LSE to represent the complexity of an international sports programme. The organisations, volumes and data shown do not describe any real client or event.
The functional journeys, governance rules and control mechanisms, however, correspond to capabilities actually studied or demonstrated in SoReady™. Integrations that require a third-party system or a contractual agreement are identified as such.
SOREADY™ · OPERATIONAL READINESS & KNOWLEDGE OS
From reference data to proof of opening.
SoReady™ is a modular software solution that drives the readiness of major projects and events. It connects requirements, data, planning, budget, risks, evidence and decisions, without replacing specialist systems. AI proposes, rules compute, the human decides — with full traceability.
- 01
Foundation
Reference data, identities, provenance and governance.
Foundation is the layer that gives every programme object a stable identity: a competition, a venue, a requirement or a document exists once, with a provenance and rights that stay attached wherever it is reused.
This is the base that keeps the other nine modules consistent with each other — without a shared reference layer, every module would redefine the same objects on its own.
The same discipline covers day-of signals, not only objects created upstream: every ingested signal keeps the authority and evidence it arrived with, instead of being folded into the record the moment it is accepted — the standard Fusion applies in real time to every live feed.
You always start from one version of each object, never nine different definitions depending on which module you open.
- 02
Bid
Feasibility, assumptions, variants and trajectory.
Before any commitment, Bid documents the feasibility assumptions — capacity, budget, schedule — and the variants considered, along with what tipped the decision from one option to another.
Those assumptions then stay linked to the programme’s actual trajectory: a gap between the original assumption and execution becomes visible, instead of getting lost after the bid decision.
Years later, you can still find why an assumption was made — not just what it was.
- 03
Event
Global readiness, dependencies and trade-offs.
Event aggregates programme-wide readiness from what the other modules already report — venues, disciplines, schedule, risk — instead of recalculating it separately.
When two priorities compete, the dependencies between modules are already visible, which makes the trade-off faster to make and easier to justify afterwards.
You see the programme’s readiness as a whole, not just the readiness of the last module you opened.
- 04
Federation
Sporting requirements, disciplines and validations.
Federation keeps each discipline’s own requirements — rules, field of play, resources — linked to their source and version, instead of scattered across several contacts.
Sporting validations stay logged separately from each competition’s Sport Risk Assessment, never merging the two registers.
These are the same requirements the product’s contextual assistance draws on — through the MCP layer described in Connect — to propose an answer grounded in the version actually in force, never in general knowledge.
You find a discipline’s exact requirement, its source and its validation status, in a single lookup.
- 05
Venue
Functional passport, interfaces and commissioning.
Venue holds a single functional passport per site — spaces, utilities, overlay, interfaces — replacing the disconnected checklists each venue would otherwise keep on its own.
That passport follows the site through to commissioning: tests, the gaps found and how they were resolved stay attached to the same record, all the way to handback.
You compare two venues on the same format, instead of reconciling checklists that don’t look alike.
- 06
Live
Signals, incidents and operational decisions.
Live receives day-of signals — sensors, reports from the ground, alerts — and normalises them before they reach a decision team, instead of broadcasting them raw.
Every incident stays linked to the decision that answered it, timestamped: a day of operations stays reviewable afterwards, not only while it’s happening.
After the event, you can retrace why a live decision was made — not just what it was.
- 07
Knowledge
Project memory, audit and legacy.
Knowledge keeps what the programme has learned — decisions, gaps, resolutions — instead of letting it disappear with the teams that move on once the event ends.
That memory stays available for an audit or for the programme’s next edition, in a structured form rather than scattered across separate reports.
You hand the next edition a usable legacy, not a pile of archives to reconstruct.
- 08
Connect
Controlled connectors and MCP protocols.
Connect governs every connection to a specialist system — federation, ticketing, security — through a controlled protocol (MCP) rather than direct, untracked access to source data.
Each connector keeps its own authorisation, scope and traceability: SoReady™ never replaces the specialist system, it governs access to it.
MCP is an open standard, not a proprietary protocol: the same connector stays usable whichever AI engine sits on top of it, including the local agents of on-premise engines.
For every piece of data on screen, you know which connector brought it in and under what authorisation.
- 09
Insights
Rules, assisted AI and cross-analysis.
Insights applies deterministic rules first — the ones that can be computed with certainty — before bringing in AI assistance on what remains ambiguous.
When AI is used, it proposes an analysis; it never decides alone, and its output stays compared, logged and subject to a human decision before anything is applied.
You can always tell what a rule computed from what an AI merely proposed.
- 10
Fusion
Multi-source feed intake and deterministic event correlation.
Fusion is the boundary every incoming feed crosses before it can shape the programme’s live state — timing and results, environment, safety, access and crowd, mobility, venue systems, network health, logistics, media, operational communications. Each signal is durably preserved as evidence and validated before it counts for anything, instead of being trusted the moment it arrives; anything that fails validation is quarantined, never silently dropped.
What passes correlates deterministically first, combining independent axes into one faithful state of the event at the level actually requested — a cluster, a site, a single discipline — instead of one average that hides what is happening underneath it. AI may help explain a correlation; it never triggers one on its own.
You read one coherent state of the event across every operational axis, always traceable back to the signals it came from — never a black-box summary.
DEMONSTRABLE READINESS
Eight gates. No magic percentage.
- 1Identified
- 2Defined
- 3Funded
- 4Contracted
- 5Designed
- 6Delivered
- 7Tested
- 8Accepted
FEEDS, FORMATS & RIGHTS
A readable format is not a right of use.
The functional scope is visible immediately, without naming a supplier. Each source keeps its authority, its contractual conditions and its licence.
| Function | Formats | Rights | SoReady™ usage |
|---|---|---|---|
| Documents & requirements | PDF · office documents · structured data | Open, contractual or protected | Extraction, version, provenance |
| Spatial data | GeoJSON · geographic APIs · GIS exports | Open standards; data may be licensed | Zones, capacities, proximities |
| Planning & resources | CSV · calendars · project APIs | Contractual or internal | Milestones, shifts, dependencies |
| Sporting data | Structured messages · files · API | Often under rights or contract | Schedule, participants, information |
| Results & timing | Official structured feeds | Managed rights, restricted access | Information and correlation only |
| Live signals | Webhooks · messages · API | Contractual, sometimes personal/sensitive | Incidents, alerts, operational status |
Hard limit: any visualisation or result data remains informative only. Only results, rankings and protocols officially issued or validated by the competent sporting authority are authoritative.
Let’s take action: your programme.
We take a real case from your programme and rebuild, with you, the impact chain it reveals.
Test a real case