From global groundwater data to defensible decisions.

Standing on the work of generations. Built for the scale that work created.

The data revolution already happened. NHDPlus made high-resolution stream networks computable across North America; HydroSHEDS made global hydrography (HydroBASINS watersheds, HydroRIVERS streams, HydroLAKES lakes) accessible everywhere on Earth. USGS made groundwater monitoring, wells, and hydraulic property data continuous and live. PRISM made climate fields routine. GRACE and GRACE-FO made basin-scale storage anomalies quantifiable everywhere — the satellite-gravimetric signature of aquifer depletion and groundwater mining at regional and watershed scale. All sit in the IGW-NET pre-integrated base or federate via DataNET, ready to populate a model from minute one.

USGS 3DEP Bare Earth DEM Dynamic services made multi-resolution terrain queryable across all of North America (1m LiDAR where collected, 10m seamless elsewhere, 5m IfSAR in Alaska) — continental coverage at a resolution that is truly immovable: you cannot download, store, or preprocess this per project at full resolution.

The numerical methods matured over decades. The platform integrates two complementary flow engines — the MODFLOW family (MODFLOW 6, MODFLOW-2005, MODFLOW-USG, MODFLOW-NWT) for regulatory-grade simulation, and the IGW (Interactive Groundwater) native engine for real-time streaming visualization and progressive exploration. Both are documented in IGW-NET Users' Manual Ch. 1 as the platform's flow solvers. Around them: MT3DMS for reactive transport, SEAWAT for variable-density flow, MODPATH for particle tracking, T-PROGS for geostatistical aquifer characterization, UCODE for automatic calibration — all rigorously validated, all open-source, all in the hands of every practitioner. The open-source water science community made the engines, the data, and the standards available to the world.

Three foundational layers, then the workflow loop.

Conventional workflows are linear: prepare data, build model, run simulation, export results, visualize, then analyze — each step its own tool with its own format, every handoff creating I/O, delay, and inconsistency. IGW-NET keeps them all in one loop: foundations ready before any work begins, then a workflow loop. You don't wait between steps. You steer.

The steering system rests on three foundational layers.

Groundwater happens underground, but its dominant patterns are set above. Water particles take the path of least resistance to discharge — rivers, lakes, the ocean. Stream geometry, lake position, drainage topology, and recharge pattern together fix the regional spatial and stress framework — gradients, discharge areas, capture zones, plume pathways — that controls large-scale flow. Heterogeneity, layering, and recharge variability add textures on top — they perturb the pattern; they don't determine it.

The pre-integrated base captures these dominant surface controls. The user refines the textures — and collects the data that calibrates them — within a structurally correct framework, instantly available when you draw boundaries:

Five things happen at once.

Three commitments behind every answer.

Foundations and a workflow loop are not enough. The answers the platform produces have to be defensible — against observations, against physics, against scale. Three architectural commitments do that work: observation through two pre-integrated calibration datasets, physics through drainage that emerges from the flow solution, and architecture through a conceptual model decoupled from the computational grid.

Two datasets. Two patterns. One live comparison.

IGW-NET pulls in two distinct national monitoring datasets, each doing different work in calibration — and the asymmetry between them is itself important. The 15M+ water-well dataset is the only calibration dataset dense enough to support regional or site-scale calibration anywhere on demand across the IGW-NET coverage area. Drillers' records cover every US state and every Canadian province in the pre-integrated base. Where state agencies provide static water levels, lithologies, or groundwater quality, those attach automatically; coverage is broadest in long-standing partner regions (Michigan alone holds 800K+ records) and continuously expanding through DataNET.

SWLs are noisy as individual measurements, but in aggregate they pin down spatial pattern at regional scale: where the water table is high and low, how it gradients, where the divides are. The statistical principle is honest — many noisy measurements beat a few precise ones for resolving a spatial field. Wherever wells have been drilled, the data exists — essentially everywhere outside dense urban centers on public water. This is what matches the platform's model-anywhere promise with a calibrate-anywhere reality.

USGS and Canadian monitoring well networks add the second dataset — sparse spatially but continuous in time, delivering historical and live water-level time series at sentinel sites. They pin down temporal pattern: seasonal cycles, drought response, pumping signatures, recharge events. They are excellent where they exist; they don't exist universally. A single click downloads the relevant stations, formats the time series, and loads them into the model for comparison; the same is true for the SWL dataset. Calibration data assembly — one of the most painful tasks in conventional groundwater workflows — collapses to a single click. Both datasets are compared against the running simulation in real time. The statistics tell the user where to steer next, and where one more observation would matter most.

