We turn geological uncertainty into high-confidence drill-targets.

1. Executive Summary

Terra Intelligence Labs is a Canadian sovereign geospatial intelligence platform. Today, a mining geologist, an agronomist, or a carbon methodologist typically receives raw data as scattered files. Satellite scenes, field-sensor readings, public soil archives, geochemistry assays. The platform brings these together and turns them into decisions with a clear paper trail behind them. Every result comes back with its uncertainty attached and its provenance readable at each step. All of this is organised around a single object, the Area of Interest (or AOI).

The platform is organised into five capability domains: Sense, Locate, Infer, Verify, and Interact. They run on a six-layer AWS infrastructure hosted in ca-central-1. Canadian data residency and Protected B compliance are design constraints, not marketing tags. Algorithms in each domain are chosen for defensibility rather than novelty. Foundation models raise the general capability floor, but they do not build a moat on their own. The real moat is a compounding data flywheel made of proprietary sensor data, region-routed soil ground truth, multi-physics inversion, and a verification trust chain that a validator or a regulator can audit.

Three principles that shape the platform

2. The Platform Frame

Five capability domains describe what the platform does. Six infrastructure layers describe how it is built. The AOI is the query object that binds them together.

The TIL Platform Frame

Five capability domains organised across six infrastructure layers, bound by the AOI

Capabilities · what the platform does

SenseSee the ground.

LocateCommon 10 m grid.

InferSignals into predictions.

VerifyAttach a paper trail.

InteractLet a human decide.

AOI polygonthe unifying query object

Infrastructure · how it is built

L6InteractionNext.js dashboards · MapLibre 2D · deck.gl 3D · API gateway

L5Verification & dMRVAppend-only audit chain · NI 43-101 and Verra methodology anchors

L4Inference & ModelsBand ratios · XGBoost + QRF · CLHS · Kriging · DSM · model registry

L3Fusion & StorageSTAC catalogue · harmoniser · Iceberg tables in the Glue catalogue

L2Ingest & StreamingMSK Serverless · schema-validated topics · idempotent processing

L1Edge & SensingSatellite STAC · field CSV · soil archives · NVS gradiometer plugin

2.1 The five capability domains

The product surface is organised around five capabilities. Every workflow, whether a drill-targeting run, a soil-carbon baseline, or a compliance disclosure draft, is a sequence of these five capabilities acting on a single AOI. The domains are not layers in the deployment sense. They are the vocabulary a customer or partner uses to reason about what the platform is doing.

Capability	Plain framing	Technical scope
Sense	See the ground.	Ingestion of Sentinel-2 and Landsat 8/9 scenes, field-sensor uploads, public soil archives, and the NVS quantum gradiometer stream from a drone.
Locate	Put it on a common grid.	Harmonisation. Reproject to UTM. Resample to a 10 metre grid. Register in a STAC catalogue and in Iceberg tables. The AOI is the spatial filter.
Infer	Turn signals into predictions.	Deterministic mineral indices. XGBoost plus QRF fusion classifier. Kriging and Quantile Random Forest for soil properties. CLHS for site selection.
Verify	Attach a paper trail.	Append-only audit chain. Cryptographic hashes on inputs and outputs. Methodology-anchored disclosure drafts for NI 43-101, SEC S-K 1300, and the Verra VM0047 and VM0042 families.
Interact	Let a human decide.	Dashboards and APIs. A polygon drawer. 3D probability heatmaps. Depth-resolved soil profile viewers. A JSON API for programmatic access.

2.2 The six infrastructure layers

The infrastructure stack sits underneath the capability domains. Each layer is versioned, contract-first, and swappable. The identity provider can change without editing services. The streaming broker can move from serverless to provisioned without changing producers or consumers. The fusion classifier can move from tree ensembles to a fine-tuned foundation model without touching the orchestrator. None of these changes ripples upward, because every layer talks to the next through an interface contract, not through a shared codebase.

Layer	Name	Scope
L1	Edge and Sensing	Source plugins. Satellite STAC ingestors. Field-sensor CSV importer. Batch soil-reference ingestor. Real-time IoT and quantum gradiometer streams.
L2	Ingest and Streaming	MSK Serverless cluster. Schema-validated topics. Dead-letter queues. Idempotent processing.
L3	Fusion and Storage	STAC catalogue on Aurora PostGIS. Harmoniser to a common 10 metre UTM grid. S3 raw, silver, and gold zones as Iceberg tables in the AWS Glue catalogue.
L4	Inference and Models	Sampler. Band-ratio engine. Fusion classifier. Soil digital soil mapping pipeline. Model registry using MLflow. Every model plugs in behind a common ModelHandler interface.
L5	Verification and dMRV	Append-only audit trail with methodology-anchored draft generation. VM0047 for mining ARR pathway. VM0042 for soil-carbon. Disclosure drafts for NI 43-101 and SEC S-K 1300.
L6	Interaction	Next.js dashboards. MapLibre and deck.gl for 2D and 3D. An API gateway with per-tenant JWT scopes. Partner surfaces for common GIS and geology tools.

2.3 The AOI as the unifying query object

Everything the platform stores, computes, and delivers is scoped to an AOI. This has two consequences that matter algorithmically.

• Reasoning is polygon first. A model's inputs are the harmonised covariates within an AOI polygon. Its outputs are rasters or points inside the same polygon. Fan-out across multiple AOIs is the orchestrator's job. This keeps every job's memory and I/O bounded by the AOI area. It also keeps the covariance structures used by kriging and QRF geographically local.
• Provenance is polygon first. Every audit event is tagged with the AOI identifier, the tenant, the model version, the data version, the input hash, and the output hash. A validator, a Qualified Person, or an auditor can replay any past output because every ingredient was named at the time it was used.

3. Sense and Locate. Ingestion and Harmonisation.

How the platform brings in satellite scenes, field readings, and soil archives, and how it places all of them on a common 10 metre grid.

3.1 The sources

The platform ingests three source families and treats each behind the same envelope so downstream code does not have to know which source produced the observation. Every source is a plugin that implements the same three-method interface. The methods are acquire, validate, and publish. Adding a source is writing one more plugin.

Source	Cadence	Envelope
Sentinel-2 Level 2A from ESA	On AOI creation, plus daily poll.	Element 84 STAC references. Only required band windows are pulled at harmonisation time. Raw store holds references, not copies.
Landsat 8 and 9 Level 2 from USGS	On AOI creation, plus daily poll.	Same STAC reference envelope as Sentinel-2.
Field-sensor CSV	Multipart upload.	Fixed core schema of lat, lon, depth, timestamp. Flexible measurements map with unit-tagged values. Units validated, not presence.
Region-routed soil reference	Batch, on release.	OSIS for Ontario. SLC v3.2 and NSDB for rest of Canada. gNATSGO and SSURGO for United States. SoilGrids 250 m as global fallback only.

