DengueOps AI

This table distinguishes the current implementation status of DengueOps AI’s deployed interface, analytical workflows, output model, and planned validation capabilities. Deployment status does not by itself establish methodological or operational readiness.

DengueOps AI is an experimental decision-support platform for dengue forecasting and dataset assessment. It is designed to help examine whether uploaded dengue and climate data are structurally suitable for forecasting, apply a controlled forecasting workflow, and translate model outputs into planning-oriented fields. DengueOps AI has a deployed web interface, while its forecasting methodology, model-selection workflow, planning outputs, and operational use remain experimental and require further validation.

The platform separates two different analytical tasks. Quick Forecast is intended for controlled forecast generation using the currently configured demonstration pipeline. Assess Dataset is intended for deeper evaluation of an uploaded historical dataset, including temporal-quality assessment, time-aware model comparison, and dataset-specific model recommendation.

DengueOps AI is not a clinical system, diagnostic tool, or authoritative outbreak-warning platform. Its outputs are conditional analytical signals that depend on the quality, continuity, coverage, and relevance of the uploaded data. Final interpretation requires public-health and epidemiological judgment.

Dengue forecasting is not only a model-training problem. A forecasting workflow can produce misleading results when the underlying dataset is incomplete, temporally inconsistent, too short, poorly labeled, or evaluated using methods that ignore chronological order.

Common weaknesses in forecasting prototypes include random train-test splitting, insufficient comparison with baseline models, overreliance on a single algorithm, hidden data assumptions, and presentation of experimental scores as if they were validated public-health probabilities.

DengueOps AI was designed around the principle that forecast generation and dataset assessment are related but distinct responsibilities. A user seeking a rapid forecast does not necessarily require full model benchmarking, while a user evaluating a historical dataset requires stronger evidence before selecting a forecasting approach.

The platform therefore separates fast operational experimentation from deeper evidence-oriented model assessment.

• Insufficient historical observations
• Missing or duplicate time periods
• Inconsistent target and climate variables
• Random splitting of time-series data
• Treating one model as universally optimal
• Weak comparison with baseline forecasts
• Unclear separation between prediction and planning interpretation
• Overconfident use of unvalidated risk terminology
• Limited visibility of assumptions and limitations

• Validate the schema and temporal structure of uploaded dengue and climate datasets.
• Distinguish rapid forecast generation from deeper dataset and model assessment.
• Support time-aware forecasting evaluation rather than random data splitting.
• Produce interpretable planning-oriented outputs instead of presenting prototype scores as clinical risk probabilities.
• Make assumptions, evidence, limitations, and model maturity visible.
• Support dataset-specific model reasoning rather than assuming one algorithm is permanently optimal.
• Preserve compatibility with legacy API fields while moving toward a clearer canonical output model.
• Encourage reproducible and reviewable forecasting workflows.

The platform begins with dataset validation because a model result is only meaningful when the uploaded data meet basic structural and temporal requirements. After validation, the user selects either Quick Forecast or Assess Dataset.

Quick Forecast prioritizes a controlled forecast workflow using the currently configured demonstration model. Assess Dataset prioritizes evidence generation by evaluating the uploaded dataset and comparing approved candidate models through time-aware validation.

Both workflows are intended to end with transparent outputs, visible assumptions, and clear interpretation boundaries.

Quick Forecast is the controlled forecasting path. It is intended for users who want to validate an uploaded dataset, run the currently configured demonstration pipeline, and receive planning-oriented forecast outputs without performing a complete model-selection exercise.

1. 01.

   Dataset upload

   The user provides dengue and climate data in the expected structured format.

2. 02.

   Schema validation

   The system checks whether required columns, target fields, dates, and supported data types are available.

3. 03.

   Temporal validation

   The workflow checks chronological ordering, duplicate periods, missing periods, and whether the data provide sufficient temporal structure for processing.

4. 04.

   Data preparation

   The approved preprocessing and feature-preparation steps are applied using the configured prototype workflow.

5. 05.

   Demonstration model execution

   The currently configured Random Forest demonstration model is trained or executed according to the supported workflow.

6. 06.

   Forecast generation

   The platform generates experimental forecast outputs based on the uploaded data and the configured forecasting process.

7. 07.

   Planning-output generation

   Forecast outputs are translated into the canonical planning fields used by the platform.

8. 08.

   Interpretation and limitations

   The user is shown planning suggestions together with relevant assumptions, limitations, and warnings about data and model maturity.