Drainage as solution, not input.

Conventional 3D groundwater models treat the drainage network — rivers, seeps, springs, drains — as a prescribed boundary condition. The modeler digitizes the network upfront; specifies head, conductance, or flux at each stream cell; and the solver respects those constraints whether or not they are physically consistent with the rest of the model. Mismatched assumptions can produce numerical artifacts, divergence, or quiet wrong answers. IGW-NET inverts this. Drainage emerges from the flow solution as a consequence of the physics: where the computed water table rises to meet the land surface, drainage occurs naturally — wherever the simulated head equals or exceeds elevation. At LiDAR resolution, this resolves not just rivers and major channels but seeps, wetlands, and fens — features that conventionally require expensive hand-mapping at every project. They emerge from the model itself. The drainage network is not an input the modeler guesses at; it is an output the model produces. This is scientifically more correct — drainage is a consequence, not a cause of regional flow — and operationally more robust: wrong assumptions about where streams should be don't crash the model; they reveal themselves visually as the simulation runs. The user sees where the model wants to drain, compares it against the observed network, and refines accordingly. Failure becomes diagnostic, not catastrophic. (Users' Manual Ch. 14 §14.2.1 documents this as the Level 1 DEM-as-drain default: the land surface acts as a one-way drain controlled by the Surface Drain Leakancy parameter; every gaining surface-water feature in the domain — rivers, lakes, wetlands, springs, seeps — is represented implicitly because they all sit at DEM lows.)

Under coupled climate change, land-use change, and growing pumping, these emergent features evolve — wetlands shrink, fragment, and disappear; fen-scale systems lose their groundwater discharge. See SwaNET L2 § "Water sustainability" for the coupled SwaNET-IGW-NET architecture and Cross-Platform Guide C.3 for the complementarity.

The conceptual model is grid-independent.

