6.3. AI inversion

The AI inversion guide documents the complete learned-inversion lifecycle in pyCSAMT: scientific assumptions, training-data generation, architecture selection, training, inference, validation, uncertainty, hybrid refinement, PINN workflows, agent-assisted execution, and reporting.

AI inversion is a peer of Forward Modelling and Classical model integrations. Forward modeling generates responses from known earth models; classical inversion estimates models through numerical optimization; AI inversion learns an inverse mapping from representative examples. These approaches can support one another, but their assumptions and validation requirements remain distinct.

Validation is part of the model

A network prediction is not trustworthy merely because inference is fast or a training loss is small. Field use requires representative training data, strict data separation, out-of-distribution checks, physical diagnostics, uncertainty assessment, and comparison with independent evidence.

• 6.3.1. AI inversion concepts
  • 6.3.1.1. Where AI inversion fits
  • 6.3.1.2. Why EM inversion remains difficult
  • 6.3.1.3. Three AI inversion families
    • Supervised surrogate inversion
    • Physics-informed inversion
    • Hybrid inversion
  • 6.3.1.4. Choosing 1-D, 2-D, or 3-D
  • 6.3.1.5. Depth support is not the model depth
  • 6.3.1.6. Model parameterization
    • Layered 1-D target
    • Fixed-grid 2-D target
    • Graph target
    • Three grids in a 3-D AI workflow
  • 6.3.1.7. Data representation
  • 6.3.1.8. The feature contract
  • 6.3.1.9. Training distribution as prior
  • 6.3.1.10. Simulation-to-field domain gap
  • 6.3.1.11. Supervised learning objective
  • 6.3.1.12. Physics-informed objective
  • 6.3.1.13. Architectures encode assumptions
  • 6.3.1.14. Training, validation, and test separation
  • 6.3.1.15. Evaluation hierarchy
  • 6.3.1.16. Uncertainty concepts
  • 6.3.1.17. Configuration objects
  • 6.3.1.18. The Sites bridge
  • 6.3.1.19. Agents and automation
  • 6.3.1.20. Pretrained checkpoints
  • 6.3.1.21. Reproducibility and provenance
  • 6.3.1.22. Scientific acceptance framework
  • 6.3.1.23. Common conceptual mistakes
  • 6.3.1.24. Next steps
  • 6.3.1.25. Documentation figures
• 6.3.2. Architecture roadmap
  • 6.3.2.1. Package map
  • 6.3.2.2. The 3-D Maxwell equation and the production-backend choice
  • 6.3.2.3. What is verified today
  • 6.3.2.4. Wired into the agents
  • 6.3.2.5. Milestone status
  • 6.3.2.6. Next steps
• 6.3.3. Canonical data contracts
  • 6.3.3.1. Building a survey
  • 6.3.3.2. The 3-D Maxwell dataset contract
  • 6.3.3.3. Invalid data are never invented
  • 6.3.3.4. Convention is part of the data
  • 6.3.3.5. Selecting, subsetting, and merging
  • 6.3.3.6. Fitting a normalizer once, reusing it everywhere
  • 6.3.3.7. Splitting realizations without leaking
  • 6.3.3.8. Recording what actually produced a dataset
  • 6.3.3.9. Accounting for every station, not just the aggregate
• 6.3.4. Correlated geological priors
  • 6.3.4.1. What a Gaussian correlation length means
  • 6.3.4.2. Verify correlation statistically
  • 6.3.4.3. Build stratigraphy before adding bodies
  • 6.3.4.4. Compose lenses with explicit overlap rules
  • 6.3.4.5. Topography is a mask, not a vertical stretch
  • 6.3.4.6. Carry the same composition into 3-D
  • 6.3.4.7. Connecting a rich prior to 3-D Maxwell training
  • 6.3.4.8. Persist identity and audit the ensemble
