Why this page exists
Plansyx outputs feed decisions with real consequences: what to underwrite, where to send a vegetation crew, which corridor to de-energise, how to price a parametric trigger. Buyers in those positions carry liability, and they are right to ask what a model is for before they act on it.
This page is that answer. It states what our models are built to support, the decisions they must not be used for, and the limits that travel with every output. It is written to be read by an underwriter, an engineer or a regulator, not only by a lawyer.
It is also binding. Terms of service, section 4 makes the scope below part of your contract with us.
What Plansyx produces
Every output is one of four things, and the distinction matters when you decide how much weight to put on it.
| Type | Example | What it is |
|---|---|---|
| Observation | FuelPulse fuel condition, soil moisture, NDVI | Measured or retrieved from satellite instruments. Subject to sensor error, cloud cover, swath gaps and retrieval assumptions. |
| Index | iDRI™, SPI, EDDI | A transformation of observations onto a comparable scale. Meaningful relative to its own reference period, not as an absolute physical quantity. |
| Forecast | Ignite10 ignition likelihood, drought onset probability | A probability over a stated horizon and area. It is not a prediction that an event will happen. |
| Scenario | SpreadCast spread runs, AssetImpact exposure | A simulated outcome under stated assumptions. One plausible path, not the expected one. |
Intended uses
The Services are designed, validated and documented for the following purposes.
Insurers and reinsurers
- Hazard input to underwriting and pricing analysis, alongside your own loss experience and actuarial judgment.
- Portfolio accumulation, concentration and scenario stress testing.
- Renewal triage and prioritisation of surveys or risk engineering visits.
- Parametric trigger design, basis risk analysis and independent post event verification.
Electric utilities and infrastructure operators
- Prioritising vegetation management and asset hardening across a network.
- Situational awareness of fuel condition, ignition likelihood and plausible spread near assets.
- Operational readiness planning, including staging and resource pre-positioning.
Agencies, nonprofits and infrastructure bodies
- Preparedness and resilience planning on seasonal to multi-year horizons.
- A shared, documented risk picture for cross agency planning.
- Scenario libraries for exercises and investment cases.
Growers, ranchers and water users
- PRF grid and interval optimisation analytics.
- Identifying gaps between federal cover and actual exposure.
In every case the output is an input to a decision made by a qualified person, not the decision itself.
Uses that are out of scope
Plansyx outputs are not validated for life safety decisions and must not be used as the basis for any of the following. Using them this way breaches Terms of service, section 5.
- Evacuation, shelter or life safety orders. Those belong to emergency management authorities using their own protocols and ground truth.
- Real time firefighting or tactical incident command. Our spread scenarios run at sub-daily time steps on modelled inputs and are not a substitute for observed fire behaviour, aerial reconnaissance or incident intelligence.
- Emergency dispatch or 911 routing. The Services carry no emergency service availability commitment.
- Sole basis for declining, cancelling or non renewing an individual policy, or for denying an individual claim. Use a documented process with human review, your own loss data and an appeal route.
- Individual credit, employment, housing or tenancy decisions, or any decision governed by the Fair Credit Reporting Act. Plansyx is not a consumer reporting agency and its outputs are not consumer reports.
- Parcel level statements of fact about a specific property, such as asserting that a named address is or is not safe. See Resolution and scale.
- Regulatory compliance certification, where a law prescribes a specific method or dataset that we are not delivering.
- Training competing models. Covered in Terms of service, section 5.
If your intended use is not listed in either section, ask us at contact@plansyx.com before you rely on it. We would rather scope it with you than read about it later.
Resolution, scale and what a cell means
A gridded output describes a cell, not a point inside it. Conditions within a cell vary with slope, aspect, micro-climate, irrigation, land management and defensible space, and our models do not see that variation.
| Layer | Native resolution | Smallest sensible unit of decision |
|---|---|---|
| Drought indices, iDRI™ | About 4 km | Water district, county, grid and interval selection |
| Fuel condition, priority areas | 30 to 100 m | Corridor segment, management unit, neighbourhood |
| Ignition likelihood | Model grid cell | Operational zone or corridor, over a day |
| Spread scenarios | Scenario dependent | Landscape, not a street |
Federal index programmes have historically used grids of about 0.25 degrees, roughly 17 by 17 miles. Our drought work at about 4 km is finer than that, and it is still far coarser than a field boundary. Treat any parcel level read-out as an interpolation carrying the uncertainty of the cell it came from.
How to read a probability
Confidence and sensitivity information travels with every output. It is there to be used, not stripped out.
- A ten day ignition likelihood of 0.08 for a cell means that, across many comparable cells and days, about eight in a hundred saw ignition. It says nothing certain about tomorrow in one place.
- A drought index is calibrated against a reference period. Comparing across regions or across index versions without accounting for that is a common and consequential error.
- Scenarios are conditional. A SpreadCast run answers “if ignition occurs here, under these weather assumptions”, and changing the assumption changes the answer.
- Skill degrades with horizon. Sub-seasonal and seasonal outlooks are materially less skilful than a ten day forecast, and we report that skill rather than hiding it.
Do not present an output as more certain than its documentation states, and do not reduce a distribution to a single number in customer facing material without saying so.
Human judgment is required
The Services are decision support, not command and control. Every use in production should have a person who is accountable for the decision, competent to read the output and its uncertainty, and able to override it.
We expect customers to keep a documented process covering who may act on an output, what corroborating evidence is required for consequential decisions, how overrides are recorded, and how affected parties can question a decision. For insurance uses, that process should meet the model governance expectations of your regulator.
Validation and model documentation
Every model ships with documentation: what it predicts, the training and reference period, the inputs, known failure modes, measured skill against historical events, and the population it was validated on.
We publish historical hindcasts and calibration plots against representative events rather than headline accuracy figures, because a single accuracy number hides the cases that matter. Where a model performs poorly for a region, season or hazard type, the documentation says so.
Model documentation ships in the platform alongside each layer, and is available on request during an evaluation.
Versioning, reproducibility and audit
Outputs carry a model version and dataset versions. We archive the inputs and algorithm version behind any Trigger Certificate so that a determination can be reconstructed independently, and so that neither party to a contract can influence an observation after the event.
When a model version changes in a way that materially alters outputs, we record it in the version history and, for affected customers, describe the effect. You can reproduce a prior result by requesting the pinned version.
Retention periods for archived certificate inputs are set in your contract. See also Privacy policy, retention.
Fairness and adverse impact
Hazard exposure is not evenly distributed, and neither is the ability to mitigate it. A model that is accurate about physical risk can still produce unfair outcomes when it drives pricing or availability of cover.
We therefore ask customers using Plansyx in insurance or credit adjacent contexts to test for disparate impact within their own portfolios, to keep a human review path for adverse decisions, and to retain the ability to explain which layer moved a risk. The integrated chain is built so that signals are traceable rather than opaque, which makes that explanation possible.
We do not use protected characteristics as model inputs, and we do not supply demographic data. If you identify an adverse impact you believe originates in our outputs, report it under Reporting a problem.
Data currency, gaps and outages
Satellite products have revisit intervals, cloud cover, swath gaps and processing latency. Composites fill gaps by design, and a composite labelled over a date range is not a snapshot of its last day.
Upstream providers can delay, revise or withdraw a dataset. When that materially degrades an output we will flag the affected layer in the platform and, for contracted customers, notify your named contact. Where a layer is stale, the platform shows its observation date. Check it before acting on a time sensitive decision.
Reporting a problem
If an output looks wrong, if a model appears to be failing for a region or a season, or if you believe a decision went badly because of something we produced, tell us. We would rather know.
Everything goes to contact@plansyx.com. Put one of these at the start of the subject line so it reaches the right person:
- Model for a model or data concern.
- Security for a suspected vulnerability. Please tell us before you disclose it publicly, and we will work with you in good faith.
- Anything else needs no prefix.
Include the layer, the region, the dates and the model version if you have it. We aim to acknowledge within two business days, and we record substantiated issues in the model documentation.