OSIS is the Canadian soil anchor because it is real, depth-resolved pedon ground truth. It contains 14,154 sites and 41,103 measured horizons. This allows the platform's soil models to be trained on measured data rather than on a global prior. SoilGrids 250 metre is the honest global fallback. It is downgraded and flagged in the coverage mask. It is not the training data of choice where a national or provincial product is better.

3.2 Schema and event envelope

Every ingested observation is written to S3 raw with versioning turned on, then emitted to MSK as a Protobuf event under a versioned topic name. The envelope carries the source identifier, the observation class, the tenant, the AOI (if scoped), a URI pointing to the raw payload, a timestamp, and the schema version. The body is source-specific. Schema evolution is explicit and additive. A new schema version is issued alongside the existing version, not in place of it. Consumers pin the schema version they read. A malformed event is dropped to a dead-letter queue with a rejection reason. It is not silently discarded.

3.3 Harmonisation. The common grid contract.

The Locate capability turns a scene into a raster on a common grid. Every silver raster is EPSG:326XX, the UTM zone for the AOI. Every raster is at 10 metre pixel resolution and is aligned to a global 10 metre grid origin. Every band, every sensor, and every model assumes this. That single decision is what makes multi-source fusion feasible. Sentinel-2 B4 and Landsat B4 land on the same pixel, and a soil property projected from an OSIS pedon lands there too.

The harmonisation pipeline

• Read only the required COG windows for the AOI. Full scenes are not downloaded. The reference is enough.
• Reproject to the AOI's UTM zone. Bilinear for continuous bands, nearest-neighbour for categorical layers.
• Resample to the 10 metre target grid, snapping to the global origin. No manufactured detail without an explicit uncertainty penalty.
• Clip to the AOI polygon with a small buffer that preserves edge continuity in later kriging steps.
• Write to S3 silver as a Cloud-Optimised GeoTIFF (COG) and register an Iceberg manifest entry via Glue. All silver writes are Iceberg-tracked. Schema evolution is explicit and time-travel queries are available.

4. Infer. Mineral Prospectivity.

How the platform turns a Sentinel-2 scene and a small CSV of field assays into a 3D copper-prospectivity heatmap that a geologist can drill against.

Mining Prospectivity Pipeline

From an AOI polygon and a field CSV to a 3D Cu-probability heatmap in a single job

01 AOI drawn Polygon in the web app. Tenant scoped.

02 Ingest Sentinel-2 L2A. Landsat 8/9 L2. Field-sensor CSV.

03 Harmonise UTM reprojection. Resample to 10 m grid. Clip to AOI.

04 Band ratios Iron oxide. Clay. Hydroxyl. Crosta alteration.

05 XGBoost + QRF Trained per job. Pixel probability. Per-pixel σ.

06 Result + audit COG in S3 gold. 3D heatmap. Lineage event.

Every stage emits a lineage event to audit.events.v1 with input hash, output hash, model version, and data version.

4.1 The model stack

The platform uses a hybrid stack. It combines deterministic band-ratio mineral indices, which have decades of exploration-geology behind them, with a small per-job XGBoost classifier and a Quantile Random Forest for uncertainty. The reasoning is simple. A band-ratio panel gives the geologist a physical prior they already trust. The per-job classifier calibrates that prior to the actual assays uploaded for that AOI. The QRF gives every pixel an uncertainty band rather than a single number.

4.2 The band-ratio panel. A physical prior.

Band-ratio mineral indices are ratios of reflectance across specific satellite bands. Each ratio is chosen because it responds to the absorption features of target minerals. They do not need to be trained. Their formulas live in versioned YAML in S3. Adding a new index, for example a propylitic alteration index, is a configuration republish and not a code change.

Index	Sentinel-2 formula	Responds to
Iron oxide	B04 / B02	Ferric-iron-bearing minerals. Gossans and oxidised zones over sulphide bodies.
Clay minerals	B11 / B12	Kaolinite, illite, montmorillonite. Argillic alteration around porphyry systems.
Hydroxyl	B11 / B12 alt tuning	Hydroxyl-bearing minerals. Phyllic alteration.
Ferrous iron	B08 / B11	Ferrous silicates in mafic and ultramafic hosts.
Crosta alteration	PC composite	Alteration halo mapping. Empirical composite of iron oxide and hydroxyl.

4.3 The XGBoost plus QRF fusion classifier

The band-ratio panel is a strong prior. It is not calibrated to the specific geology of a given prospect. The fusion classifier closes that gap. It reads the harmonised ratio stack, samples each ratio at the location of every uploaded field-sensor point, and trains a small XGBoost classifier with the sampled ratios as features and the dominant assay anomaly (for example Cu concentration above the 90th percentile) as the label.

Training defaults are conservative. The classifier uses 500 estimators, a maximum tree depth of 5, a learning rate of 0.05, and 5-fold cross-validation. Overrides are per-job via API and are not hard-coded. The Quantile Random Forest is trained alongside on the same feature stack to produce per-pixel uncertainty bands. The dashboard renders both the probability heatmap and the uncertainty ribbon.

4.4 CLHS site selection. The sampling design problem.

Conditioned Latin Hypercube Sampling (CLHS) is the classical algorithm for choosing where to put a set of ground-sample points. The chosen points jointly represent the full distribution of covariates over the AOI. It is used when a customer wants to plan the next field campaign rather than analyse existing data. The implementation runs CLHS in Fargate using scikit-learn stochastic optimisation over the harmonised covariate stack. The customer specifies the number of points and optional constraints such as no-go zones and minimum spacing. The output is a set of point coordinates written back as a GeoJSON layer. CLHS is well understood, fast for small AOIs, and defensible in a disclosure. It is the default backend for sample design. A quantum backend option is introduced in the companion whitepaper and the classical path is never removed.

5. Infer. Soil Intelligence and Digital Soil Mapping.

How the platform projects depth-resolved soil properties across an AOI using measured pedon ground truth, kriging within coverage, and Quantile Random Forest with per-pixel uncertainty.

Soil Workspace Pipeline

Region-routed reference to a projected property surface with per-pixel uncertainty and an SOC baseline

Region-routed sources

• OSIS (Ontario) · measured pedons · 14,154 sites · 41,103 horizons
• SLC v3.2 + NSDB · Canada outside Ontario · map-unit polygons
• gNATSGO + SSURGO · United States · gridded soil survey
• SoilGrids 250 m · global fallback · downgraded prior only

til-soil-svc · L3–L4

• ◆ Ingest and provenance
• ◆ Coverage flag per AOI
• ◆ Depth harmonisation to GSM depths
• ◆ Kriging and QRF property projection
• ◆ Per-pixel σ retained
• ◆ SOC and SIC split

Delivered outputs

• Property surfaces + uncertainty
• Depth-resolved profile viewer
• SOC baseline stock by GSM depth
• VM0042 soil-carbon disclosure draft

Kriging is applied within the pedon coverage envelope. Outside coverage, QRF is used with a visibly wider σ.Extrapolation is flagged in the coverage mask. Pathfinder metals in OSIS are shown as point overlays with wide σ, never as confident surfaces.

5.1 What the Soil Workspace is