• 6.3.5. Domain-gap and noise simulation
  • 6.3.5.1. Two families of corruption
  • 6.3.5.2. Composing one reproducible pass
  • 6.3.5.3. Fitting corruption from a real survey
  • 6.3.5.4. Comparing simulated and field distributions
  • 6.3.5.5. Accounting for every station, not just corruption
• 6.3.6. Solver-neutral Maxwell contracts
  • 6.3.6.1. The problem and result contracts
  • 6.3.6.2. A validated execution path, not just an interface
  • 6.3.6.3. Meshes built from geology, not by hand
  • 6.3.6.4. Proven against physics, not asserted
  • 6.3.6.5. What the solved 3-D backends guarantee
  • 6.3.6.6. Backends found by capability, not by import
  • 6.3.6.7. Caching and batch generation
• 6.3.7. 2-D Maxwell training-data generation
  • 6.3.7.1. Configuring one coherent dataset
  • 6.3.7.2. From complex impedance to network channels
  • 6.3.7.3. Two impedance modes, and why one needed more care than the other
  • 6.3.7.4. Fail fast before an impractical mesh
  • 6.3.7.5. Handing this to noise, or to training
• 6.3.8. 3-D Maxwell training-data generation
  • 6.3.8.1. Configuring a 3-D dataset
  • 6.3.8.2. A padded mesh, not a uniform one
  • 6.3.8.3. Frequency-aware core resolution
  • 6.3.8.4. Fail fast before an impractical mesh
  • 6.3.8.5. From impedance tensor to network channels
  • 6.3.8.6. Handing this to noise, agents, or training
• 6.3.9. Loss functions for scientific inversion
  • 6.3.9.1. Weighting a residual by what it means
  • 6.3.9.2. Penalizing structure, not just misfit
  • 6.3.9.3. Anchoring what the training data cannot see
  • 6.3.9.4. Closing the loop back through the forward solver
  • 6.3.9.5. Making declared uncertainty answerable to evidence
  • 6.3.9.6. Assemble an auditable staged score
  • 6.3.9.7. Wiring the spatial terms into a trainable network
  • 6.3.9.8. Choose and validate the objective deliberately
• 6.3.10. Recovery, residual, and OOD diagnostics
  • 6.3.10.1. Scoring recovery when the truth is known
  • 6.3.10.2. Breaking a response residual down by where it comes from
  • 6.3.10.3. Checking whether declared uncertainty deserves trust
  • 6.3.10.4. Flagging predictions the training distribution never covered
  • 6.3.10.5. Reading the four diagnostics together
  • 6.3.10.6. Turning diagnostics into an acceptance decision
  • 6.3.10.7. What actually reaches an agent’s result today
• 6.3.11. Reproducible experiment configuration
  • 6.3.11.1. Deriving stable, order-independent seeds
  • 6.3.11.2. Pinning a dataset by hash, not by path
  • 6.3.11.3. Fixing acceptance criteria before looking at results
  • 6.3.11.4. The complete configuration
  • 6.3.11.5. One frozen protocol still needs repeated runs
  • 6.3.11.6. What the configuration does not prove
• 6.3.12. AI inversion data preparation
  • 6.3.12.1. Data preparation workflow
  • 6.3.12.2. 1. Start from the decision and parameterization
  • 6.3.12.3. 2. Load field data canonically
  • 6.3.12.4. 3. Use observation containers before features
    • 1-D observations
    • 2-D observations
  • 6.3.12.5. 4. Freeze the 1-D feature contract
  • 6.3.12.6. 5. Build a 2-D field panel
  • 6.3.12.7. 6. Prepare coordinates for graph inversion
  • 6.3.12.8. 7. Design synthetic earth models
    • Target transformations
  • 6.3.12.9. 8. Generate a 1-D synthetic dataset
    • Generator parameters
  • 6.3.12.10. 9. Understand ForwardDataset
  • 6.3.12.11. 10. Generate pseudo-3-D graph data
  • 6.3.12.12. 11. Prepare 2-D training profiles
  • 6.3.12.13. 12. Prepare 3-D training profiles
  • 6.3.12.14. 13. Add realistic observation effects
  • 6.3.12.15. 14. Audit synthetic arrays
  • 6.3.12.16. 15. Split without leakage
  • 6.3.12.17. 16. Fit preprocessing on training only
  • 6.3.12.18. 17. Compare field and synthetic domains
  • 6.3.12.19. 18. Store datasets with provenance
  • 6.3.12.20. Complete 1-D preparation example
  • 6.3.12.21. Review checklist
  • 6.3.12.22. Common mistakes
  • 6.3.12.23. Next steps
