Open research Research only

Weather-JEPA North-Star Project Management Plan

Document status: Governing project plan
Version: 1.0
Date: July 26, 2026
Project: Weather-JEPA
License target: Apache License 2.0
Primary development platform: Apple M2 Mac Studio, 32 GB unified memory
Primary framework: PyTorch with Apple Metal Performance Shaders (MPS) support

1. Purpose of This Document

This document is the authoritative management, research, architecture, data, and engineering plan for Weather-JEPA. It is intended to prevent the project from becoming a collection of attractive notebooks, incomparable experiments, and retrospective explanations of decisions that were never actually documented.

Every major project artifact should trace to this plan:

The plan is a living document, but it is not casual documentation. Changes to a governing requirement must be recorded in the decision log, linked to evidence, and reflected in the version history. Convenience is not evidence. A result that appears promising is also not evidence that the protocol should be rewritten around it.

Part I — Mission, Scope, and Governance

2. Mission

Weather-JEPA will investigate whether reconstruction-free joint-embedding predictive learning can produce transferable, dynamically useful, uncertainty-aware representations of the atmosphere under accessible computational constraints.

The project’s ultimate purpose is to contribute knowledge that may improve the anticipation and characterization of hazardous weather and thereby support forecasting systems that protect human life.

Weather-JEPA is not an operational warning system. It will not issue public forecasts, emergency instructions, evacuation guidance, or claims of operational readiness. Its contribution is upstream: reproducible evidence about atmospheric representation learning, forecast behavior, uncertainty, and failure.

3. Vision

Build an open, scientifically disciplined atmospheric world-model research platform that:

  1. learns multiscale representations of atmospheric states;
  2. compares JEPA learning fairly against direct forecasting and masked reconstruction;
  3. evaluates both ordinary forecast skill and hazard-relevant behavior;
  4. exposes uncertainty and failure rather than decorating deterministic output with confidence language;
  5. runs meaningful experiments on prosumer hardware;
  6. publishes code, configurations, negative results, and methodological limitations;
  7. remains useful as an educational resource and a foundation for later research.

4. Governing Principles

4.1 Protect Life, Do Not Perform Safety Theater

The public-safety goal governs model evaluation, documentation, and claims. It does not authorize exaggeration. A global RMSE reduction is not equivalent to a saved life. A useful research result must be connected carefully to the forecasting and warning chain.

4.2 Scientific Rigor Over Novelty

The project will not claim to be the first atmospheric world model, the first learned weather model, the first stochastic atmospheric model, or the first self-supervised weather model. Novelty must be stated narrowly and supported by a current literature review.

4.3 Compare Objectives, Not Bundles of Changes

The primary causal question concerns the learning objective. The supervised, masked-autoencoder, and JEPA systems must therefore share the same backbone, input data, output resolution, parameter budget, optimization budget, and evaluation protocol wherever technically possible.

Changing the backbone, data volume, augmentation, optimizer, and objective simultaneously may produce a good model. It does not produce a clean answer.

4.4 Reproducibility Is a Product Requirement

A result is incomplete until another person can identify:

4.5 Negative Results Are Deliverables

A JEPA objective that fails to outperform masked reconstruction under matched conditions is still a useful result. The project will not quietly remove failed experiments from the historical record.

4.6 Compute Limits Are Experimental Conditions

The M2 Mac Studio is not an embarrassing substitute for an institutional cluster. It defines a deliberate research regime: representation quality per unit of memory, data, energy, and training time.

4.7 No Operational Claims Without Operational Evidence

Weather-JEPA outputs must be labeled research-only until independently validated against appropriate observations, compared with operational baselines, tested prospectively, reviewed by domain experts, and deployed within an accountable warning institution.

5. Project Scope

5.1 In Scope

5.2 Out of Scope for Initial Releases

5.3 Deferred Scope

The following may enter only after formal phase-gate approval:

6. Research Questions