The Soil Workspace is a vertical extension of the platform. It turns the terrain and digital soil mapping stack from synthetic-prior-trained into ground-truth-trained on measured, depth-resolved pedons. It is delivered as a page in the dashboard and a microservice named til-soil-svc. It reuses the AOI service and the terrain engine unchanged and stands up soil organic carbon (SOC) baselines as a distinct measurement, reporting, and verification (MRV) credit class.

5.2 Depth harmonisation. The GlobalSoilMap standard.

Measured soil horizons come from the field with irregular thicknesses that reflect the pedon's actual profile. An A horizon might be 12 cm at one site and 22 cm at another. Downstream models need a common depth grid. The workspace harmonises every horizon to the GlobalSoilMap standard depths of 0 to 5, 5 to 15, 15 to 30, 30 to 60, 60 to 100, and 100 to 200 cm. Harmonisation uses an equal-area quadratic spline. The spline preserves the vertical mass of the property, for example kilograms of carbon per square metre, while resampling to fixed intervals. The uncertainty introduced by harmonisation is retained and carried forward as a component of the per-pixel uncertainty.

5.3 Property projection. Kriging and QRF, honestly bounded.

For each Tier 1 projectable property, the workspace fits a variogram on the harmonised horizon values within a buffered AOI window. It then runs ordinary kriging, or sequential Gaussian simulation for a fully probabilistic surface. The output is a spatial prediction with a per-pixel kriging variance. In parallel, a Quantile Random Forest is trained on the same points with the harmonised covariate stack as features. The two surfaces are combined with a weighting that favours kriging where the AOI is inside the pedon coverage envelope and QRF where it is outside.

Tier	Properties	Treatment
Tier 1. Krigeable.	SOC and Organic C. Sand, silt, clay texture. pH. CaCO₃. Total N. CEC. Exchangeable Ca, Mg, K. Bulk density. Derived SOC stock.	Kriging or QRF projected to the AOI grid with per-pixel uncertainty and a coverage mask.
Tier 2. Overlay only.	Pathfinder metals (Cu, Ni, Pb, Zn) and pedogenic Fe, Al, Mn.	Point overlays and wide-uncertainty background only. Never surfaced as a confident raster. Never used for prospectivity.
Tier 3. Not surfaced.	Hydraulic and water-retention properties. Base saturation. Available K. Nitrate.	Too sparse in source data to project honestly. Kept in ingest path for later work.

5.4 The digital soil mapping job

The digital soil mapping job runs in the same per-job SageMaker spot pattern as the mining fusion classifier. The til-soil-models family plugs into the platform's ModelHandler interface. This means a new soil model, for example an SOC-specific gradient-boosted machine, can be registered and promoted without touching the orchestrator. Training data are harmonised OSIS horizons within the AOI's pedon buffer. Features are the harmonised covariate stack. Targets are the Tier 1 properties. Cross-validation is spatial-blocked, not random-fold, because points within the same field are correlated and random folds inflate cross-validation scores.

6. Verify. The Audit Chain and MRV.

How the platform turns a raster into a disclosure draft that a Qualified Person, a validator, and a registry can all follow, with every ingredient named.

6.1 The verification model

L5 does not just log. It produces three classes of deliverable. All are anchored to the same append-only audit chain, and all are explicitly marked as machine-assisted drafts that a human validator or Qualified Person must sign off on before filing.

Deliverable	Anchoring standard	Delivers
Mining disclosure draft	NI 43-101 in Canada, SEC S-K 1300 in the United States.	Auto-drafted technical report sections with cited lineage. Data sources, model versions, uncertainty bands. Qualified Person edit path per section.
Carbon MRV. ARR pathway.	Verra VM0047 for afforestation, reforestation, and revegetation.	Baseline scenario, additionality argument, monitoring plan, quantification with methodology-anchored inputs.
Carbon MRV. Soil-carbon.	Verra VM0042 family for soil-carbon methodology.	SOC baseline stock by GlobalSoilMap depth. SOC and SIC split. Uncertainty envelope. Monitoring cadence. Distinct credit class from VM0047.

6.2 The audit chain. Event schema and integrity.

Every step of every job, from ingest through harmonise, ratio compute, classify, project, and disclose, emits an audit event to the audit.events.v1 topic. Events are sunk to S3 Iceberg with S3 Object Lock in compliance mode. The event schema carries room for cryptographic signing without a schema change: event_id, timestamp, tenant_id, service, action, resource_type, resource_id, parent_event_id, payload_hash, output_hash, signature, attributes.

6.3 SOC baseline. The algorithm that anchors a credit.

The SOC baseline is the single most consequential number the soil workspace produces. It is the quantity a carbon credit is issued against. The workspace computes SOC stock by GlobalSoilMap depth interval using the standard formula:

Here SOC is the organic carbon content in g per kg, BD is bulk density in g per cm³, D is the layer depth in cm, and CF is the coarse fragment volume fraction between 0 and 1. Every term carries an uncertainty. The workspace propagates these using Monte Carlo simulation with 5,000 draws by default. It reports the 5th, 50th, and 95th percentiles alongside the mean stock. Where inorganic carbon is present, an SOC and SIC split is applied so only creditable organic carbon is reported in calcareous soils. Reporting total soil carbon in a calcareous field would over-credit the project, an error that will not survive a validator's review.

7. Interfaces, Contracts, and Modularity

7.1 The modularity rules

The platform runs on eight modularity rules. Each is enforced in code review and in the continuous integration pipeline. If a proposed component cannot satisfy the rules, the design changes. The rules do not.

Rule	In practice
Interface before implementation	Every service publishes a stable contract in OpenAPI for REST and Protobuf for events before business logic. Implementations swap without consumer edits.
Configuration over hardcoding	No bucket names, topic names, model paths, mineral-index formulas, or thresholds baked in code. Everything reads from S3 config, SSM Parameter Store, or environment variables.
Plugin-style sources	Each ingestor is a SourcePlugin. Adding a source is one more plugin.
Plugin-style models	Each model is a ModelHandler (load, preprocess, infer, postprocess). Adding a foundation-model embedding, a segmentation network, or an inversion is registering a handler.
Auth via OIDC abstraction	Services validate JWTs from a configured issuer URL. Changing identity providers is a configuration change.
Observability via env-controlled exporter	Logs and metrics go through a thin wrapper. Changing the backend is a wrapper swap.
No service writes another service's database	Cross-service state changes happen through the API or through a Kafka event. No backdoors.
Schemas live in a shared contracts repository	All event payloads and API specifications live in a shared repository. Services pin contract versions. Consumers regenerate clients.

7.2 The two interfaces that matter most

SourcePlugin. Every ingestor implements three methods. acquire reaches out to the source. validate checks the payload against the registered schema. publish emits the envelope to MSK. A new source, whether a public archive, a real-time IoT stream, or the quantum gradiometer receiver, is one new plugin. Nothing else in the platform changes.