In conventional groundwater modeling, the conceptual model — wells, rivers, lakes, plume sources, geological layers, boundaries — is bound to the computational grid. Each feature is digitized in cell coordinates: well in row i, column j, layer k; river along this row of cells; boundary along that face. Changing grid resolution means re-digitizing the conceptual model in the new cell coordinates — a costly, error-prone reconstruction. IGW-NET inverts this. The conceptual model lives in real-world coordinates: a well sits at a longitude, latitude, and screened-interval elevation; a river follows a polyline in geographic space; a plume source occupies a coordinate-defined volume. The computational grid is laid over this conceptual fabric. Change grid resolution from 500m to 50m to 5m — the conceptual features auto-remap onto the new grid. The model the user thinks about is the model the user keeps, regardless of how finely or coarsely they choose to discretize it. This is the architectural foundation that lets hierarchical nested modeling, multi-resolution Monte Carlo, and progressive refinement work as one continuous workflow rather than as separate model-rebuilding exercises. (Users' Manual Ch. 7 §7.1 documents the xyz→ijk discretization that makes this possible: the conceptual model (xyz, real-world coordinates) is rebuilt onto the computational grid (ijk) fresh on every SIMULATE; the conceptual model persists, the grid does not.)

Free surfaces, surface-water features, and steering — the choices that determine whether your model is right.

Regional groundwater models face three structural decisions that determine whether the answer is right: how to handle the 3D free-surface water table (the unsaturated/saturated boundary that is itself part of the solution); how to represent the surface-water features — rivers, lakes, wetlands — that exchange water with the aquifer; and how to make those choices visible enough to catch artifacts during simulation. IGW-NET handles each through a deliberate architectural approach: a 2–3 simulation iterative refinement for the free-surface problem; a five-way formulation taxonomy for surface-water features, steered per feature; and a streaming visual-analytics suite that makes the consequences of each choice visible during the simulation itself. The user spends time on the decisions where professional judgment matters most; the platform makes those decisions productive by showing their consequences immediately.

The 3D free-surface problem — tackled cleanly in 2–3 linear simulations.

The 3D unconfined-aquifer free-surface problem is a classically tough one in groundwater modeling. Classical approaches subdivide layers based on land surface and geological boundaries, then resolve cells that straddle the water table through wet/dry switching — which often diverges. IGW-NET resolves this through a robust architectural approach: layer geometry is derived from the water-table solution itself, refined across 2–3 quick linear simulations. The classically nonlinear free-surface problem becomes a strictly confined sequence of linear problems.

The workflow:

1. 2D run — solves a linear vertically-integrated aquifer. Produces an approximate water-table elevation field, accurate enough to guide where to subdivide.
2. 3D run with a few thick layers (say 3) — layers subdivided below the 2D water table; thick layers tolerate the 2D water table's approximation. All cells stay saturated. Strictly confined linear problem. Both water table and 3D field improve.
3. 3D run with finer layers (say 10) — subdivided below the refined water table. Still strictly confined. Further refinement as needed.

Aggressive subdivision (direct 2D → 25 layers) also works — the wet/dry pattern is bounded and consistent, not chaotic — but takes more iterations to negotiate the wet/dry transitions. Incremental steering eliminates wet/dry entirely; both paths converge to the same answer. (Users' Manual Ch. 7 §7.4 documents the Water-Table-as-Top option that enables this workflow mechanically — the Exchange Field carries the water-table elevation from one simulation to the next as the top boundary of the 3D computational domain. A forthcoming chapter on the free-surface algorithm provides the full mathematical and algorithmic treatment.)

This is computational steering in its deepest form — not parameter tuning or scheme selection, but human-conceptual and machine-mathematical collaboration on model structure itself. The user brings hydrogeologic judgment about where vertical resolution matters and how aggressively to subdivide; the machine brings linear-solver efficiency and continuous head fields at every step. Each iteration is a real, complete solution the user can stop at and defend.

The result: a robust, effective architectural solution to a classically tough problem.

How to represent rivers, lakes, and wetlands — five formulations, one decision per feature.

Modeling how rivers, lakes, and wetlands exchange water with the aquifer is one of the most consequential conceptual modeling decisions. A naive intuition says: "use the most general formulation everywhere — bidirectional head-dependent exchange — to capture all the physics." In practice, this can produce models that calibrate well on heads but are wildly wrong on fluxes — and that lead to qualitatively wrong sustainability conclusions. IGW-NET supports five formulations; the user steers per feature, matching formulation to the physical reality of each surface-water body and the question being asked. (The IGW-NET Users' Manual organizes these as three levels — Level 1 DEM-as-drain, Level 2 explicit head-dependent features with one-way / two-way / prescribed-head sub-types, Level 3 coupled modeling; see Manual Ch. 14 §14.2. The five ways below expand Level 2 into its three sub-types and split Level 3 by surface-water physics.)

The five ways:

Critical distinction: Ways 1–4 treat surface water as a boundary condition to the groundwater model. Way 5 treats surface water and groundwater as both solution variables, solved together.

Wetlands: drain or coupled — a steering decision worth making per feature.

Wetlands are where this taxonomy gets architecturally interesting. Some wetlands are routine — small, transient, of regional context interest only. Modeling them as drains (Ways 1 or 2) is sufficient and far more efficient: at LiDAR resolution, wetlands emerge naturally from the physics, the model identifies their locations without user digitization, and computational cost is minimal. Other wetlands are objects of management or regulatory interest — wetland-decline trajectories under nearby pumping; specific wetland-stage timeseries; ecological-significance studies. For these, the coupled lake-equivalent formulation (Way 5a) makes the wetland a solution variable with full water-balance + 3D aquifer Darcy.

The user steers per wetland. Not every wetland needs the same treatment; the platform supports the judgment call wetland by wetland. This is computational steering at the conceptual-model level — the user spends time on decisions that require professional judgment, while the platform handles the mechanical setup. A regional model with hundreds of wetlands might have most as drains and a handful as coupled — exactly matching where modeling expertise actually adds value.

Why "more physics" is not always more accurate — the naive trap.

The naive logic: Way 3 is more general than Way 1 because it allows bidirectional flow → therefore Way 3 must be more accurate, just slower. This thinking misses how flux uncertainty compounds.

The exchange flux at a stream cell, by Darcy's law:

Q = K · A · (h_aquifer − h_stream) / L

Both factors carry compounding uncertainty. Hydraulic conductivity in a typical sand aquifer can defensibly be 10 ft/day or 100 ft/day before calibration — an order-of-magnitude range, all justifiable from literature. The head gradient (h_aquifer − h_stream) can be off by 5–10× when coarse-resolution DEM places the prescribed stream stage on the channel bank or surrounding terrain rather than the stream bed itself — at 30m or coarser DEM, a pixel containing a small stream represents the average of channel and banks, which in topographically variable terrain can be meters above the actual water surface.

Multiply these together and the flux can be wrong by orders of magnitude. A 5–10× rainfall flux through a single stream cell is a genuinely typical artifact when Way 3 is misapplied to small streams in topographically variable terrain — not a hypothetical extreme. The IGW-NET Users' Manual §14.7 documents this exact failure mechanism (the central pitfall: dense hydrography network + DEM-derived stages + two-way head-dependent flux produces aggregate fluxes hundreds of thousands to millions of m³/day with no physical basis), and §14.9.2 formalizes the diagnostic: the R_SW→GW/rain ratio (head-dependent flux into the aquifer divided by total rainfall recharge) is the canonical canary — R ≥ 5 implausible in any climate; R ≥ 10 the canonical failure signature. And calibration doesn't catch this: the aquifer absorbs the fictitious flux locally by adjusting heads slightly; the calibrator matches observed heads; the artifact stays invisible in head plots. Heads can calibrate beautifully while fluxes are physically impossible.

The infinite-source-of-water trap — applies to any prescribed-head boundary.

The flux-artifact problem generalizes beyond stream cells. Any prescribed-head boundary — Way 4 (prescribed-head streams or lakes), constant-head exterior boundaries based on measured well levels, specified-head regional-context cells — acts as an infinite source of water to nearby stresses.

A common scenario: A modeler sets a constant-head boundary based on measured well levels at the model perimeter (natural and defensible at first glance — "I'm using real data"). They install a high-capacity pumping well inside the model, near the boundary. The simulation runs:

• The well pumps; the nearby constant-head cells supply water to maintain the prescribed head
• The well shows little drawdown; the cone of depression is suppressed
• The simulated capture zone is artificially small
• The conclusion: "The well can pump 1000 gpm with minimal regional impact"
• Reality: the actual aquifer doesn't have an infinite source at the boundary. Real pumping would cause much larger drawdown, larger capture zone, real impacts on adjacent wells and surface water.

The same trap applies to small streams, wetlands, and headwater systems modeled with Way 3 or Way 4. A high-capacity well next to a prescribed-head wetland pumps "forever" in the simulation with no environmental impact; in reality, the wetland water level drops and the system dries up in days. Modeling fragile features with prescribed-head or two-way head-dependent boundaries produces qualitatively wrong sustainability conclusions — not just quantitatively off, but the opposite physical narrative. (This trap generalizes the small-stream failure mode formally documented in Users' Manual §14.7: any prescribed-head or two-way head-dependent boundary placed where the underlying stage is unreliable or the feature is hydrologically fragile becomes a source of physically-impossible flux. The protective convention — one-way drain for small / fragile features, two-way only for genuinely large connected systems — is mass-balance protection, not just approximation.)

For fragile and small features, Way 1 (one-way drain) is much more robust. It respects the finiteness of small water bodies: drainage triggers only when the water table physically reaches the surface; pumping that lowers the water table simply causes drainage to stop. The model says the right thing about sustainability because the formulation respects the underlying physics.

For genuinely large connected systems (major rivers, large reservoirs, RBF settings), Way 3 or Way 4 is the right choice — the bidirectional exchange is physically real, the stream stage is well-known, the leakance can be reasonably estimated. The platform supports both. The user steers per feature.

Three layers of streaming visual analytics — catch the artifacts as the simulation runs.

What makes per-feature steering operationally real — and what makes the naive trap above catchable in seconds rather than months — is that diagnostic instruments stream during simulation, not after it. The water budget showing the 5× rainfall flux at a stream cell, the drawdown map showing the cone of depression suppressed near a constant-head boundary, the capture-zone delineation revealing boundary artifacts: all visible while the simulation runs, at the granularity that matches the question. Users' Manual Ch. 8 ("Results") documents the streaming visualization architecture — head fields, velocity vectors, particles, plumes, and water-budget components updating live alongside the simulation. Three layers, all streaming during simulation:

Layer 1 — The always-on base view. The simulation lives on a Google Maps backdrop — toggleable between terrain, satellite/aerial-photo, and hybrid views so the user always recognizes the real place. The model itself runs in a locally projected coordinate system (typically a UTM zone matched to the project area), so distances, areas, and gradients are computed without projection-induced distortion; the basemap is reprojected to match for display. Display convenience without modeling distortion. On this base, the whole simulation is alive at once:

• Conceptual features — wells, contamination sources, zones of different hydraulic conductivity, boundary conditions, drainage features
• Head contours — the head field as map overlays, evolving each timestep
• Velocity vectors — flow direction and magnitude
• Advecting particles — pathlines, impact zones, capture zones — particles migrate through the live flow field
• Solute plumes — concentration fields developing through advection, dispersion, and reaction

The user looks at the screen and sees the basin, the model elements, and the live physics simultaneously.

Layer 2 — One-or-two-click streaming detail panels. When the user wants more depth, they bring up additional concurrent streams that continue to update in real time alongside the map view:

• Cross-sections of head, velocity vectors, aquifer elevations, particles, plumes — vertical cuts at any orientation
• Hydrographs at monitoring wells — head time-series, drawdown trajectories streaming as they develop
• Breakthrough curves at compliance wells — concentration time-series at observation points
• Water balance for any zone — per-domain, per-zone, per-feature, per-feature-type, or comparatively across multiple zones
• 3D water-table surface — the saturated-zone top as a 3D rendered surface

These augment Layer 1; they don't replace it. The map view stays alive while the detail panels stream their own data.

Layer 3 — Pause-and-explore true 3D. When the user pauses the simulation, they can initiate full 3D rendering for deep inspection:

• 3D velocity vectors — full flow field as 3D arrows through the aquifer volume
• 3D plume isosurfaces — concentration isosurfaces showing plume geometry in volume
• 3D aquifer elevations — bedrock topography, conceptual layer boundaries, water table all as 3D surfaces
• 3D K distribution — hydraulic conductivity volume rendering, showing heterogeneity in 3D

This is deep-inspection mode — used when the user wants to understand 3D geometry and structure rather than watch evolution.

Contamination sources are added anytime — real or hypothetical. Any source of water entering the aquifer can carry a concentration. Named environmental sources include:

• Polluted rivers, ditches, or canals — contaminated surface water seeping in at gaining or losing reaches
• Polluted ponds and lagoons — industrial settling ponds, agricultural waste lagoons, contaminated surface impoundments
• Contaminated recharge — agricultural nitrate, road-salt brine, contaminated stormwater infiltration
• Injection wells — deliberate (industrial waste injection, managed aquifer recharge with treated water) or accidental
• Instantaneous releases — spills, tank failures, one-event contamination
• Continuous landfill leaching — long-term plume sources from unlined or aged landfills
• Contaminated soil infiltration — historical surface contamination entering through recharge

Place a source — plume modeling triggers automatically and streams immediately alongside the flow. No separate setup. No post-processing step. The user watches the plume develop in real time.

The water budget is the diagnostic instrument for catching the flux artifacts described above. Interrogatable at any granularity matching the question — basin, zone, feature, feature-type, or comparative across zones — it makes otherwise-invisible flux artifacts visible during the simulation itself.

The steering loop closes in seconds — modelers catch errors, consultants scope monitoring, managers test policy.

With three layers of streaming visualization active during simulation, the user does three things at once — none of them after the simulation finishes:

(1) Builds system understanding viscerally. Drop a particle near a proposed well location → watch where it goes through the live flow field. Place a hypothetical contamination source → watch the plume develop with advection, dispersion, and reaction. Toggle a pumping schedule → watch the drawdown propagate through the hydrograph and the head contours. This is how experienced groundwater modelers think about a system — made directly visible as the simulation runs, on the real place, in real time.

(2) Catches modeling errors as they happen, or tests hypotheses live. The same architecture serves three roles:

• For the modeler: inspect the per-feature water budget at a stream cell — is that flux physically plausible, or 5× rainfall? Inspect the drawdown near a constant-head boundary — is the cone artificially suppressed? Catch the modeling error at simulation year 2; stop the run; steer; re-test.
• For the consultant: "Will two more monitoring wells in the upgradient buffer significantly reduce uncertainty in our capture-zone delineation?" Place the hypothetical wells; watch the sensitivity of breakthrough curves and capture-zone shape; defensibly scope monitoring investments before the field crew is deployed.
• For the manager: "Will reducing irrigation pumping 15% across the basin recover the depressed wetlands within 10 years?" Apply the scenario; watch the water-table recovery; watch wetland water budgets through time; watch downstream streamflow. Policy decisions made on visible system response, not on modeling reports submitted weeks later.

Different question owners. Different hypotheses. Same architecture. Same loop. Same speed.

This is what makes per-feature steering practical for regional models with hundreds of features — and what makes hypothesis testing operational at the speed of thought. Without concurrent streaming visualization, the user (whether modeler, consultant, or manager) could only test a handful of hypotheses or steering choices before exhausting their time budget. With it, they iterate continuously, converging on models defensible at the level of physical reasoning — not just at the level of calibration metrics.

Four scales of steering. Models inside models. Monte Carlo at scale.

This section shows what the architecture distinctively enables: steering at four different scales, and capabilities only a loop-inside-the-simulation design makes possible. Conventional 3D groundwater workflows have a fixed sequence: configure inputs, run the solver to completion, export outputs, then visualize and analyze. The simulation is a black box that completes after a long wait, after which you see what happened. IGW-NET inverts this: simulation, visualization, statistics, and analysis run together at the time-step level. You see the model evolve. You can steer while it runs.

What's shown, how it's computed, what it represents, and how the conceptual model itself evolves.

The four scales correspond to four dimensions the modeler adjusts: display, numerical methods, parameter properties, and conceptual fabric. Each kind has a specific mechanism; together they make "human in the loop" a complete architectural commitment, not a feature.

Capabilities the architecture makes possible.

When steering is part of the architecture rather than a workaround, capabilities emerge that go beyond what conventional workflows provide — at ensemble scale, across model hierarchies, and across portfolios of sites.

Groundwater doesn't stand alone. Neither does your work.

IGW-NET is one of five expressions of the MAGNET4WATER architecture. The cross-platform relationships are documented in the homepage Cross-Platform Guide. Its central coupling is to SwaNET for watershed recharge — recharge arrives as a spatial field, not as a manually reconstructed file. In future releases, IGW-NET will provide water-table information to all three other modeling platforms — as initial water table to SwaNET subbasins/HRUs and StormNET subcatchments for antecedent-state initialization, and as water-table depth to StormNET and ConduitNET cost models for excavation, trench dewatering, and infrastructure-cost adjustments. DataNET federates additional refinement data — terrain, lithology, well records, water-quality observations — alongside the always-on preprocessed multi-resolution database that direct-links IGW-NET to essential layers. And — when you choose — the Global Model Network and the Model Observatory, where your published work becomes the foundation for the next person's work.

Boundary, recharge, projection — arriving as fields, not as files.

Groundwater recharge is one of the hardest things to specify in a 3D model. It varies spatially with land use, soils, vadose-zone behavior, climate, and management — none of which a groundwater code can resolve on its own. In conventional workflows, recharge enters IGW-NET-style models as a manually constructed file: digitized polygons, lookup tables, or static rasters that go stale the moment land use or climate assumptions change — and the user must also manually align watershed boundaries with the aquifer model domain and reconcile projection systems between tools, which is silent, error-prone work.

With SwaNET feeding directly into IGW-NET, the handoff arrives as a complete package: watershed boundary, recharge field, and projection system (typically UTM) — all as live spatial fields, not as files. The recharge field becomes part of the steering system's stress framework, updating automatically when the upstream scenario changes. IGW-NET handles region-specific projection systems natively — no manual reprojection, no coordinate mismatches between watershed and aquifer boundaries, no silent offsets that flip capture-zone or well-impact answers. The handoff is field-to-field, architectural rather than procedural.

One architecture. Five expressions.

The MAGNET4WATER platforms share architectural principles — domain-appropriate cells, integrated iteration loops, real-time visualization, no-export workflows — and a common preprocessed data foundation. The homepage Cross-Platform Guide documents the full family — sister watershed platforms, the recharge handoff, the water-table fanout, sister pipe-network platforms, the unsaturated zone across three platforms, and the two complementary data routes (preprocessed multi-resolution database + DataNET federation).

Your work joins the network.

Your IGW-NET work can stay private to you, shared with your team, or published to the Global Model Network. Models published to the Model Observatory become accessible to other practitioners. Data served from your own GeoServer node — visualized in DataNET by URL, transferred directly to any modeling platform — stays on your own infrastructure with access under your control. Your work persists across projects, and across the careers of people whose work it informs. Every new participant who shares makes the network slightly richer for everyone else.