RQ1 — Representation Quality

Under matched architecture, data, parameter count, and optimization budget, does reconstruction-free JEPA pretraining produce atmospheric representations that transfer more effectively than supervised forecasting or masked reconstruction?

RQ2 — Forecast Skill

Does the JEPA representation improve deterministic forecast skill across variables, vertical levels, regions, spatial scales, and lead times?

RQ3 — Dynamical Stability

Do JEPA-trained latent states support more stable multistep rollouts than baseline representations, as measured by error growth, spectral drift, variance collapse, and decoded physical plausibility?

RQ4 — Robustness

Are JEPA representations more robust to missing variables, noisy inputs, masked regions, temporal gaps, seasonal shifts, and held-out extreme events?

RQ5 — Hazard Relevance

Do JEPA representations improve the detection, classification, tracking, intensity estimation, or uncertainty characterization of selected hazardous phenomena?

RQ6 — Compute Efficiency

What representation and forecast performance can be achieved per parameter, training hour, gigabyte of peak memory, and unit of processed data on prosumer hardware?

RQ7 — Probabilistic Utility

After deterministic stability is established, can a probabilistic latent predictor generate calibrated, spatially coherent alternative futures without smoothing high-impact possibilities into a convenient average?

7. Primary Hypotheses

Hypotheses may be rejected. The project is not obliged to protect them from data.

8. Governance and Decision Rights

8.1 Roles

For the current single-researcher phase, one person may hold multiple roles, but the responsibilities remain distinct.

Role Responsibility
Principal Investigator Scientific direction, claims, ethics, publication approval
Project Manager Milestones, scope, dependencies, risk register, release gates
Data Engineer Acquisition, validation, transformation, lineage, storage
ML Research Engineer Model implementation, training, evaluation
Software Engineer Packaging, testing, CI, releases, security
Reviewer Independent challenge of methods, metrics, and claims
Communications Lead Public documentation and educational content

8.2 Required Records

The repository will maintain:

8.3 Change Control

A change requires an ADR or RDR when it affects:

Each decision record must contain context, alternatives, evidence, decision, consequences, and reversal conditions.

Part II — Mathematical Specification

9. Atmospheric State Definition

Let the atmospheric state at time (t) be

[ \mathbf{X}_t \in \mathbb{R}^{C \times L \times H \times W}, ]

where:

Surface and static fields may be represented separately:

[ \mathbf{S}_t \in \mathbb{R}^{C_s \times H \times W}, \qquad \mathbf{B} \in \mathbb{R}^{C_b \times H \times W}. ]

A training sample contains a context window of (K) atmospheric states:

[ \mathcal{C}t = {\mathbf{X}{t-(K-1)\Delta t}, \ldots, \mathbf{X}_t}, ]

and one or more prediction horizons

[ \mathcal{H} = {h_1, h_2, \ldots, h_m}. ]

The initial temporal resolution is six hours, matching common global forecast evaluation practice and controlling dataset volume. Higher-frequency experiments require a separate decision record.

10. Normalization

For variable (c), level (l), and optionally calendar stratum (s), standardized values are

[ \widetilde{X}{t,c,l,i,j} = \frac{X{t,c,l,i,j} - \mu_{c,l,s}}{\sigma_{c,l,s}+\epsilon}. ]

The default is training-split-only climatological statistics. Validation or test data must never influence normalization parameters.

Alternative transforms may be required:

Every transformation must be invertible or explicitly documented as lossy.

11. Spatial Weighting

Global grid-cell area varies with latitude. Field losses and metrics will therefore use weights

[ w_i = \frac{\cos(\phi_i)}{\frac{1}{H}\sum_{k=1}^{H}\cos(\phi_k)}, ]

where (\phi_i) is latitude. Regional experiments may use uniform weighting or a documented area-preserving scheme.

12. Tokenization and Patching

The input state is partitioned into spatial or spatiotemporal patches. For patch size (P_h \times P_w), the number of horizontal tokens is