ModelHandler. Every model implements four methods. Given a version, load returns a ready model. Given inputs, preprocess returns features. Given features, infer returns raw predictions. Given raw predictions, postprocess returns outputs. New models plug in behind the same interface and register with the model registry. The orchestrator does not change when a new handler is added.

7.3 The output schema

Every inference run writes a Cloud-Optimised GeoTIFF (COG) in unsigned 8-bit format scaled from 0 to 255. Alongside the COG, the run writes a JSON metadata sidecar carrying the model version, the training metrics, the AUC or Brier score, feature importances, and, for probabilistic models, the QRF uncertainty raster reference. Every model conforms to this. The dashboard, the tile server, the audit trail, and the disclosure engine all read this shape and no other.

8. Limits and Trade-offs

Every algorithm has a boundary where it stops being reliable. Naming those boundaries openly is what lets a validator sign off on the outputs. Hiding them is what leads to a failed review. This section lays them out.

8.1 Interpolation and extrapolation

Kriging and QRF are reliable inside the envelope of the training points. Outside that envelope, they are extrapolators. The platform flags coverage explicitly in the mask, widens the uncertainty, and does not display a confident surface. Resampling a coarse public grid such as SoilGrids at 250 metre to a fine grid does not create fine information. It creates fine pixels. The Soil Workspace treats SoilGrids as a downgraded prior, not as training data.

8.2 Label quality in the fusion classifier

The dominant assay anomaly rule is a weak label. It works well for dense campaigns where the commodity of interest has a clear geochemical signature, for example Cu. It works less well for polymetallic prospects with mixed signatures. Every deployment runs a calibration step against a benchmark dataset first. Below AUC 0.7, only band-ratio outputs are emitted and the AOI is marked low-confidence.

8.3 Class imbalance

Mineral anomalies are rare by construction. A naive XGBoost fit under class imbalance produces a classifier that is accurate on the majority class and useless on the minority. The platform uses class-weighted XGBoost as the default because it is simpler than synthetic-sample generation and does not manufacture labels. Synthetic Minority Over-sampling (SMOTE) is available under an override flag but is not the default. A customer knows when synthetic samples are in the loop.

8.4 Sample-to-pixel mismatch

Sensor points are point measurements at some depth. Ratios are 10 metre pixel averages. The platform samples the ratio stack at the pixel containing the point. A Gaussian-process model of the spatial covariance is the mathematically correct treatment and is on the roadmap.

8.5 Google Earth Engine licensing

Google Earth Engine's free and non-commercial tier is licensing-incompatible with commercial deliverables. The platform uses Google Earth Engine only for research prototyping. Production analytics run on the AWS-native ingest path. The sovereignty tension with the United States infrastructure is resolved by keeping commercial deliverables on ca-central-1 pipelines.

9. References

1. Hengl, T. et al. (2017). SoilGrids250m. PLOS ONE 12(2). e0169748.
2. Sabins, F. F. (1999). Remote sensing for mineral exploration. Ore Geology Reviews 14(3-4). 157–183.
3. Crósta, A. P. et al. (2003). Targeting key alteration minerals using ASTER imagery and PCA. Int. J. Remote Sensing 24(21). 4233–4240.
4. Chen, T. and Guestrin, C. (2016). XGBoost. SIGKDD. 785–794.
5. Meinshausen, N. (2006). Quantile regression forests. JMLR 7. 983–999.
6. Minasny, B. and McBratney, A. B. (2006). Conditioned Latin hypercube sampling. Computers and Geosciences 32(9). 1378–1388.
7. Arrouays, D. et al. (Eds.) (2014). GlobalSoilMap. CRC Press.
8. Bishop, T. F. A. et al. (1999). Modelling soil attribute depth functions with equal-area quadratic smoothing splines. Geoderma 91(1-2). 27–45.
9. Goovaerts, P. (1997). Geostatistics for Natural Resources Evaluation. OUP.
10. CIM (2014). Definition Standards for Mineral Resources and Mineral Reserves. NI 43-101 companion.
11. SEC (2018). Modernization of Property Disclosures for Mining Registrants. Regulation S-K Subpart 1300.
12. Verra (2023). VM0047. Afforestation, Reforestation and Revegetation. Methodology v1.0.
13. Verra (2020). VM0042. Improved Agricultural Land Management. v1.0 and subsequent updates.
14. Poeplau, C. et al. (2017). Soil organic carbon stocks are systematically overestimated by misuse of bulk density and rock fragment. SOIL 3(1). 61–66.

10. Closing

Terra Intelligence Labs is a Canadian sovereign geospatial intelligence platform. Its defensibility rests on four things: proprietary sensor data, region-routed ground truth, multi-physics inversion models that respect the physics of the ground they are modelling, and a verification trust chain that a Qualified Person or a validator can actually follow. The algorithms are deterministic where that is defensible, learned where learning adds calibration to real data, and uncertainty tagged always. The interfaces are stable so that future evolution stays local. The limits are named openly, because hiding them is what makes a platform fail external review.

The companion whitepaper on Quantum Sensing and Quantum Optimization documents the two quantum threads that connect to this stack. The first is the NVS drone-deployable NV-diamond gradiometer, which is the sensor. The second is a D-Wave hybrid Constrained Quadratic Model backend for sample design, which is the algorithm. Both plug into the interfaces described in Section 7. Neither replaces the classical algorithms above. Both extend them where the physics or the mathematics offers an honest quantum advantage.

1. Executive Summary

There are two quantum ideas inside the Terra Intelligence Labs platform. They are separate technologies, and they belong in one document because they share the same platform, the same audit trail, and the same commercial thesis.

The first is a quantum sensor. The NVS gradiometer is a drone-deployable nitrogen-vacancy (NV) diamond magnetometer that measures magnetic field gradients over a mineral prospect. Its target sensitivity goes beyond what classical fluxgate and Overhauser instruments reach at drone weight and drone speed. The second is a quantum algorithm. A hybrid Constrained Quadratic Model (CQM) solver, executed on the D-Wave Leap hybrid backend, decides where the next ground samples should go so that each drilled metre reduces the most subsurface uncertainty. One is hardware, the other is software. They share the mathematical fact that quantum annealing and spatial sample design walk the same kind of energy landscape. They also share the commercial fact that both extend the platform's moat in the same direction: proprietary signals plus provenance, defended against classical alternatives that come close but are not equal.

Three principles that shape this work

2. Two Threads, One Platform

Where each quantum thread plugs into the six-layer stack, and what a customer sees when it is turned on.

2.1 The two threads

Thread	What it is	Which layer it enters
NVS quantum gradiometer	Drone-deployable NV-diamond magnetometer pair on a carbon-fibre boom. Reads magnetic field gradients over a mineral prospect.	L1. Edge and Sensing. Enters through a new SourcePlugin with a locked event envelope.
Hybrid CQM solver	Quantum backend option for the sample-design step. Constrained Quadratic Model formulation, solved on the D-Wave Leap hybrid solver.	L4. Inference and Models. Enters through a backend select flag on the sampler service. Classical CLHS is the default.

2.2 What the customer sees