Quick Forecast does not determine whether Random Forest is the best model for the uploaded dataset. It uses the currently configured demonstration approach to provide a controlled and repeatable prototype workflow.

The quality of its results depends on the uploaded dataset, including temporal coverage, reporting consistency, missingness, target definition, and the availability of relevant explanatory variables.

Assess Dataset is the evidence-oriented workflow. It is intended for users who have labeled historical data and want to determine whether the dataset is suitable for forecasting and which approved forecasting approach performs most appropriately for that particular dataset.

1. 01.

   Historical-label verification

   Confirm that the uploaded dataset contains a defined forecasting target and sufficient labeled historical observations.

2. 02.

   Schema and completeness assessment

   Evaluate required fields, data types, missing values, duplicate records, and field consistency.

3. 03.

   Temporal continuity assessment

   Inspect chronological coverage, missing periods, irregular intervals, reporting gaps, and possible structural breaks.

4. 04.

   Predictor and target review

   Check whether the target variable and available predictors are appropriate for the intended forecasting task.

5. 05.

   Time-aware validation setup

   Create chronological training and validation periods that preserve temporal order.

6. 06.

   Candidate-model evaluation

   Compare approved forecasting approaches using a consistent time-aware evaluation process.

7. 07.

   Metric and baseline comparison

   Evaluate model performance against suitable baseline forecasts and relevant forecasting metrics.

8. 08.

   Dataset-specific recommendation

   Recommend an approach for the uploaded dataset based on validation evidence, stability, forecast horizon, interpretability, and data characteristics.

9. 09.

   Evidence and limitation report

   Present the recommendation together with assumptions, metric evidence, data limitations, and interpretation boundaries.

A model recommendation from Assess Dataset is specific to the uploaded dataset and evaluation design. It does not establish permanent superiority across different time periods, geographic areas, surveillance systems, or future datasets.

Random train-test splitting must not be used as the main evaluation method for chronological forecasting data.

DengueOps AI uses a planning-oriented output model intended to separate analytical forecast behavior from operational interpretation. The canonical fields should lead the user interface, API documentation, and case-study explanation.

• forecast_growth_category: A categorical interpretation of the forecasted direction or level of expected case growth. It is intended to summarize forecast behavior without representing a validated clinical or epidemiological probability.
• experimental_growth_score: An experimental analytical score derived from the configured forecasting workflow. It supports relative interpretation within the prototype and must not be presented as a formally calibrated probability.
• planning_priority_tier: A planning-oriented category intended to help organize attention or review priority. It is not an emergency classification and should be interpreted together with the underlying forecast evidence and limitations.
• planning_suggestions: Contextual planning suggestions generated from the analytical outputs. These suggestions support review and discussion but do not replace epidemiological assessment, programme protocols, or public-health authority decisions.

These fields are intended to make the distinction between model output and planning interpretation explicit. Their definitions, thresholds, and operational use require further validation before any unrestricted real-world deployment.

Earlier versions of the platform or API may expose the fields risk_level, risk_score, and recommendations. These names are retained only for compatibility with earlier application logic and should not be treated as the authoritative output model.

• risk_level
• risk_score
• recommendations

The legacy field names create ambiguity because they can imply validated public-health risk estimation even when the underlying outputs are experimental planning signals. They should therefore be treated as technical debt.

A future API migration should use one or more of the following approaches:

• Mark the legacy fields as deprecated.
• Move them into a clearly labeled compatibility object.
• Introduce a versioned response schema.
• Map them explicitly to the canonical planning fields.
• Remove them after dependent clients have migrated safely.

The canonical fields forecast_growth_category, experimental_growth_score, planning_priority_tier, and planning_suggestions should lead future interface and API development.

Random Forest is the currently configured synthetic demonstration model used in the prototype forecasting workflow. Its inclusion allows the application to demonstrate data preparation, model execution, forecast generation, and planning-output construction.

Random Forest must not be interpreted as the universally best dengue forecasting model. Its suitability depends on the structure, size, temporal coverage, feature set, forecast horizon, and reporting characteristics of a specific dataset.

The longer-term model strategy is dataset-specific. Assess Dataset is intended to compare approved candidate approaches using chronological validation, relevant baseline forecasts, consistent metrics, and transparent evidence.

Model-selection considerations:

• Dataset size and historical depth
• Temporal continuity
• Forecast horizon
• Seasonal structure
• Availability of climate or contextual predictors
• Baseline performance
• Validation stability
• Interpretability
• Computational requirements
• Sensitivity to data drift

A model that performs well for one uploaded dataset may perform poorly for another. Model selection should therefore be presented as an evidence-based recommendation for a specific dataset, not as a permanent platform-wide declaration.

DengueOps AI is intended to follow validation practices appropriate for time-series forecasting. These principles are important because chronological forecasting cannot be evaluated reliably when future observations are allowed to influence model training.

• Preserve chronological ordering during training and validation.
• Use walk-forward or rolling-origin evaluation where appropriate.
• Compare candidate models with simple baseline forecasts.
• Prevent feature and target leakage.
• Evaluate performance at the intended forecast horizon.
• Report metrics consistently across compared models.
• Examine stability across multiple validation periods.
• Record preprocessing and feature assumptions.
• Make dataset limitations visible.
• Preserve reproducibility of the evaluation workflow.

These principles describe the intended validation standard of the platform. The case study must distinguish between principles that are already implemented and principles that remain part of the planned model-assessment roadmap. None of these validation principles are currently implemented in the codebase because DengueOps AI is presented as a planning case study and prototype. The principles remain part of the planned roadmap.

DengueOps AI produces experimental analytical and planning-support outputs. It does not diagnose disease, identify individual patients, or independently determine public-health actions.

• Forecasts are conditional on the quality and representativeness of historical data.
• Surveillance delays and underreporting can change observed patterns.
• Climate and dengue relationships may vary across locations and time periods.
• Prototype scores are not validated probabilities.
• Planning-priority tiers are not emergency classifications.
• Model outputs require epidemiological and operational interpretation.
• The platform should not independently trigger clinical, governmental, or emergency decisions.
• Recommendations should be reviewed against current surveillance evidence and institutional protocols.
• Performance can decline when data-generating conditions change.
• External validation is required before operational deployment.

The platform is designed to support structured analysis and discussion. Responsibility for real-world interpretation remains with qualified public-health professionals and relevant authorities.

The usefulness of DengueOps AI depends on the assumptions built into the uploaded dataset, preprocessing workflow, forecasting model, and planning-output interpretation.

• Uploaded datasets may contain reporting delays, missing periods, duplicates, or inconsistent definitions.
• Historical relationships may not remain stable under future epidemiological or environmental conditions.
• Climate variables alone may not explain dengue transmission patterns.
• Important factors such as mobility, vector-control activities, serotype changes, immunity, healthcare access, or local interventions may be unavailable.
• A model trained for one location may not transfer reliably to another.
• Forecast performance may vary across horizons.
• The current Random Forest workflow is a demonstration model rather than a universal benchmark winner.
• Planning-output thresholds require further validation.
• Legacy risk-oriented fields can create interpretation ambiguity.
• Prototype outputs have not been established as operational public-health probabilities.
• Independent and external validation is required before unrestricted deployment.

The current platform contains design and compatibility decisions that should be resolved before broader deployment.

• Legacy risk_level, risk_score, and recommendations fields
• Possible duplication between legacy and canonical output objects
• Need for explicit API versioning
• Need for clearer model-evidence reporting
• Need for stronger distinction between implemented and planned workflows
• Need for validated planning-output thresholds
• Need for forecast-uncertainty representation
• Need for dataset and model documentation cards
• Need for monitoring of data drift and concept drift
• Need for stronger external validation evidence

Technical debt should be addressed through controlled migration rather than abrupt removal. Existing clients should be identified, compatibility mappings documented, and deprecation communicated before legacy fields are removed.

• Complete the dataset-specific Assess Dataset workflow.
• Expand approved candidate-model comparison.
• Add consistent baseline forecasts.
• Add rolling-origin or walk-forward evidence reports.
• Introduce forecast intervals or uncertainty ranges where methodologically appropriate.
• Add dataset cards describing coverage, missingness, target definition, and limitations.
• Add model cards describing training data, validation method, metrics, assumptions, and intended use.
• Version the output API.
• Deprecate legacy risk fields safely.
• Add monitoring for data drift and concept drift.
• Strengthen reproducibility and experiment tracking.
• Conduct independent validation using real-world datasets.
• Review planning-output definitions with public-health specialists.
• Complete security, privacy, governance, and operational-readiness assessment before production deployment.