[ N = \frac{H}{P_h}\frac{W}{P_w}. ]

Vertical structure may be represented by one of three governed alternatives:

  1. Level-as-channel: simple and memory efficient, but weakly explicit;
  2. Level tokens: each variable-level patch becomes a token;
  3. Factorized vertical encoder: horizontal patching followed by vertical attention or mixing.

The initial reference architecture will use factorized vertical mixing because it balances physical explicitness and workstation memory.

13. Context Encoder

The context encoder maps visible atmospheric context to latent tokens:

[ \mathbf{Z}^{(c)}t = f{\theta}(M_c \odot \mathcal{C}_t, \mathbf{S}_t, \mathbf{B}, \mathbf{e}_t), ]

where:

14. Target Encoder

The target encoder maps uncorrupted or selectively masked target states to latent targets:

[ \mathbf{Z}^{(y)}{t+h} = f{\xi}(\mathbf{X}{t+h}, \mathbf{S}{t+h}, \mathbf{B}, \mathbf{e}_{t+h}). ]

Its parameters are updated by exponential moving average:

[ \xi \leftarrow \tau \xi + (1-\tau)\theta, ]

where (\tau) follows a governed schedule approaching one during training.

The target encoder does not receive gradients from the predictor loss.

15. JEPA Predictor

The predictor estimates target embeddings from context embeddings, mask tokens, and forecast-horizon conditioning:

[ \widehat{\mathbf{Z}}^{(y)}{t+h} = g{\psi}(\mathbf{Z}^{(c)}_t, M_y, \mathbf{q}_h), ]

where (M_y) identifies target blocks and (\mathbf{q}_h) encodes forecast horizon.

The predictor must support the following target families:

A target-family ablation is mandatory. “JEPA” is not a sufficiently precise experimental condition unless the masking and target geometry are specified.

16. Core JEPA Loss

For target token set (\mathcal{T}), the basic latent prediction loss is

[ \mathcal{L}{\text{JEPA}} = \frac{1}{|\mathcal{T}|} \sum{k \in \mathcal{T}} \left| \widehat{\mathbf{z}}_k - \operatorname{sg}(\mathbf{z}^{(y)}_k) \right|_p, ]

where (\operatorname{sg}) denotes stop-gradient and (p\in{1,2}) is selected by experiment.

Cosine distance may be evaluated:

[ \mathcal{L}_{\cos} = 1- \frac{\widehat{\mathbf{z}}_k^\top \mathbf{z}^{(y)}_k} {|\widehat{\mathbf{z}}_k|_2|\mathbf{z}^{(y)}_k|_2+\epsilon}. ]

17. Collapse Diagnostics and Regularization

Latent collapse must be measured, not assumed absent. Diagnostics include:

If necessary, the project may introduce variance and covariance terms:

[ \mathcal{L}{\text{var}} = \frac{1}{d}\sum{j=1}^{d}\max(0, \gamma-\sqrt{\operatorname{Var}(Z_j)+\epsilon}), ]

[ \mathcal{L}{\text{cov}} = \frac{1}{d}\sum{i\neq j}\operatorname{Cov}(Z)_{ij}^{2}. ]

The total loss becomes

[ \mathcal{L} = \lambda_J \mathcal{L}{\text{JEPA}} + \lambda_V \mathcal{L}{\text{var}} + \lambda_C \mathcal{L}{\text{cov}} + \lambda_P \mathcal{L}{\text{physical}}. ]

Regularizers may not be added merely because a training curve is unattractive. Their necessity must be demonstrated by diagnostics.

18. Supervised Forecasting Baseline

The supervised baseline predicts physical fields directly:

[ \widehat{\mathbf{X}}{t+h} = d{\omega}(f_{\theta}(\mathcal{C}_t), h). ]

A latitude-weighted normalized error may be used:

[ \mathcal{L}{\text{sup}} = \sum{c,l}\alpha_{c,l} \frac{\sum_{i,j} w_i (\widehat{X}{c,l,i,j}-X{c,l,i,j})^2} {\sum_{i,j}w_i}, ]

where (\alpha_{c,l}) prevents high-variance variables from dominating the objective.

19. Masked Autoencoder Baseline

The masked autoencoder predicts raw masked values:

[ \widehat{\mathbf{X}}{M} = d{\omega}(f_{\theta}(M_c\odot\mathbf{X})), ]

[ \mathcal{L}{\text{MAE}} = \frac{1}{|M_y|}\sum{k\in M_y} \left|\widehat{\mathbf{x}}_k-\mathbf{x}_k\right|_2^2. ]

Mask ratios and geometries must match the JEPA target protocol as closely as the objectives allow.

20. Multistep Rollout

Two rollout modes will be distinguished:

  1. Decoded autoregression: predicted physical fields are re-encoded;
  2. Latent autoregression: predicted latent states are advanced directly.

For latent transition operator (F_\psi):

[ \widehat{\mathbf{Z}}{t+(n+1)\Delta t} = F\psi(\widehat{\mathbf{Z}}{t+n\Delta t}, \mathbf{q}{\Delta t}). ]

Rollout evaluation must detect:

21. Probabilistic Extension

Probabilistic modeling is a later phase. The deterministic model must first demonstrate stable training and rollout.

Candidate formulations include:

A generic probabilistic predictor estimates

[ p_\psi(\mathbf{Z}{t+h}\mid\mathbf{Z}{\le t}, h). ]

A model will not be called probabilistic merely because dropout is enabled at inference.

22. Physical Diagnostics and Constraints

Initial releases will prefer diagnostics over strong constraints. Candidate diagnostics include:

Physical penalties may be introduced only when the represented variables support a defensible calculation. The project will not claim exact conservation from an incomplete state vector.

Part III — Proposed Architecture

23. Reference Architecture: Weather-JEPA v1

23.1 Architectural Objective

The reference architecture must be large enough to learn meaningful cross-variable and multiscale structure, but small enough for repeatable experiments on 32 GB unified memory.

23.2 High-Level Flow

ERA5 / WeatherBench-compatible state
        |
        v
Validation -> normalization -> temporal windowing
        |
        v
Variable/level embeddings + static fields + calendar features
        |
        v
Spatial patch embedding
        |
        v
Factorized vertical-variable mixer
        |
        v
Multiscale context encoder -------------------------.
        |                                            |
        v                                            v
JEPA predictor + horizon query                EMA target encoder
        |                                            |
        '-------------- latent loss -----------------'
        |
        +--> optional decoder --> physical fields
        |
        +--> probes / classifiers / hazard heads

23.3 Input Modules

23.4 Encoder

The initial encoder will use a hierarchical transformer or hybrid convolution-transformer design with:

A pure global-attention transformer is not the default because its memory bill would arrive before its scientific contribution.

23.5 Target Encoder

The target encoder mirrors the context encoder and is updated by EMA. It receives target fields without the context corruption applied to the online encoder.

23.6 Predictor

The predictor is intentionally narrower than the encoder and includes:

23.7 Decoder

The decoder is not the center of the JEPA objective, but it is required for physical evaluation. It should be lightweight and shared across compared objectives where possible.

Decoder options:

23.8 Downstream Heads

23.9 Initial Parameter Tiers

Tier Approximate parameters Purpose
Micro 1–5 million pipeline and loss verification
Small 10–30 million objective comparison and ablation
Medium 40–100 million final workstation-scale experiments
Large >100 million only after profiling and explicit approval

The project will scale only after the smaller tier passes its scientific gate. A larger failed experiment is not automatically more informative.

23.10 Precision and Memory

Part IV — Data Management Plan

24. Authoritative Data Sources

24.1 ERA5