From the customer surface, both threads look like additional dials on the platform they already use. The NVS gradiometer becomes another data layer they can turn on in the AOI viewer. It shows as a magnetic-gradient raster with per-pixel uncertainty, sitting alongside band-ratio mineral indices and the fusion-classifier probability heatmap. The quantum sample-design backend becomes a single dropdown on the sample-design job form. The choices are classical (the default) or quantum (opt-in). The solve time and the backend actually used are reported in the result panel. Nothing else in the customer workflow changes when quantum is switched on. That is the point.

2.3 The commercial thesis in one paragraph

A mineral prospect has ten thousand possible sample sites and twenty affordable drills. A soil-carbon project has ten million pixels and a limited budget for pedon collection. Both are search problems in a rugged, high-dimensional landscape where the classical method is spatial simulated annealing. Adding a native quantum backend to that class of problem is neither a leap of faith nor a gimmick. It is asking hardware that anneals in physics to help solve a problem that anneals in software. The NVS gradiometer, in turn, adds a signal that classical drone magnetometers cannot produce at the same sensitivity, weight, and cost point. Together they compound. Better signals feed the same algorithm. Better algorithms decide where to acquire the next signal.

3. The Physical Opportunity

3.1 Magnetic sensing at drone scale. Where the classical instruments stop.

Airborne magnetometry has mapped the subsurface for decades. Fluxgate, Overhauser, and caesium-vapour magnetometers routinely reach roughly 5 nT of noise floor at 1 Hz on airborne surveys. At drone scale, meaning kilogram-class weight, ten-metre flight lines, and low-cost operation, those same physics can be miniaturised but they carry a cost. Fluxgate drone units land around 1.2 to 1.4 kg with roughly 5 nT sensitivity. What that leaves on the table is the gradient. The gradient is the difference in the magnetic field between two points that are close together. This is where the mineral-relevant information actually lives, because the gradient decays with distance more sharply than the field itself. The gradient therefore isolates near-surface anomalies from the geomagnetic background.

For a magnetic dipole source at depth r, the field magnitude falls off as the inverse cube of the distance while the field gradient falls off as the inverse fourth power. Shallow anomalies therefore dominate the gradient signal, and deep sources cancel to first order in a differential measurement.

NV-diamond magnetometry offers a different noise floor and a very different weight budget. Published compact NV magnetometers have reached the tens of nT per √Hz range in sensor heads of a few cubic centimetres, with control electronics still sitting in a separate rack in most laboratory designs. The engineering thesis behind the NVS gradiometer is that a room-temperature NV gradiometer with matched-pair diamonds at the two sensor heads, packaged with the control electronics between them on a carbon-fibre boom, can deliver a gradient measurement at a drone-relevant size, weight, and power point that classical instruments cannot match at the same sensitivity per unit mass.

3.2 Sample design as a search on a rugged landscape

The sample-design problem states as follows. Choose N locations from a very large candidate set so that the drilled or sampled points jointly explain the maximum subsurface uncertainty, subject to hard constraints on budget, spacing, and exclusion zones. It is a combinatorial optimisation problem on a landscape with a rugged energy surface. It has many local minima. It has hard constraints that behave badly under naive relaxation. The classical algorithm currently in the sampler, CLHS, walks that landscape using stochastic annealing over a Latin-hypercube objective. Quantum annealing walks a related landscape in physics. It searches for the low-energy states of an Ising Hamiltonian. Both approaches are searching for the same kind of ground state. Quantum annealing does not always win. For larger and tightly constrained instances, and for the fast re-solve case, the physics of quantum annealing can outperform stochastic classical annealing per unit wall-clock time. The gain is measured on real data, not assumed.

4. The Quantum Sensor. NVS Gradiometer.

NVS Gradiometer Physical Architecture

Split package. Two matched sensor heads on a carbon-fibre boom with central electronics between them.

Sensor Head 1

• CVD NV-diamond plate
• Matched pair with Diatope
• 520 nm laser diode
• Photonics cluster
• Photodiode readout
• CPW microwave delivery
• Bias magnet pair
• TEC + RTD loop

Central Electronics

sits between the heads on the boom

• ◆ Microwave synth 2.6 to 3.1 GHz
• ◆ IQ modulation and amplification
• ◆ Phase-sensitive lock-in DSP
• ◆ Timing and synchronisation
• ◆ On-device feature extraction
• ◆ Power management
• ◆ Ingest link over Ethernet or gRPC

Sensor Head 2

• CVD NV-diamond plate
• Matched pair with Diatope
• 520 nm laser diode
• Photonics cluster
• Photodiode readout
• CPW microwave delivery
• Bias magnet pair
• TEC + RTD loop

Gradient measurement: B(head 1) minus B(head 2). Common-mode noise cancels at first order.Motor field, geomagnetic diurnal, and coherent atmospheric noise are all common-mode.

4.1 The nitrogen-vacancy centre

The nitrogen-vacancy (NV) centre is a point defect in diamond formed by a substitutional nitrogen atom adjacent to a lattice vacancy. Its ground-state electronic spin (S = 1) is optically polarisable at room temperature. Pumping with green light, typically at 532 nm, drives the system into the m_s = 0 sublevel with high fidelity, and the fluorescence in the red band (roughly 650 to 800 nm) depends on the spin state. Applying a microwave field at the ground-state resonance (2.87 GHz at zero applied field) drives m_s = 0 to m_s = ±1 transitions. The resonance shifts linearly with the projection of an external magnetic field onto the NV axis. This is the Zeeman effect.

Here γₑ is the electron gyromagnetic ratio and Bz is the component of the field along the NV axis. Reading out the fluorescence while sweeping or modulating the microwave frequency, a technique called optically detected magnetic resonance (ODMR), yields a magnetometer that works at room temperature, in ambient air, without cryogenics.

NV Centre Ground-State Structure and ODMR Readout

Optical pumping polarises the spin. Microwave drives ground-state transitions. Fluorescence encodes the spin state.

Zeeman shift on the microwave resonance: Δf = γₑ · Bz with γₑ ≈ 28 GHz/TLock-in detection of the fluorescence at the modulated microwave frequency yields the field measurement.

4.2 The NVS gradiometer. Architectural decisions.

The NVS gradiometer is a split-package design. Two identical sensor heads are mounted on the ends of a carbon-fibre boom, with a central electronics enclosure between them. Each sensor head contains an engineered CVD NV-diamond plate that is ¹²C-enriched to suppress spin-bath decoherence, a 520 nm laser diode, an integrated photonics cluster, a photodiode, a microwave delivery structure implemented as a co-planar waveguide on the head PCB, a permanent-magnet bias pair to set the operating point, and a thermoelectric cooler with a temperature-sensor loop. The central box carries the microwave synthesiser, IQ modulation and amplification, the digital signal processing chain, the timing and synchronisation, the on-device feature extraction, the power management, and the ingest link over Ethernet or gRPC on a tether or low-latency wireless.