• 6.3.13. AI model selection
  • 6.3.13.1. Selection workflow
  • 6.3.13.2. 1. Define the selection objective
  • 6.3.13.3. 2. Decide dimension before architecture
    • Choose 1-D when
    • Choose profile 2-D when
    • Choose graph-context 3-D when
    • What WILLY L18 permits
  • 6.3.13.4. 3. Compare model families
  • 6.3.13.5. 4. Choose the 1-D architecture
    • FCN
    • CNN1D
    • ResNet
  • 6.3.13.6. 5. Choose layer count and target complexity
  • 6.3.13.7. 6. Select solver and feature content
    • Phase
    • Components
    • Frequency grid
  • 6.3.13.8. 7. Select the 2-D U-Net configuration
  • 6.3.13.9. 8. Select graph architecture and adjacency
  • 6.3.13.10. 9. Decide whether joint inversion is justified
  • 6.3.13.11. 10. Decide between supervised, PINN, and hybrid
    • Choose supervised when
    • Choose PINN when
    • Choose hybrid when
  • 6.3.13.12. 11. Decide whether an ensemble is required
  • 6.3.13.13. 12. Establish baselines
  • 6.3.13.14. 13. Define a fair comparison protocol
  • 6.3.13.15. 14. Compare multiple metric families
  • 6.3.13.16. 15. Consider persistence and deployment
  • 6.3.13.17. 16. Use InversionConfig for 1-D candidates
  • 6.3.13.18. 17. Record the selection decision
  • 6.3.13.19. Complete selection example
  • 6.3.13.20. Selection checklist
  • 6.3.13.21. Common mistakes
  • 6.3.13.22. Next steps
• 6.3.14. Training AI inversion models
  • 6.3.14.1. What fit means in pyCSAMT
  • 6.3.14.2. Before starting a run
  • 6.3.14.3. Splits, leakage, and normalization
  • 6.3.14.4. Configuration-first 1-D training
  • 6.3.14.5. Direct 1-D fitting
  • 6.3.14.6. Understanding the training arguments
  • 6.3.14.7. Augmentation is a scientific nuisance model
  • 6.3.14.8. Monitor more than one loss
    • The trainer is a validation-controlled state machine
    • An executed CPU training audit
  • 6.3.14.9. Training a 2-D U-Net
  • 6.3.14.10. Training a graph model
  • 6.3.14.11. Joint and ensemble training
  • 6.3.14.12. PINN and hybrid optimization
  • 6.3.14.13. Reproducible experiment design
  • 6.3.14.14. Failure diagnosis
  • 6.3.14.15. Training completion checklist
• 6.3.15. AI inversion inference
  • 6.3.15.1. Inference workflow
  • 6.3.15.2. 1. Define the inference unit
  • 6.3.15.3. 2. Assemble the approved model package
  • 6.3.15.4. 3. Verify integrity and compatibility
  • 6.3.15.5. 4. Load a 1-D checkpoint
  • 6.3.15.6. 5. Prepare 1-D field features
  • 6.3.15.7. 6. Replay preprocessing exactly
  • 6.3.15.8. 7. Gate out-of-domain inputs
  • 6.3.15.9. 8. Run 1-D prediction
    • Raw parameter vectors
    • LayeredModel output
    • Single synthetic response
  • 6.3.15.10. 9. Run 2-D profile prediction
  • 6.3.15.11. 10. Run graph 3-D prediction
  • 6.3.15.12. 11. Predict graph uncertainty
  • 6.3.15.13. 12. Ensemble inference
    • Reliability and sharpness answer different questions
  • 6.3.15.14. 13. PINN and hybrid inference
  • 6.3.15.15. 14. Decode outputs safely
  • 6.3.15.16. 15. Reconstruct forward responses
  • 6.3.15.17. 16. Apply acceptance rules
  • 6.3.15.18. 17. Batch and resource behavior
  • 6.3.15.19. 18. Export an inference record
  • 6.3.15.20. Complete 1-D inference example
  • 6.3.15.21. Review checklist
  • 6.3.15.22. Common mistakes
  • 6.3.15.23. Next steps