ERA5 is the primary research dataset because it provides a coherent, long-duration, global reanalysis with pressure-level and single-level variables. It is a model-assimilation product, not direct observation, and this limitation must remain visible in all claims.

24.2 WeatherBench 2

WeatherBench 2 provides an open, like-for-like evaluation framework, reference datasets, baseline forecasts, and established metrics. Weather-JEPA should preserve compatibility wherever practical rather than inventing a private benchmark on which it is conveniently undefeated.

24.3 Independent Observational Data

Later hazard evaluation may use:

Each external source requires a data card, license review, temporal coverage audit, and alignment procedure.

25. Initial Variable Set

The initial state should remain scientifically useful but computationally manageable.

25.1 Pressure-Level Variables

25.2 Initial Pressure Levels

Recommended v1 levels:

This set captures boundary-layer, lower-tropospheric, midlevel, jet-level, upper-tropospheric, and lower-stratospheric structure while limiting channel count. A seven-level reduced configuration may be used for early experiments; a 13-level configuration may enter after the pipeline is stable.

25.3 Surface and Near-Surface Variables

Initial candidates:

25.4 Static Variables

26. Spatial Domains and Resolutions

26.1 Development Domain

A regional domain will be used for initial end-to-end testing. Candidate regions should contain varied dynamics and sufficient hazardous events. The exact bounding box requires an ADR.

26.2 Reference Resolution

Initial experiments should use 1.5° or 1.0° resolution. A 0.25° global archive is valuable as source data but is not the default training grid on 32 GB hardware.

26.3 Scale Progression

  1. synthetic tensors;
  2. tiny geographic subset;
  3. regional coarse resolution;
  4. regional moderate resolution;
  5. global coarse resolution;
  6. expanded global or regional high resolution only after profiling.

27. Temporal Coverage and Splits

A provisional chronology is:

Exact years may change based on dataset availability, but the following are mandatory:

28. Data Pipeline

CDS / WeatherBench source
    -> immutable raw archive
    -> checksum and metadata validation
    -> coordinate normalization
    -> variable and unit validation
    -> regridding
    -> temporal alignment
    -> derived-variable generation
    -> training-statistic computation
    -> normalized Zarr stores
    -> sample index manifests
    -> DataLoader / DataPipe

29. Storage Format

30. Data Contracts

Every variable must declare:

Pipeline code must validate contracts before training.

31. Data Quality Checks

Required checks include:

32. Data Lineage and Versioning

Each processed dataset receives:

Large data will not be stored directly in Git. Manifests, small fixtures, and acquisition scripts will be versioned.

33. Data Ethics and Licensing

Weather and reanalysis data are generally less personally sensitive than human-subject data, but the project will still:

Part V — Development Sequence and Phase Gates

34. Stage 0 — Repository and Environment Foundation

Objectives

Create a reliable project skeleton before model experimentation.

Work

Exit Gate

35. Stage 1 — Research Specification

Objectives

Freeze the initial scientific question and comparison protocol.

Work

Exit Gate

36. Stage 2 — Data Prototype

Objectives

Build a trustworthy small-scale pipeline.

Work

Exit Gate

37. Stage 3 — Synthetic Mathematical Verification

Objectives

Verify architecture and losses on controlled systems before blaming the atmosphere.

Work

Train micro-models on:

Exit Gate

38. Stage 4 — Persistence and Climatology Baselines

Objectives

Establish non-neural reference skill.

Work

Exit Gate

All learned models must be evaluated against these baselines. A neural network that cannot beat persistence at short lead times has not earned a more poetic description.

39. Stage 5 — Shared Backbone

Objectives

Implement the architecture used by all primary objectives.

Work

Exit Gate

40. Stage 6 — Supervised Forecast Baseline

Objectives

Establish direct forecasting performance.

Work

Exit Gate

41. Stage 7 — Masked Autoencoder Baseline

Objectives

Measure reconstruction-based representation learning.

Work

Exit Gate