On-device features leaving the sensor include the real and imaginary components of the spin susceptibility as a function of the microwave modulation frequency, and the spatial derivative of the field magnitude along the flight direction:

Decision	What	Why
Split package, two heads + central box	Sensor heads at boom ends. Electronics between.	Isolates diamonds from the drone's motor field. The gradiometer subtracts common-mode geomagnetic background, leaving the near-surface gradient.
Matched-pair CVD diamonds	Diamond plates procured with paired NV density, depth, ¹²C enrichment.	Common-mode rejection depends on head similarity. Matched pairs turn a differential measurement from a calibration problem into a physics measurement.
On-head PCB integration	All non-optical electronics on one custom PCB per head.	Miniature enclosure cannot accommodate discrete evaluation boards. PCB integration is what turns a bench-top demonstration into a fieldable instrument.
On-device feature extraction	Spin-susceptibility and gradient features computed at the edge.	Reduces bandwidth. Isolates the boundary between hardware and platform ingest. Keeps envelope small enough for tether-free operation.
Room-temperature operation	No cryogenics. Thermoelectric stabilisation only.	The physics allows it. The commercial thesis requires it. Cryogenics eliminate drone deployment.

4.3 The sensitivity target

The NVS gradiometer targets a per-head sensitivity below 5 nT per √Hz at 1 Hz bandwidth. The gradient measurement between the two heads is correspondingly reduced by the common-mode rejection. The 5 nT per √Hz per-head figure sits in the precision and defence tier of published compact NV magnetometers and is achievable with an engineered CVD diamond, careful ODMR contrast optimisation, and phase-sensitive lock-in readout. The gradiometer figure of merit is the noise floor of the difference of the two head measurements at the boom baseline. This depends on the matching of the two heads more than on any single head's absolute sensitivity. The design target for the gradient noise floor is set relative to the classical drone magnetometer benchmark, not to laboratory NV records, because the commercial comparison is against fluxgate and Overhauser drone instruments.

4.4 Drone integration. The magnetic hygiene problem.

A drone motor is a source of magnetic noise several orders of magnitude larger than the field the sensor is trying to measure. Two engineering disciplines mitigate this. The first is the boom. The sensor heads sit at the ends of a carbon-fibre boom whose length is chosen so that the motor field at the head is below the anomaly of interest at expected altitude. The second is common-mode rejection. The gradiometer measures the difference between two matched heads. Any field that both heads see equally, including motor noise, geomagnetic diurnal variation, and coherent atmospheric noise, subtracts out at first order. Residual noise is characterised in flight-test on a magnetically clean airframe before the instrument is deployed on a customer's platform. The boom, the head-mounting geometry, and the on-device feature-extraction firmware are proprietary. The physical principle of common-mode rejection is textbook.

5. Integrating the Gradiometer with the Platform

NVS Gradiometer Integration into the TIL Stack

From on-device features on the drone to a defensible subsurface susceptibility model on the platform

01 Drone flight On-device features · GPS tagged · low-latency link

02 til-nvs-ingestor SourcePlugin validates · writes S3 raw · emits to MSK

03 til-ingest-validator Envelope check · routes to valid or DLQ

04 til-harmoniser 10 m UTM grid · variogram kriging · per-pixel σ

05 til-inversion-svc Tikhonov solve · voxel model · SimPEG based

06 til-fusion-classifier Feature layer into XGBoost + QRF

Every step publishes a lineage event.A Qualified Person can replay the inversion from raw stream all the way to the final susceptibility model.

5.1 The ingest envelope

The gradiometer streams compact features, meaning the on-device spin susceptibility and DC gradient, through the ingest service. This service is a SourcePlugin behind the same L1 interface used by the satellite ingestors and the field-sensor CSV importer. The envelope carries the tenant, the AOI, the flight identifier, the timestamp, the location (GPS tagged), the derived gradient values, and the payload URI for the raw ADC stream if the customer has retained it. The event is emitted to a versioned Kafka topic. Everything downstream of L1 treats a gradiometer event exactly like a Sentinel-2 or a CSV event. It validates the schema, drops malformed to a dead-letter queue, upserts a lineage entry in the audit chain, and hands the observation to the harmoniser.

5.2 Harmonisation

The harmoniser grids the gradient stream to the common 10 metre UTM grid used by every other silver raster on the platform. Because the gradiometer moves continuously along a flight line, this is a point-cloud-to-raster problem, not a scene-to-raster problem. The pipeline runs a per-track drift correction using the tie-line intersections in the flight plan. It then interpolates to the 10 metre grid using variogram-based kriging with a per-pixel uncertainty. This matches the treatment of the soil workspace's pedon interpolation. The discipline is the same and the output shape is the same.

5.3 Multi-physics inversion. From field gradient to subsurface susceptibility.

The gradient raster is not the final product. The customer wants to know what is under the ground. Multi-physics inversion turns the measured magnetic gradient into a three-dimensional model of magnetic susceptibility at depth. The approach uses Tikhonov regularisation with a smoothness prior over a voxelised subsurface, solved with a conjugate-gradient least-squares solver. SimPEG is the reference open-source implementation on which the build is based. The proprietary contribution is the coupled inversion that jointly uses the gradiometer's high-gradient signal and the satellite band-ratio prior as evidence in the same objective function.

Here m is the vector of magnetic susceptibilities in every subsurface voxel. G is the forward operator that maps susceptibilities to the field gradient at every measurement location. d is the observed gradient vector. R(m) is a smoothness regulariser, typically a discrete Laplacian. β is the regularisation weight that trades data fit against smoothness. The gradiometer's contribution to the well-posedness of this problem is that inverting a baseline-corrected gradient is numerically much better-conditioned than inverting the full field. Shallow anomalies dominate the signal instead of being masked by the deep field.

6. The Quantum Algorithm. Hybrid CQM Sample Design.

6.1 The problem

The customer specifies an AOI, a candidate set of possible sample locations (typically the pixel centres of the harmonised covariate grid), a target number of points N, a maximum budget, a minimum inter-point spacing, and a set of no-go zones. The optimisation asks for the subset of N locations from the candidate set that maximises the expected uncertainty reduction across the AOI, subject to the constraints. Expected uncertainty reduction is quantified using the kriging variance surface derived from the current soil or geochemistry model, described in Whitepaper 01. This is a constrained quadratic combinatorial optimisation.

6.2 The classical baseline. CLHS.

The classical implementation runs Conditioned Latin Hypercube Sampling in Fargate. CLHS is a stochastic simulated-annealing algorithm that maintains a candidate set and swaps points in and out to improve the Latin-hypercube coverage of the covariate distribution. It scales well for small N and small candidate sets. It slows down considerably for larger and tightly constrained instances. For the fast re-solve case, where a new assay is added and the plan needs to be recomputed, it has to start again from a hot state without a native way to reuse the prior solution. CLHS is the platform default. It is fast, it is fully in-region, and it is well understood in the geostatistics literature. Quantum earns its place on top of it, not in place of it.

Sample-Design Backend Select

One optional field on the request. Two solve paths. One output shape.