• 6.3.16. AI inversion validation
  • 6.3.16.1. Validation is a claim with a scope
  • 6.3.16.2. The evaluation partitions
  • 6.3.16.3. Freeze the artifact before testing
  • 6.3.16.4. Parameter-space evaluation
  • 6.3.16.5. Model geometry and boundary recovery
    • The aggregation trap is observable, not theoretical
  • 6.3.16.6. Response-space validation
    • The reports answer different questions
  • 6.3.16.7. Baselines and ablations
  • 6.3.16.8. Robustness and stress testing
  • 6.3.16.9. Uncertainty validation
  • 6.3.16.10. Field-data validation
  • 6.3.16.11. Validation by inversion family
  • 6.3.16.12. Failure analysis
  • 6.3.16.13. Worked rejection decision
  • 6.3.16.14. Acceptance criteria
  • 6.3.16.15. Statistical reporting
  • 6.3.16.16. Minimum validation record
  • 6.3.16.17. Validation checklist
• 6.3.17. AI inversion uncertainty
  • 6.3.17.1. What uncertainty should answer
  • 6.3.17.2. Sources of uncertainty
  • 6.3.17.3. Calibration and sharpness must be read together
  • 6.3.17.4. Deep ensembles
    • Choosing the ensemble size
  • 6.3.17.5. Calibration data are a separate resource
  • 6.3.17.6. Conformal prediction intervals
    • Direct conformal use
  • 6.3.17.7. Coverage diagnostics
  • 6.3.17.8. Calibrated posterior samples
  • 6.3.17.9. From parameter uncertainty to model uncertainty
  • 6.3.17.10. Forward-response uncertainty
  • 6.3.17.11. Sensitivity and perturbation tests
  • 6.3.17.12. Out-of-distribution checks
  • 6.3.17.13. Uncertainty for 2-D, graph, joint, and hybrid models
  • 6.3.17.14. Persistence and reproducibility
  • 6.3.17.15. Reporting uncertainty responsibly
  • 6.3.17.16. Common mistakes
  • 6.3.17.17. Decision checklist
• 6.3.18. Hybrid AI and physics inversion
  • 6.3.18.1. Before you run it
  • 6.3.18.2. The two-stage objective
  • 6.3.18.3. 1-D hybrid inversion
  • 6.3.18.4. 2-D hybrid refinement
  • 6.3.18.5. 3-D and graph hybrid workflows
  • 6.3.18.6. Agent-assisted hybrid runs
  • 6.3.18.7. Convergence and stopping
  • 6.3.18.8. Sensitivity design
  • 6.3.18.9. What to compare
  • 6.3.18.10. Reporting requirements
  • 6.3.18.11. Common failure modes
  • 6.3.18.12. Next steps