42. Stage 8 — Weather-JEPA v1

Objectives

Implement reconstruction-free latent prediction.

Work

Exit Gate

43. Stage 9 — Controlled Objective Comparison

Objectives

Answer the central research question.

Controls

Hold constant:

Deliverables

Exit Gate

A conclusion is permitted only when comparison integrity is demonstrated.

44. Stage 10 — Latent Dynamics and Rollout

Objectives

Test whether learned representations support stable atmospheric evolution.

Work

Exit Gate

45. Stage 11 — Transfer and Robustness

Tasks

Exit Gate

At least one transfer task must be evaluated without full encoder fine-tuning.

46. Stage 12 — Hazard-Focused Evaluation

Initial Hazard Candidates

Required Metrics

Event metrics depend on the task and may include:

Exit Gate

Hazard claims must be based on event-level verification, not inference from global field scores.

47. Stage 13 — Probabilistic Weather-JEPA

Entry Requirements

Work

Exit Gate

48. Stage 14 — Scaling and Optimization

Scaling follows evidence, not impatience.

Work

Exit Gate

Each scale increase must identify the scientific question it enables.

49. Stage 15 — External Reproduction and Release

Work

Exit Gate

A release is complete only when the published result can be recreated from documented artifacts.

Part VI — Evaluation Framework

50. Field-Level Metrics

Metrics must be reported separately by variable and level before aggregation.

51. Scale and Structure Metrics

52. Probabilistic Metrics

53. Representation Metrics

54. Compute Metrics

55. Statistical Reporting

56. Success Criteria

Weather-JEPA v1 will be considered scientifically successful if it achieves at least one of the following under fair comparison:

  1. materially better frozen-probe or few-shot transfer;
  2. more stable latent rollout;
  3. improved robustness under missing or corrupted inputs;
  4. improved hazard-event representation or prediction;
  5. equivalent skill at materially lower compute;
  6. a well-supported negative result that clarifies when JEPA is not advantageous.

Absolute superiority on every forecast metric is not required.

Part VII — AI Engineering Standards

57. AI Risk Management

The project will adapt the NIST AI Risk Management Framework functions:

58. Model Documentation

Every released model requires a model card containing:

59. Training Standards

60. Experiment Integrity

61. Robustness and Safety Testing

Required stress tests include:

62. Explainability Standards

Interpretability artifacts may include attention maps, latent projections, probes, and sensitivity analyses, but:

63. Responsible Claims

Public statements must distinguish:

Prohibited language includes “predicts disasters,” “saves lives,” “understands weather,” or “replaces meteorologists” unless the evidence genuinely supports the exact claim. The project goal may be to protect life; the model does not receive moral credit in advance.

Part VIII — Data Engineering Standards

64. Data Architecture Standards

65. Reproducible Data Builds

A data build must be recreatable using:

66. Validation and Observability

The pipeline will emit machine-readable reports for:

67. Leakage Prevention

68. Data Security

Although public atmospheric data dominate the project:

Part IX — Software Engineering Standards

69. Repository Structure

weather-jepa/
├── README.md
├── LICENSE
├── CITATION.cff
├── SECURITY.md
├── CONTRIBUTING.md
├── CHANGELOG.md
├── pyproject.toml
├── configs/
│   ├── data/
│   ├── model/
│   ├── objective/
│   ├── train/
│   └── experiment/
├── docs/
│   ├── architecture/
│   ├── adr/
│   ├── rdr/
│   ├── standards/
│   ├── tutorials/
│   └── project-management/
├── src/weather_jepa/
│   ├── data/
│   ├── models/
│   ├── objectives/
│   ├── training/
│   ├── evaluation/
│   ├── hazards/
│   ├── visualization/
│   └── utils/
├── scripts/
├── tests/
│   ├── unit/
│   ├── integration/
│   ├── regression/
│   └── fixtures/
├── experiments/
├── reports/
├── figures/
├── notebooks/
└── papers/