Sample-Design Request AOI · N points · budget · spacing · exclusion zones · solver_backend flag
optional, defaults to classical

solver_backend
value?

Output Same shape · solver_backend_used · solver_time_seconds · GeoJSON points

empty or classical

Classical Path CLHS on Fargate. Simulated annealing over covariates.In region. Fast for small N. Default.

quantum

Quantum Path CQM via D-Wave Ocean SDK. LeapHybridCQMSampler over HTTPS.Leaves region. Per-job time cap.

Fallback rule. The customer always gets a result.
If the quantum path errors, times out, or the token is missing, the service runs the classical CLHS path and marks solver_backend_used = classical_fallback. Quantum is upside, never a dependency.

Every job emits an audit event with the backend used, the solve time, the constraint set, and the token identifier.

6.3 The CQM formulation

The quantum path expresses the same problem as a Constrained Quadratic Model. Each candidate location i becomes a binary decision variable x_i, where x_i equals 1 if the point is chosen and 0 otherwise. The objective is to minimise the following expression.

Here u_i is the kriging variance at candidate i, which is the uncertainty reduction if the point is sampled. The pairwise term c_ij penalises redundant coverage between nearby chosen points, and λ balances marginal value against joint value.

Constraints (all native, no penalty tuning):

The critical property of the CQM form is that all constraints are native. The D-Wave CQM solver accepts equality and inequality constraints directly and enforces them during the annealing process. This means a customer's hard business constraints do not have to be re-expressed as tuned penalty terms in the objective, as they would in a pure QUBO formulation. A budget cap that must be respected exactly is respected exactly. A spacing constraint that must never be violated is never violated.

6.4 The D-Wave Leap hybrid solver. How it actually runs.

The sampler service, when the quantum backend is selected, packages the CQM using the D-Wave Ocean SDK (dwave-ocean-sdk, LeapHybridCQMSampler from dwave.system) and submits it to the D-Wave Leap Solver API. The Leap hybrid solver is a hybrid classical and quantum architecture. A classical driver decomposes the problem, hands sub-instances to the D-Wave Advantage2 quantum annealer, and stitches the results back together. From the sampler service's point of view, this is a REST call with a payload and a solver-time budget. The response is the best feasible solution the hybrid found within the budget, and the service parses it back into the same sample-point output shape as the classical CLHS path. Nothing downstream has to know which backend ran.

6.5 The fallback rule. Never a single point of failure.

A job never fails just because the quantum path is unavailable. If the Leap API errors, times out, or the D-Wave token is missing, the sampler service runs the classical CLHS path instead. It marks the result with solver_backend_used equal to classical_fallback and includes a note in the result panel. The customer always gets a result. This is not a hedge. It is the first-class design decision. Quantum is an upside path, not a dependency.

6.6 The API surface. One field, two paths.

The sample-design request gains a single optional field named solver_backend, with two values, classical or quantum. Empty defaults to the tenant default. Empty tenant default defaults to the platform default, which is classical. A tenant only sees the quantum option when a tenant flag, quantum_solver_allowed, is set. Tenants that must stay in-region never reach the quantum path even by accident. The response gains two fields. solver_backend_used reports one of classical, quantum, or classical_fallback. solver_time_seconds reports the solve time. Every quantum job also carries a per-job solver-time cap so a single job cannot run up an unbounded quantum bill.

7. Architecture. Where Quantum Meets the Stack.

7.1 The NVS gradiometer path from L1 through L5

#	Service	What happens
1	Drone flight and NVS gradiometer	Streams on-device features tagged with GPS position and timestamp over a tether or low-latency link to a ground receiver.
2	NVS ingestor at L1	Consumes receiver stream. Validates schema. Writes raw to S3. Publishes to Kafka.
3	Ingest validator at L2	Validates envelope. Routes to valid topic or DLQ.
4	Harmoniser at L3	Interpolates track to AOI's 10 m UTM grid with per-pixel kriging uncertainty. Writes silver raster.
5	Inversion service at L4	Runs Tikhonov-regularised inversion to produce subsurface susceptibility voxel model. Registers with model registry.
6	Fusion classifier at L4	Consumes susceptibility model as additional feature layer. Improved probability heatmap.
7	Audit service at L5	Every step publishes lineage events. A validator or Qualified Person can replay the inversion from raw stream to final susceptibility model.

7.2 The quantum sample-design path with backend select at L4

#	Service	What happens
1	Dashboard at L6	Customer selects Quantum in sample-design job form. Optional constraints set for budget, spacing, exclusion GeoJSON.
2	API gateway	Request forwarded to sampler service with solver_backend = quantum.
3	Sampler. Classical branch (default)	If empty or classical, runs CLHS on Fargate. Returns points and metrics.
4	Sampler. Quantum branch	Reads kriging variance surface from S3. Constructs CQM using Ocean SDK. Submits to Leap hybrid solver over outbound HTTPS.
5	D-Wave Leap external to AWS	Hybrid classical + quantum decomposition. Sub-instances land on Advantage2 QPU. Result is the best feasible solution within solver-time budget.
6	Sampler. Response assembly	Parses CQM sample set back into same sample-point output as classical. Records solver_backend_used and solver_time_seconds.
7	Fallback	If Leap call errors or times out, service runs classical CLHS and returns result with solver_backend_used = classical_fallback.
8	Audit service at L5	Emits audit event with backend used, solve time, token identifier. Nothing about the CQM leaves an untraceable path.

7.3 Data residency, secrets, and cost guards

Concern	How it is handled
Data residency	Platform stays in AWS ca-central-1. Quantum call leaves the region because Leap is hosted outside AWS. Tenants with strict residency requirements keep the classical default. Dashboard clearly labels any job that will leave the region.
D-Wave token	Stored in AWS Secrets Manager. Never in git. Never in Terraform state. Sampler task role has read access to exactly one secret.
Egress	Outbound-only allowlist to D-Wave Leap Solver API. No inbound rule. If fixed IPs are required, D-Wave publishes static IPs for the Leap region to whitelist.
Cost guard	Every quantum submission carries a per-job solver-time cap. A single job cannot run up an unbounded quantum bill.
Audit chain	Every job emits an audit event with backend used, solve time, constraint set, token identifier. Provenance for a quantum job is identical in shape to provenance for a classical job.

8. Limits and Assumptions

This section lays out the boundary lines: where physics claims rest on public literature rather than measurement, where the quantum algorithm is not always faster, and where the residency posture has real consequences for a customer.

8.1 Physics claims are public-literature-based until measured

The NV-diamond physics of Section 4 is textbook. The sensitivity target of below 5 nT per √Hz per head is grounded in published compact NV magnetometer results and is achievable at that scale. The current NVS build has not yet been flight-characterised at intended altitude and speed. Measured performance will be reported in a separate flight-test document once the first-article prototype is in the air. Nothing in this whitepaper claims a measured on-platform sensitivity. Every number here that has not been measured on the NVS platform is flagged as public literature.

8.2 Quantum is not always faster