• 6.3.19. Physics-informed 2-D inversion
  • 6.3.19.1. When to use this workflow
  • 6.3.19.2. Workflow
  • 6.3.19.3. 1. Understand the model parameterization
  • 6.3.19.4. 2. Understand the loss function
    • Data term
    • Vertical regularization
    • Lateral regularization
    • Thickness regularization and constraints
  • 6.3.19.5. 3. Prepare and order profile data
  • 6.3.19.6. 4. Select polarization mode
  • 6.3.19.7. 5. Choose the common frequency grid
  • 6.3.19.8. 6. Choose layer count and depth
  • 6.3.19.9. 7. Select regularization weights
  • 6.3.19.10. 8. Select optimizer controls
  • 6.3.19.11. 9. Run a baseline inversion
    • Executed WILLY smoke test
  • 6.3.19.12. 10. Extract resistivity and thickness
  • 6.3.19.13. 11. Review convergence
  • 6.3.19.14. 12. Review residuals
  • 6.3.19.15. 13. Plot the section correctly
    • Add topography without changing the physics
  • 6.3.19.16. 14. Run TE/TM and regularization scenarios
  • 6.3.19.17. 15. Compare with 1-D and classical 2-D results
  • 6.3.19.18. 16. Use the PINN agent for orchestration
  • 6.3.19.19. 17. Consider hybrid 2-D refinement
  • 6.3.19.20. 18. Assess uncertainty
  • 6.3.19.21. 19. Preserve a run record
  • 6.3.19.22. Complete example
  • 6.3.19.23. Review checklist
  • 6.3.19.24. Common mistakes
  • 6.3.19.25. Next steps
• 6.3.20. AI inversion agents
  • 6.3.20.1. Agent map
  • 6.3.20.2. Common execution contract
  • 6.3.20.3. AgentResult
  • 6.3.20.4. Prepare data before running an agent
  • 6.3.20.5. Deep-learning backend
  • 6.3.20.6. Read every inversion as a contract
  • 6.3.20.7. AIInversionAgent: 1-D workflow
    • Train from synthetic data
    • Run from a local checkpoint
    • Inspect 1-D outputs
    • Executed small-run audit
    • Compare CNN1D, ResNet, and FCN under one contract
  • 6.3.20.8. Inv2DAgent: profile workflow
  • 6.3.20.9. Inv3DAgent: spatial graph workflow
    • What physics="mt3d" now executes
    • Why the frequency grid has to come from the survey
  • 6.3.20.10. EnsembleAgent: uncertainty-aware 1-D workflow
  • 6.3.20.11. PINNInversionAgent
  • 6.3.20.12. ModelZooAgent
  • 6.3.20.13. Checkpoint and output policy
  • 6.3.20.14. Optional LLM interpretation
  • 6.3.20.15. Failure handling
  • 6.3.20.16. Choosing the right interface
  • 6.3.20.17. Review checklist
  • 6.3.20.18. Common mistakes
  • 6.3.20.19. Next steps
• 6.3.21. AI inversion reporting
  • 6.3.21.1. Reporting objectives
  • 6.3.21.2. Recommended reporting workflow
  • 6.3.21.3. 1. Define report status and audience
  • 6.3.21.4. 2. Use linked identifiers
  • 6.3.21.5. 3. Recommended package structure
  • 6.3.21.6. 4. Write a dataset card
  • 6.3.21.7. 5. Write a model card
  • 6.3.21.8. 6. Report model selection
  • 6.3.21.9. 7. Report training behavior
  • 6.3.21.10. 8. Report test metrics in context
    • Model-space metrics
    • Response-space metrics
    • Build structured evidence
    • Structural and decision metrics
    • Performance slices
  • 6.3.21.11. 9. Report field-domain status
  • 6.3.21.12. 10. Report predictions with an output schema
  • 6.3.21.13. 11. Report response reconstruction
  • 6.3.21.14. 12. Report uncertainty and calibration
  • 6.3.21.15. 13. Report classical and independent validation
  • 6.3.21.16. 14. Report figures responsibly
  • 6.3.21.17. 15. Use ReportAgent carefully
  • 6.3.21.18. 16. Handle optional LLM narrative
  • 6.3.21.19. 17. Write the narrative report
  • 6.3.21.20. 18. Build a machine-readable manifest
  • 6.3.21.21. 19. Validate the report package
  • 6.3.21.22. 20. Review and approval roles
  • 6.3.21.23. 21. Monitor deployed models
  • 6.3.21.24. Complete reporting skeleton
  • 6.3.21.25. Release checklist
  • 6.3.21.26. Common reporting mistakes
  • 6.3.21.27. Next steps