70. Python Standards

71. Configuration Standards

72. Testing Pyramid

Unit Tests

Integration Tests

Regression Tests

Scientific Tests

73. Continuous Integration

CI must run:

MPS-specific tests may run locally if hosted CI lacks Apple hardware, but their results must be recorded before release.

74. Version Control

75. Code Review Checklist

A change is reviewed for:

76. Secure Software Development

The project will adapt the NIST Secure Software Development Framework:

Controls include:

77. Performance Engineering

Performance changes require measurement.

Track:

Optimization order:

  1. correctness;
  2. measurement;
  3. data pipeline;
  4. tensor shapes and unnecessary copies;
  5. precision;
  6. checkpointing;
  7. architecture scaling.

Part X — Experiment and Artifact Management

78. Experiment Naming

Recommended format:

WJ-{stage}-{objective}-{domain}-{resolution}-{tier}-{date}-{sequence}

Example:

WJ-S08-JEPA-NATL-1deg-SMALL-20260815-003

79. Experiment Card

Each experiment records:

experiment_id:
status:
hypothesis:
research_question:
code_commit:
config_hash:
dataset_version:
split_version:
model_version:
objective:
parameter_count:
seed:
hardware:
start_time:
end_time:
processed_samples:
peak_memory:
primary_metrics:
secondary_metrics:
artifacts:
failures:
conclusion:
next_action:

80. Artifact Retention

Retain permanently:

Intermediate checkpoints may follow a storage policy, but deletion must not make a published result irreproducible.

81. Claim-Evidence Matrix

Every public claim should map to:

| Claim | Experiment(s) | Dataset | Metric | Comparator | Uncertainty | Limitation | |—|—|—|—|—|—|—|

No evidence row, no claim.

Part XI — Risk Register

82. Scientific Risks

Risk Probability Impact Mitigation Trigger
JEPA offers no advantage Medium Medium Publish controlled negative result; identify task boundaries Baselines consistently match or exceed JEPA
Latent collapse Medium High Diagnostics, EMA tuning, target design, regularization Effective rank or variance degrades
Forecast smoothing High High Spectral and event metrics; probabilistic extension Extremes and gradients underrepresented
Reanalysis imitation mistaken for atmospheric understanding High High Independent observations and transfer tests Good ERA5 score, poor external validation
Hazard sample scarcity High Medium Event catalogs, longer chronology, bootstrap, focused domains Unstable event metrics
Metric overfitting Medium High Preregister primary metrics, untouched challenge set Repeated tuning on test results

83. Engineering Risks

Risk Probability Impact Mitigation
MPS unsupported operations Medium Medium Device tests, fallbacks, profiling, architecture alternatives
Memory exhaustion High High Small tiers, patching, accumulation, checkpointing
Data-download or storage limits High Medium Regional subsets, staged retrieval, compression, manifests
Pipeline bottleneck Medium High Chunk benchmarking, prefetching, cached indices
Environment drift Medium Medium Lock files, containers where feasible, CI
Corrupted checkpoints Low High Checksums, atomic writes, backup policy

84. Governance and Communication Risks

Risk Probability Impact Mitigation
Scope creep High High Phase gates, backlog triage, non-goals
Inflated novelty Medium High Literature ledger and reviewer challenge
Public misunderstanding Medium High Research-only labels, limitations, careful language
Cherry-picking Medium High Registered metrics and complete result tables
Documentation decay High Medium Documentation included in definition of done

Part XII — Milestones and Deliverables

85. Major Milestones