For small sample-design instances, meaning a few hundred candidates with loose constraints, CLHS is fast and good. The quantum path earns its place on larger and tightly constrained instances and on the fast re-solve case. Both solve times are reported in the response so a customer can compare the two backends on their own data and make an informed choice. This is a choice, not a promise of speed.

8.3 Data leaves the region on the quantum path

The D-Wave Leap solver is hosted outside AWS. The quantum call is an outbound HTTPS request. A tenant with strict residency requirements such as Protected B or PBMM-adjacent data must keep the classical default. The dashboard says clearly when a job will leave the region. The tenant flag quantum_solver_allowed defaults to off.

8.4 The gradiometer supply chain has real dependencies

Engineered CVD NV-diamond suppliers are few, and matched-pair sourcing is a specialised ask. Backup suppliers exist. Matched pairs are a live supply-chain consideration and are addressed by parallel supplier qualification.

8.5 The quantum backend is one of several possible future backends

The Section 6 formulation targets the D-Wave Leap hybrid CQM solver because it is the best fit for the sample-design problem's constraint structure. It is not the only quantum backend the platform will support. Amazon Braket provides access to gate-model quantum devices such as IonQ and Rigetti and to neutral-atom devices such as QuEra Aquila. Each will suit different problem classes. The backend-select design in Section 7 is deliberately general. Adding another backend is registering another plugin behind the same interface.

9. Beyond CQM. The Roadmap for Quantum Optimisation.

9.1 The optimisation layer

The quantum sample-design backend is the first product in a family of hybrid quantum optimisation services for mineral exploration and soil science. This family deepens the value of every drilled metre and every collected pedon by choosing where the customer's next sample will most reduce their subsurface uncertainty. It is not a new dataset. It is not a new sensor. It is a smarter answer to the question every customer with a limited budget asks. Where should the next sample go? Because the layer is opt-in and additive, it can be offered to customers who already use the platform without disturbing their existing workflow. Because it uses a mathematically honest quantum match, meaning annealing hardware for an annealing problem, it can be defended in a technical review rather than sold as a metaphor.

9.2 Additional backends and problem classes

Backend	Access path	Problem class
D-Wave Leap hybrid CQM (today)	Direct HTTPS from AWS to D-Wave Leap Solver API.	Constrained combinatorial optimisation on rugged landscapes. Sample design. Drill-target selection. Mine-plan sequencing.
Amazon Braket gate model	AWS-native through Braket.	Chemistry-adjacent problems. Mineral-fluid equilibria. Adsorption modelling on soil colloids. Small-molecule reaction pathways for MRV additionality baselines.
Amazon Braket neutral atom	AWS-native through Braket.	Graph-structured problems. Subsurface connectivity. Hydrogeological flow-network optimisation. Pathfinder-anomaly community detection.
Sovereign quantum (future)	Domestic quantum hardware if and when it matures.	The long-term posture. Watched, not built.

9.3 The compounding case. Sensor plus solver.

The two threads in this document reinforce each other. Better signals from the NVS gradiometer feed a better prior into the sample-design objective. Better sample designs from the CQM path acquire more informative next samples that refine the inversion prior. Both threads feed the same audit chain. The compounding advantage does not require the customer to trust a claim they cannot verify. The lineage is right there in the disclosure draft. That is the point of doing hardware and software together. Neither one is the whole moat. The two of them together are compounding and defensible in a way that either one alone is not.

10. References

1. Kadowaki, T. and Nishimori, H. (1998). Quantum annealing in the transverse Ising model. Physical Review E 58(5). 5355–5363.
2. Farhi, E., Goldstone, J., Gutmann, S., and Sipser, M. (2000). Quantum computation by adiabatic evolution. arXiv:quant-ph/0001106.
3. Minasny, B. and McBratney, A. B. (2006). Conditioned Latin hypercube sampling. Computers and Geosciences 32(9). 1378–1388.
4. Doherty, M. W. et al. (2013). The nitrogen-vacancy colour centre in diamond. Physics Reports 528(1). 1–45.
5. Rondin, L. et al. (2014). Magnetometry with nitrogen-vacancy defects in diamond. Reports on Progress in Physics 77(5). 056503.
6. Degen, C. L., Reinhard, F., and Cappellaro, P. (2017). Quantum sensing. Reviews of Modern Physics 89(3). 035002.
7. Barry, J. F. et al. (2020). Sensitivity optimization for NV-diamond magnetometry. Reviews of Modern Physics 92(1). 015004.
8. Nabighian, M. N. et al. (2005). The historical development of the magnetic method in exploration. Geophysics 70(6). 33ND–61ND.
9. Blakely, R. J. (1996). Potential Theory in Gravity and Magnetic Applications. Cambridge University Press.
10. Sturner, F. M. et al. (2021). Integrated and portable magnetometer based on NV ensembles in diamond. Advanced Quantum Technologies 4(4). 2000111.
11. Perdomo-Ortiz, A. et al. (2019). Readiness of quantum optimization machines for industrial applications. Phys. Rev. Applied 12(1). 014004.
12. Ripka, P. (Ed.) (2021). Magnetic Sensors and Magnetometers. 2nd ed. Artech House.
13. Cressie, N. (1993). Statistics for Spatial Data. Rev. ed. Wiley.
14. Tikhonov, A. N. (1963). Solution of incorrectly formulated problems and the regularization method. Soviet Math. Doklady 4. 1035–1038.
15. Aster, R. C., Borchers, B., and Thurber, C. H. (2018). Parameter Estimation and Inverse Problems. 3rd ed. Elsevier.
16. Cockett, R. et al. (2015). SimPEG. Computers and Geosciences 85(A). 142–154.
17. D-Wave Systems (2023). D-Wave Constrained Quadratic Model. D-Wave Ocean Documentation.
18. Lucas, A. (2014). Ising formulations of many NP problems. Frontiers in Physics 2. Article 5.
19. McGeoch, C. C. and Farre, P. (2022). The Advantage2 Prototype. D-Wave Technical Report 14-1063A-A.
20. Amazon Web Services (2024). Amazon Braket Developer Guide.

11. Closing

There are two quantum ideas inside the Terra Intelligence Labs platform. The first is a sensor, an NV-diamond gradiometer that is room-temperature and drone-deployable, with matched-pair diamonds and on-device feature extraction. It targets a sub-5 nT per √Hz per-head sensitivity, well within what published compact NV magnetometers have achieved. The second is an algorithm, a hybrid Constrained Quadratic Model backend for the sample-design step. It is native to a problem class that is a mathematically honest match for hybrid quantum annealing, and it is delivered as an opt-in choice on top of a classical default that never breaks.

Both threads plug into the same six-layer platform. Both leave the same audit trail. Both are defended by real physics or real mathematics rather than by marketing metaphors. And both compound. The sensor produces the signal that trains the model that decides where to acquire the next sample, which then refines the sensor's inversion. That compounding, more than any single number in this document, is what makes the quantum thread worth building. It is also what a customer, a partner, or an investor is engaging with when they engage with the platform.