Backend/Data Engineer for Football Analytics POC - phase 2

# REFMONITOR ## PHASE 2 — PROFESSIONAL REFEREE DATABASE + SIMULATION LAYER ### Product **RefMonitor — The Intelligence Layer for Football Officiating** --- # 1. PROJECT OVERVIEW RefMonitor is an existing football intelligence MVP focused on predicting and analysing the impact of referees and officiating environments on football matches. Phase 2 expands the existing product by creating a structured: **Professional Referee Database + Referee Simulation Layer** This is an additive development phase. The existing RefMonitor application should **not be rebuilt or redesigned**. The objective is to preserve the existing MVP while introducing the backend architecture required to: * maintain professional referee profiles * maintain historical referee data * track current and historical referee classifications * support fixtures before a referee is officially appointed * simulate multiple possible referees against the same fixture * calculate how sensitive a match is to referee selection * preserve every prediction version * recalculate predictions once the official referee is confirmed * prepare the architecture for later prediction intelligence, automation and AI layers --- # 2. CORE DEVELOPMENT PRINCIPLE Extend the existing RefMonitor MVP. Preserve the current: * frontend * routes * components * authentication * deployment structure * existing prediction logic * existing prediction behaviour unless a requirement in this brief genuinely requires a small modification. Phase 2 should primarily be a backend, database and intelligence-layer expansion. Avoid unnecessary: * frontend redesign * new frameworks * machine-learning infrastructure * complex microservices * large CMS/admin systems * unrelated refactoring * AI/LLM implementation The existing MVP must continue functioning throughout the development. --- # 3. WHY THIS UPDATE IS REQUIRED RefMonitor was initially designed around a relatively small group of established Premier League referees. That assumption is no longer sufficient. For the 2026/27 season, the professional refereeing structure has changed and the previous Select Group 1 / Select Group 2 structure is no longer the correct model for current referee coverage. RefMonitor therefore needs to support a broader: **Professional Referee Database** The public-facing product may remain primarily Premier League focused. Internally, however, RefMonitor needs to track the wider professional referee pipeline. This allows the system to build behavioural history on emerging officials before they become established Premier League referees. --- # 4. CURRENT PROFESSIONAL REFEREE STRUCTURE The referee architecture should no longer assume: one referee group = one competition The professional structure now allows referees to operate across multiple competitions during the same season. The database should therefore support professional groups such as: * Professional Referee Group * National Group * Women's Pro Game Group * future or development classifications where required RefMonitor should also retain its own internal classifications. These may include: ### Internal tier * Elite * Core * Emerging * Development ### Premier League status * Established * Emerging * Occasional * No PL Appointment Yet These should be clearly treated as **RefMonitor classifications**, rather than official governing-body classifications. --- # 5. GOVERNING BODY HISTORY Historical organisational information must not be overwritten. Historical records may belong to the previous: **PGMOL** structure, while current records may reference: **Pro Ref** The database should therefore support: * governing_body * governing body history * effective dates The governing-body name should not be hardcoded across the application. It should be stored as data so future organisational changes can be handled without widespread code changes. --- # 6. REFEREE TAXONOMY VERSIONING The classification structure itself should be versioned. Example: ### taxonomy_v1 Historical Select Group 1 / Select Group 2 structure. ### taxonomy_v2 2026/27 Professional Referee Group structure. Historical referee records must retain the classification that applied at the time. For example, a referee who operated under Select Group 2 in an earlier season should not have those historical records silently relabelled under the current Professional Referee Group structure. --- # 7. REFEREE STATUS HISTORY Create a lightweight referee status-history structure. Suggested fields: * referee_status_history_id * referee_id * governing_body * professional_group * tier * PL_status * taxonomy_version * effective_from * effective_to * source * date_created This should allow RefMonitor to determine: What classification did this referee have when a historical match was officiated? rather than only storing the referee's present-day status. --- # 8. CORE REFEREE DATABASE Create or upgrade the referee database so every referee has a stable RefMonitor identity. Suggested fields include: * refmonitor_referee_id * name * active_status * governing_body * professional_group * tier * PL_status * competitions_current_season * first_PL_season * total_PL_matches * current_season * available_for_future_fixture_assignment * historical_data_retained * date_created * date_updated The exact schema can be adapted to the existing application where appropriate. --- # 9. PROVIDER-INDEPENDENT INTERNAL IDs RefMonitor should own its internal referee identities. External provider IDs should **not** become the primary database identity. Use an internal: `refmonitor_referee_id` External IDs can then map to that referee. Examples: * sportmonks_referee_id * api_football_referee_id * other_provider_referee_id The same principle should be used for fixtures where practical. This ensures that changing or combining data providers later does not require rebuilding the core database. --- # 10. REFEREE STATUS FIELDS The following concepts must remain separate. ### active_status Suggested values: * Active * Inactive * Retired ### professional_group Current professional organisational grouping. ### tier RefMonitor's internal assessment. Suggested values: * Elite * Core * Emerging * Development ### PL_status RefMonitor's Premier League status classification. Suggested values: * Established * Emerging * Occasional * No PL Appointment Yet A referee may therefore simultaneously be: **Active** **Professional Referee Group** **Emerging** **Occasional PL** These fields represent different concepts and should not be collapsed. --- # 11. RETIRED REFEREES Retired referees must remain in the database. They must not be deleted simply because they are no longer eligible for future appointments. Example state: * active_status = Retired * available_for_future_fixture_assignment = false * historical_data_retained = true Historical data should remain connected to: * fixtures * predictions * cards * penalties * fouls * referee metrics * model validation * historical analysis Retired referee records remain valuable to RefMonitor. --- # 12. COMPETITION HISTORY Do not assume every referee has five seasons of Premier League history. Historical referee data may come from: * Premier League * Championship * League One * League Two * domestic cups * other relevant professional competitions depending on the referee's career. Every historical dataset must retain its: * competition * season * source Competition identities must remain distinct. Do not merge all referee history into a single average without retaining where the underlying matches came from. --- # 13. REFEREE-SEASON DATA Create structured referee-season records. Suggested fields include: * referee_id * season * competition * appearances * yellow_cards * red_cards * penalties_awarded * fouls_called where available * cards_per_match * penalties_per_match * source * source_reference * data_quality * historical_depth * date_imported Additional fields may be included where reliable source data supports them. --- # 14. RAW DATA VS REFMONITOR DERIVED DATA Maintain a clear separation between: ## Raw / imported football data Examples: * referee * fixture * competition * cards * red cards * penalties * fouls * season and: ## RefMonitor derived intelligence Examples: * Referee Sensitivity Score * data confidence * future Strictness Score * future Chaos Index components * prediction outputs The raw historical data should remain intact even if RefMonitor later changes its scoring methodology. Derived metrics should be recalculable from the original source data. --- # 15. DATA PROVENANCE Imported data must include clear provenance. Suggested fields: * source_name * source_type * external_id * source_reference * retrieval_date * import_method * verification_status Suggested source types: * API * OFFICIAL * MANUAL * DERIVED RefMonitor should be able to determine where a historical statistic or record originated. --- # 16. HISTORICAL DATA QUALITY Missing historical data must never be replaced with invented values. Instead, record the depth and quality of the available evidence. A simple data-depth classification may initially be used. Example: * A — Strong * B — Good * C — Limited * D — Emerging These labels and thresholds should remain configurable. --- # 17. REFEREE DATA CONFIDENCE Phase 2 should include a lightweight way to represent the quality and completeness of each referee's available dataset. This is different from the more advanced **Prediction Confidence** model intended for a later prediction-intelligence phase. Possible inputs include: * match volume * data recency * competition relevance * historical depth Any starting weights used should be: * configurable * documented * stored as configuration * versioned where appropriate They must not be hardcoded as permanent RefMonitor methodology. The objective is simply to prevent a referee with two relevant matches from appearing equally data-rich as a referee with more than 100. --- # 18. DATA PROVIDER REQUIREMENTS The implementation should support an approved football-data provider rather than making the architecture dependent on one specific provider forever. Potential provider coverage should support, where available: * Premier League * Championship * League One * League Two * referee identities * referee assignments * fixtures * seasons * yellow cards * red cards * penalties * fouls * external referee IDs * external fixture IDs * competition filtering * season filtering * historical records The database architecture must remain provider-independent. If external provider taxonomy does not reflect RefMonitor's required professional referee structure, RefMonitor should maintain its own internal classification. --- # 19. DATA LICENSING AND RIGHTS The system must distinguish between: * licensed provider data * official/public source data * manually compiled data * RefMonitor-derived analytics RefMonitor's proprietary intelligence should remain clearly separated from third-party raw data. Imported data should only be used in accordance with the applicable provider licence and usage rights. --- # 20. DATA IMPORT Historical data may be ingested through: * API import * CSV import * seed scripts * controlled manual import where necessary The import process should include: * schema validation * duplicate detection * internal ID matching * provider ID mapping * error handling * import logging * verification status Malformed data should not be silently added to the database. --- # 21. PROFESSIONAL REFEREE POOL The database should support the relevant current professional referee pool under the 2026/27 structure. The architecture must not assume every referee in the database will regularly officiate Premier League fixtures. That is why the database separately maintains: * professional_group * competitions_current_season * PL_status * tier * availability One purpose of the wider database is to allow RefMonitor to follow referees before they become established Premier League officials. --- # 22. FIXTURE ARCHITECTURE Phase 2 must support all: **380 Premier League fixtures per season** Suggested fixture fields include: * refmonitor_fixture_id * external_fixture_id * season * competition * home_team * away_team * fixture_date * kick_off_time * fixture_status * confirmed_referee_id * referee_confirmation_status * current_prediction_version * date_created * date_updated The exact implementation can be adapted to the existing data model. --- # 23. FIXTURES WITHOUT AN APPOINTED REFEREE This is a core requirement. A fixture must be valid even when the referee has not yet been announced. Therefore: `confirmed_referee_id` must support a null/unassigned state. Conceptually: `confirmed_referee_id = NULL` An unassigned referee is **not an error condition**. The existing prediction system must continue functioning before a referee appointment is known. --- # 24. FIXTURE CHANGES Fixtures may be modified after they are initially created. The architecture should safely support: * date changes * kick-off changes * postponements * rescheduling * cancellation where applicable Changes to fixture scheduling must not destroy linked prediction history. --- # 25. REFEREE ELIGIBILITY Do not simulate every referee in the database against every Premier League fixture. The candidate simulation pool should be filtered. At minimum consider: * active status * assignment availability * professional group * competition eligibility * current-season activity * retired status Only credible eligible referees should enter a Premier League fixture simulation. Future phases may add **assignment probability**. Phase 2 only requires an appropriate eligible candidate pool. --- # 26. REFEREE SIMULATION ENGINE This is the central Phase 2 functionality. Before a referee is officially appointed, the system must be capable of simulating the fixture under multiple eligible referee scenarios. Flow: 1. Retrieve fixture. 2. Retrieve eligible referee pool. 3. Run the existing RefMonitor prediction logic against each eligible referee. 4. Generate a separate scenario for every referee. 5. Store each scenario independently. 6. Preserve the original baseline prediction. 7. Allow scenarios to be retrieved and compared. Conceptually: **Fixture** ↓ **Baseline Prediction** ↓ **Referee A Scenario** **Referee B Scenario** **Referee C Scenario** **Referee D Scenario** etc. --- # 27. SIMULATION STORAGE Every referee scenario must be stored independently. A useful unique relationship may contain: * fixture * referee * model version * configuration version Each scenario should contain enough information to identify: * fixture * referee * generation timestamp * prediction outputs * prediction type * model version * configuration version * relevant data confidence * component inputs required for later explanation Scenarios must never overwrite each other. --- # 28. DETERMINISTIC PREDICTIONS Phase 2 simulations should be deterministic. Given the same: * fixture * referee * input data * model version * configuration version the system should produce the same result. Avoid unnecessary randomness. This is important for: * testing * model validation * debugging * reproducibility * historical auditing --- # 29. REFEREE SENSITIVITY SCORE Phase 2 should introduce: **Referee Sensitivity Score** This measures how much a match's predicted officiating environment changes depending on which referee is appointed. Suggested scale: **0–10** Possible interpretation bands: * 0–2.9 — Low * 3–5.9 — Moderate * 6–7.9 — High * 8–10 — Very High These bands should remain configurable. --- # 30. SENSITIVITY INPUTS The initial sensitivity calculation may analyse variation across existing RefMonitor outputs such as: * Chaos Index * expected cards/card environment * penalty risk * VAR risk The purpose is to answer: **How much does referee selection matter for this particular fixture?** If provisional weights are required, they must be: * configurable * stored centrally * documented * versioned They should be treated as starting implementation values rather than permanent methodology. The component values used to calculate the sensitivity score must also be stored. --- # 31. STRICTNESS DATA Phase 2 should collect and structure the raw referee information necessary to support a future: **Referee Strictness Score** However, the definitive Strictness methodology does not need to be fully developed during this phase. Potential underlying data may include: * yellow-card rate * red-card rate * penalties * fouls * recent behaviour * competition context If a Strictness calculation already exists in the MVP, preserve it. Any temporary refinements required for Phase 2 should remain configurable. --- # 32. RECENCY SUPPORT Historical seasons must remain separately identifiable. The data model should support future recency weighting. For example, later RefMonitor versions may choose to give greater relevance to: * current season * previous season * older seasons progressively less The definitive weighting formula does not need to be fixed during Phase 2. If provisional weighting is required by the existing prediction system, it should be configuration-driven and versioned. --- # 33. COMPETITION WEIGHTING SUPPORT Premier League, Championship and lower-league data must retain distinct competition identities. The database should support future competition-specific weighting. Phase 2 should not permanently assume that one competition automatically has an arbitrary fixed percentage of the relevance of another. The architecture should make later competition weighting possible without restructuring historical data. --- # 34. PREDICTION VERSIONING Predictions must never be silently overwritten. At minimum the system should support: ### V1 — Baseline / Pre-Referee Prediction Generated before the official referee is known. ### V2 — Referee Simulation Scenarios Multiple referee-specific scenarios generated against the same fixture. ### V3 — Confirmed-Referee Prediction Generated once the official referee is entered. Future prediction states should also be possible. --- # 35. PREDICTION VERSION DATA Suggested prediction metadata includes: * prediction_version_id * fixture_id * referee_id * prediction_type * generated_at * trigger * model_version * configuration_version * prediction_outputs * data_confidence * is_current * superseded_by The exact schema can fit the existing application. The important requirement is that RefMonitor maintains permanent: **Prediction provenance** --- # 36. MODEL VERSIONING Every prediction should identify which version of RefMonitor's prediction methodology generated it. Example: `rm_prediction_v1` Future: `rm_prediction_v2` A historical prediction created using an older model must not be silently recalculated using the latest methodology and then displayed as if it were the original prediction. --- # 37. CONFIGURATION VERSIONING Variable calculation settings should also be versioned. Examples include: * sensitivity thresholds * provisional scoring weights * relevant competition rules * calculation configuration This means a prediction should be reproducible using: * its historical source data * model version * configuration version --- # 38. MANUAL REFEREE CONFIRMATION Phase 2 should provide a simple manual/admin workflow for confirming the referee once an official appointment is known. Required flow: 1. Select fixture. 2. Select confirmed referee. 3. Record appointment source where appropriate. 4. Mark referee as confirmed. 5. Trigger prediction recalculation. 6. Generate a new confirmed-referee prediction version. 7. Preserve all previous simulations. 8. Make the confirmed-referee prediction the current prediction. Automatic appointment detection will be handled by a later automation phase. --- # 39. REFEREE APPOINTMENT CHANGES Official referee assignments may occasionally change. A corrected or replacement appointment must not destroy the previous prediction history. The system should preserve: * previous referee * previous prediction * timestamp * source/reason where available and create a new current prediction. This will also support future automated appointment monitoring. --- # 40. BASIC EXPLAINABILITY DATA Phase 2 does not require an AI explanation interface. However, predictions should store enough component-level data to determine **why** a prediction changed. Example: If expected card intensity increases after referee confirmation, the system should retain the underlying figures that explain the change. This structured explainability data will later support: * prediction intelligence * automated content * AI explanations --- # 41. ACTUAL MATCH RESULT STORAGE Completed fixtures should store the actual disciplinary information required for future model validation. Where supported, this should include: * actual yellow cards * actual red cards * penalties awarded * relevant VAR events * other relevant disciplinary outputs A full analytics dashboard is not required in Phase 2. The objective is to ensure the historical validation data exists. --- # 42. PREDICTION PROVENANCE RefMonitor should be capable of determining: * what was predicted * when it was predicted * whether the referee was known * which referee scenario was used * which model version generated it * which configuration generated it * what changed after referee confirmation * what actually occurred in the match This is important for future: * accuracy measurement * backtesting * product credibility * historical validation * content * investor evidence --- # 43. PERFORMANCE The architecture should support approximately: *380 Premier League fixtures × the eligible referee pool** without requiring a single long-running blocking web request. A full matchweek of referee simulations should also be processed reliably. Appropriate techniques may include: * batching * queued processing * background jobs * scheduled processing where needed. Use the simplest reliable implementation appropriate to the existing stack. Do not over-engineer the solution. --- # 44. LIGHTWEIGHT ADMIN FUNCTIONALITY Phase 2 only requires enough internal functionality to manage and verify the new referee layer. Admin functionality should allow appropriate users to: * inspect referee profiles * update referee status * inspect historical records * correct classifications * import historical data * inspect fixtures * manually confirm referee appointments * trigger recalculation * inspect simulation scenarios * inspect prediction versions A large custom CMS is not required. --- # 45. ERROR HANDLING The system should handle common failures gracefully. ### Data source unavailable * retain the last known valid data * log the failure * do not fabricate replacement information ### Historical data incomplete * store available validated data * reduce data-confidence level * identify missing fields where practical ### Duplicate referee detected * attempt internal/provider ID matching * prevent duplicate creation where confident * flag ambiguous records for review ### Individual simulation failure * record the error * preserve successful scenarios for other referees * do not discard the complete simulation batch ### No confirmed referee This must not be treated as an application error. Unassigned fixtures are a core supported state. --- # 46. LOGGING Relevant system activity should be logged. Examples: * data imports * failed imports * referee record updates * duplicate detection * fixture updates * simulation runs * simulation failures * referee confirmations * prediction creation * prediction supersession * relevant administrative changes Sensitive credentials and API secrets must never be written to logs. --- # 47. DATA SECURITY Appropriate application security must be maintained. At minimum: * API keys must remain server-side * credentials must be stored through environment configuration * administrative functions must require appropriate authentication/authorisation * sensitive configuration must not be exposed through the frontend * database changes must follow the existing security model Phase 2 should not weaken existing authentication or access-control behaviour. --- # 48. OWNERSHIP AND PORTABILITY The architecture should remain portable and maintainable. The project should not rely on: * proprietary developer-owned infrastructure * personal developer accounts * inaccessible external services * undocumented manual processes The application should remain transferable to another competent developer. The project assets include: * source code * repository * database * deployment configuration * environment configuration * API configuration * RefMonitor data * RefMonitor-derived analytics * technical documentation --- # 49. TECHNICAL HANDOVER REQUIREMENTS Phase 2 should include updated technical documentation covering relevant changes. At minimum: * README updates * local setup * database/schema changes * migrations * environment variables * API/provider configuration * data-import procedure * referee mapping logic * simulation process * prediction-version structure * model/configuration versioning * manual referee-confirmation workflow * known limitations * troubleshooting notes The project should be understandable by another competent developer without needing to reverse-engineer the implementation. --- # 50. OUT OF SCOPE — LATER PREDICTION INTELLIGENCE The following are intentionally outside the main scope of Phase 2: * advanced referee behavioural modelling * definitive Strictness Score methodology * advanced recency weighting * definitive competition weighting * referee assignment probability * probability-weighted pre-appointment forecasts * advanced team × referee models * final prediction-confidence methodology * advanced match-context analysis The Phase 2 database should make these possible later. --- # 51. OUT OF SCOPE — AUTOMATION Phase 2 does not require: * automatic referee appointment monitoring * scheduled appointment polling * appointment webhooks * automatic alerts * automated social content * social publishing * content approval workflows Phase 2 only requires manual confirmed-referee assignment and recalculation. --- # 52. OUT OF SCOPE — AI Phase 2 does not require: * LLM integration * conversational assistant * natural-language querying * AI referee explanations * AI-generated prediction analysis * AI-generated social content The database and prediction architecture should simply retain the structured information required to support such functionality later. --- # 53. OTHER OUT-OF-SCOPE ITEMS Also excluded unless specifically necessary for Phase 2: * major frontend redesign * machine learning * unnecessary framework migration * enterprise-scale infrastructure * complex microservices * large admin CMS * full WSL/WSL2 product implementation Future competition support may be accommodated through clean schema design without building those products now. --- # 54. ACCEPTANCE CRITERIA — REFEREE DATABASE Phase 2 should demonstrate that: * a referee can be created using the current professional taxonomy * referees have stable RefMonitor internal IDs * external provider IDs can map to those internal IDs * current referee classification can be stored * historical classifications can be stored separately * taxonomy versions are retained * historical referee classifications are not overwritten by current classifications * professional group, tier, status and competition coverage remain separate concepts --- # 55. ACCEPTANCE CRITERIA — HISTORICAL DATA The implementation should demonstrate that: * referee-season records retain their season * referee-season records retain their competition * imported records contain identifiable provenance * historical records can originate from different competitions * incomplete history reduces data confidence rather than generating invented values * malformed imports are rejected or flagged * duplicate referee records are prevented or flagged --- # 56. ACCEPTANCE CRITERIA — RETIRED REFEREES The implementation should demonstrate that: * a retired referee remains in the database * their historical fixtures remain queryable * their historical predictions remain queryable * their statistics remain available * they are excluded from future referee simulation pools --- # 57. ACCEPTANCE CRITERIA — FIXTURES The implementation should demonstrate that: * all Premier League fixtures can exist before referee appointment * `confirmed_referee_id` can remain unassigned/null * the existing prediction system does not fail because a referee is unknown * fixture rescheduling does not remove historical predictions * external fixture IDs can map to internal RefMonitor fixture IDs --- # 58. ACCEPTANCE CRITERIA — SIMULATION For a fixture without a confirmed referee: * an eligible referee pool can be generated * multiple referee scenarios can be calculated * every scenario is stored independently * the baseline prediction remains intact * scenarios do not overwrite each other * inactive referees are excluded * retired referees are excluded * non-eligible referees are excluded * the same inputs and versions reproduce the same output --- # 59. ACCEPTANCE CRITERIA — REFEREE SENSITIVITY The implementation should demonstrate that: * a Referee Sensitivity Score can be produced for a simulated fixture * the score measures variation between referee scenarios * the component inputs can be retrieved * thresholds are configurable * any initial weighting is configurable * methodology/version can be identified later --- # 60. ACCEPTANCE CRITERIA — PREDICTION VERSIONING The implementation should demonstrate the complete prediction lifecycle: ### Before appointment Baseline prediction exists. ### During simulation Multiple referee-specific scenarios exist. ### After confirmation A new confirmed-referee prediction exists. The system must preserve the entire chain. A confirmed prediction must not delete: * baseline prediction * other referee scenarios * previous confirmed versions if an appointment changes --- # 61. ACCEPTANCE CRITERIA — CONFIRMED REFEREE The implementation should demonstrate that an authorised user can: 1. open a fixture; 2. assign the official referee; 3. confirm the appointment; 4. trigger recalculation; 5. create a new prediction version; 6. retain every previous version; 7. mark the newest prediction as current. --- # 62. ACCEPTANCE CRITERIA — VALIDATION FOUNDATION For a completed fixture, the database should be capable of storing: * prediction values * actual match values * prediction timestamp * prediction version * model version * referee status at prediction time This should make future prediction-performance analysis possible without rebuilding the historical architecture. --- # 63. ACCEPTANCE CRITERIA — PERFORMANCE The system should demonstrate that: * a full matchweek can be simulated reliably * multiple referee scenarios can be processed without blocking the main application unnecessarily * individual scenario failures do not destroy successful calculations * the design remains capable of supporting a full Premier League season --- # 64. ACCEPTANCE CRITERIA — REGRESSION After completion: * existing RefMonitor routes should continue functioning * existing prediction behaviour should remain available * authentication should continue functioning * deployment should remain functional * no unnecessary frontend redesign should have been introduced * the existing MVP should remain usable --- # 65. PHASE 2 FINAL DELIVERABLE At completion, RefMonitor should have: **A provider-independent professional referee database with historical classification, competition-specific referee data, provenance and data-quality tracking; a Premier League fixture architecture that works before referee appointment; a deterministic multi-referee simulation engine; Referee Sensitivity scoring; permanent prediction versioning; and a manual confirmed-referee recalculation workflow.** This becomes the data and simulation foundation for the next stages of RefMonitor. --- # 66. FUTURE ARCHITECTURE Phase 2 should be built with the following long-term product structure in mind: ### Layer 1 — Football Data Fixtures, referees, teams, events and historical match data. ↓ ### Layer 2 — Professional Referee Database Historical profiles, classifications, competition records and referee behaviour data. ↓ ### Layer 3 — RefMonitor Prediction Intelligence Referee simulations, sensitivity, strictness, confidence, contextual modelling and proprietary metrics. ↓ ### Layer 4 — Automation Appointment monitoring, recalculation triggers, alerts and content workflows. ↓ ### Layer 5 — AI Natural-language querying, prediction explanation, referee comparisons, analysis and content assistance. Phase 2 is responsible for establishing **Layers 1–2 and the simulation foundation of Layer 3**. --- # 67. FINAL DEVELOPMENT PRINCIPLES The implementation should follow these principles throughout: **Preserve historical data.** **Never silently overwrite predictions.** **Keep RefMonitor's internal identities independent from external providers.** **Keep raw data separate from RefMonitor-derived intelligence.** **Preserve competition context.** **Do not fabricate missing historical data.** **Make calculations reproducible.** **Version models and important configuration.** **Store enough component data for future explainability.** **Keep the architecture scalable without over-engineering.** **Preserve the existing MVP wherever possible.** The central Phase 2 objective is: **Build the referee intelligence infrastructure that allows RefMonitor to understand how a fixture could change depending on the referee before that referee is officially known.**