Milestone Deliverable Governing Gate
M0 Repository foundation CI and environment reproducible
M1 Research specification Questions map to measurable protocol
M2 Data pipeline v1 Validated, versioned, leakage-free data
M3 Synthetic verification Mathematical implementation validated
M4 Non-neural baselines Persistence and climatology established
M5 Shared backbone Objective-compatible architecture
M6 Supervised baseline Stable direct forecast model
M7 MAE baseline Reconstruction representation baseline
M8 Weather-JEPA v1 Non-collapsed latent training
M9 Objective comparison Central research result
M10 Rollout study Latent stability characterized
M11 Transfer study Robustness and probe evidence
M12 Hazard evaluation Event-level evidence
M13 Probabilistic prototype Calibrated alternative futures
M14 Public research release Reproducible code, cards, paper

86. Definition of Done

A work item is done only when:

A notebook that ran once is not done. It is an anecdote with cells.

Part XIII — Documentation and Publication Plan

87. Living Documentation

The project documentation site will include:

88. Public Education

Public posts may explain:

Educational communication must not reveal test results before the experiment record is complete or transform exploratory findings into settled conclusions.

89. Publication Sequence

  1. technical project documentation;
  2. benchmark and objective-comparison report;
  3. preprint if evidence warrants;
  4. conference or workshop submission;
  5. expanded journal manuscript;
  6. hazard-specific paper only after adequate event validation.

90. Required Scholarly Artifacts

Part XIV — Initial Backlog

91. Immediate Next Actions

Research

Repository

Data

Modeling

Project Management

Part XV — Weekly Operating Rhythm

92. Weekly Research Cycle

Plan

Build

Measure

Review

Communicate

93. Weekly Status Template

# Weekly Weather-JEPA Review — YYYY-MM-DD

## Objective
## Work Completed
## Evidence Generated
## Metrics
## Problems and Failures
## Decisions
## Risks
## Documentation Updated
## Public Communication
## Next Week

Part XVI — Source and Standards Basis

94. Governing External References

The plan should be reviewed against the current versions of the following:

Part XVII — Final Governing Statement

Weather-JEPA will be judged by the quality of its evidence, not the confidence of its branding. The project will proceed from validated data to verified mathematics, from simple baselines to controlled objective comparisons, from deterministic stability to probabilistic uncertainty, and from aggregate scores to hazard-relevant evaluation.

The project’s north star is the protection of human life. That principle requires ambition, but it also requires restraint. A model that is fast, visually impressive, and poorly calibrated near dangerous weather is not a partial success merely because the latent space makes an attractive figure. Weather-JEPA will therefore publish what works, what fails, what remains uncertain, and exactly how each conclusion was reached.

Appendix A — Phase-Gate Checklist

[ ] Scientific question defined
[ ] Acceptance criteria registered
[ ] Dataset version frozen
[ ] Split leakage tests pass
[ ] Baselines implemented
[ ] Code commit recorded
[ ] Config resolved and archived
[ ] Multiple seeds completed where required
[ ] Compute and memory recorded
[ ] Primary and secondary metrics reported
[ ] Hazard metrics included where relevant
[ ] Failure analysis completed
[ ] Data/model/experiment cards updated
[ ] Claims linked to evidence
[ ] Limitations documented
[ ] Reproduction performed
[ ] Release approved

Appendix B — Architecture Decision Record Template

# ADR-XXXX: Decision Title

## Status
Proposed | Accepted | Superseded | Rejected

## Context
## Decision Drivers
## Considered Options
## Decision
## Consequences
## Evidence
## Reversal Conditions
## Related Experiments

Appendix C — Research Decision Record Template

# RDR-XXXX: Research Decision

## Research Question
## Hypothesis
## Design
## Primary Metrics
## Controls
## Evidence
## Decision
## Threats to Validity
## Follow-up

Appendix D — Release Checklist

[ ] Version and tag created
[ ] Changelog complete
[ ] License review complete
[ ] Dependency scan passes
[ ] Tests pass
[ ] Clean installation verified
[ ] Flagship result reproduced
[ ] Checkpoint checksum published
[ ] Dataset manifest published
[ ] Model card published
[ ] Data card published
[ ] Safety and limitations statement published
[ ] Citation metadata published
[ ] Documentation site updated