Data Normalization

From a math and physics point of view, it only makes sense to compare things that are supposed to be the same. However there are factors that incorporate discrepancies between the data. It can be from differences in orbit, from the camera sensors that are used and so on. Therefore we'll need to be aware of the degrees of freedom for the system/satellite data.

Per-satellite degrees of freedom

For individual satellites it can be:

1. 6-Directional Position — This would be the position of the satellite in 3D space and its orientation in 3D space. This should actually be changed to orbital parameters (Semi-major axis, Eccentricity, Inclination, Right ascension of the ascending node, Argument of periapsis, True anomaly) instead of cardinal directions (Up, Down, Left, Right, Forward, Backward). Either way its equivalent to 6-degrees of freedom and a change in coordinate system is needed to compare them.
2. 3-Degrees of Rotation — Degrees of rotation don't change in space since rotation is only relative to the satellite itself not to some other body.
3. Spectral Sensitivity — This would be the range of wavelengths that the cameras/sensors are sensitive to. Probably the most important consideration since this will be what changes most between satellite types. Everything else can be accounted for through software but this can't.
4. Temporal Resolution — This would be the time it takes for the satellite to capture data.
5. Spatial Resolution — This would be the resolution of the data that the satellite captures.
6. Zoom — This would be the zoom level of the satellite which would determine how much area of the earth its actually seeing. For example one sat could capture a 100km x 100km area while another could capture a 10km x 10km area.
7. Exposure Time — This would be the exposure time of the satellite.

Cross-satellite factors

Between different satellites we have to account for:

1. Exposure Pattern — Possibly different between capturing data through scanning a 1D array of pixels over time using the satellite's movement (Pushbroom) and capturing data through a 2D array of pixels at a single moment in time (Snapshot).

These differences that arise with the degrees of freedom of the satellites are what make it difficult to compare data between different satellites and lead to the following problems and open questions.

Spectral comparison problems

Some sats for example only capture in specific bands of light, others capture in a wide range of bands.

1. Non-Intersecting Band Problem

Say Sat. 1 has three bands that are only sensitive to Red in 650-700nm, Green in 500-550nm, and Blue in 450-500nm but Sat. 2 has 3 bands at 650-600nm, 450-500nm, and 400-450nm. How are we going to compare them? Especially since in this case they have no overlap in sensitivity.

2. Subset Band Problem

Say Sat. 1 has sensitivity to bands 750-720nm, 650-620nm, 550-520nm and Sat. 2 has sensitivity to bands 740-730nm, 640-630nm, 540-530nm. How do a comparison between a subset and superset of spectral data?

3. Certainty Problem

4. Interband Relationship Problem

Lets try to create a rudimentary mathematical formulation of the problem. Specifically for what the difference of bands means.

For a semi-realistic treatment lets take the difference between two 3-dimensional matrices representing the full range of bands given by two different satellites.

Lets start by stating the problem in specific context then move to the general formulation.

Simplest example

We first want to start with the simplest formulation with the following assumptions:

1. The images of Sat. A and Sat. B are the same size and resolution.
2. The bands of Sat. A and Sat. B are the same.
3. The uncertainty of the data is not a factor.
4. The images were taken at different times but of the same location from the same satellite.

Say Sat. A has 3 bands/images of size 1024 \times 1024 pixels and Sat. B has 3 bands/images of size 1024 \times 1024 pixels.

Then the difference between the two satellites is the difference between the two matrices with the Hamming distance as the metric.

Suppose we call Sat. A's bands A_1, A_2, A_3 and Sat. B's bands B_1, B_2, B_3. With the set of these matrices being \bar{A} and \bar{B} respectively. That way A_i and B_i are the ith element of the set of matrices.

Definitions

• Sat. A has a=3 bands/images of size N \times M such that:
  • a = number of bands/images, where a \in \mathbb{Z}^+
  • N = number of rows, where N \in \mathbb{Z}^+
  • M = number of columns, where M \in \mathbb{Z}^+
  • A_i = the i-th band/image, where A_i is a matrix of size N \times M
  • \bar{A} = the set of all bands/images, where \bar{A} is a matrix of size a \times N \times M
• Sat. B has b = 3 bands/images of size P \times Q such that:
  • b = number of bands/images, where b \in \mathbb{Z}^+
  • P = number of rows, where P \in \mathbb{Z}^+
  • Q = number of columns, where Q \in \mathbb{Z}^+
  • B_i = the i-th band/image, where B_i is a matrix of size P \times Q
  • \bar{B} = the set of all bands/images, where \bar{B} is a matrix of size b \times P \times Q
• The transfer function from the full range of wavelengths to the bands/images is defined as C for Camera. It takes in the full range of wavelengths possible over essentially infinite resolution and outputs the bands/images finite N \times M resolution.
  • C: {\mathbb{R}^{3+}} \to \mathbb{R_{0 \to 1}}^a \times \mathbb{Z}^{N+} \times \mathbb{Z}^{M+}
• Let \lambda = \{0 \dots \infty\} be the full range of wavelengths. Then \lambda_C = \{min(C), \dots, max(C)\} is the range of wavelengths that the camera/sensor is sensitive to. Finally \bar{\lambda}_C = \{\lambda_1, \dots, \lambda_a\} is the set of the average wavelengths that the sensor can detect.
  • \lambda = \{0 \dots \infty\}
  • \lambda_C = \{min(C), \dots, max(C)\} (should change the variable name to something other than C since its not the function or set of possible function values but the range of wavelengths that the camera/sensor is sensitive to)
  • \bar{\lambda}_C = \{\lambda_1, \dots, \lambda_a\}

Then each of the bands can be represented by a matrix of size n by m and p by q respectively. The set of bands \bar{A} = \{A_1, A_2, \dots, A_a\} and \bar{B} = \{B_1, B_2, \dots, B_b\} where A_i and B_i are matrices of size n by m and p by q respectively and \bar{A} are of dimensionality a \times n \times m and \bar{B} are of dimensionality b \times p \times q.

The field that S is, is yet to be determined but im thinking it has to be a modulo field since the individual values are going to be interpreted as grey scale or intensity at specific wavelengths. Therefore I believe it has to be a field of real numbers between 0 and 1 modulo 1. As far as I recall we need a field in order to make use of vector spaces.

General formulation

• Sat. A has a=3 bands/images of size N \times M such that:
  • a = number of bands/images, where a \in \mathbb{Z}^+
  • N = number of rows, where N \in \mathbb{Z}^+
  • M = number of columns, where M \in \mathbb{Z}^+
  • A_i = the i-th band/image, where A_i is a matrix of size N \times M
  • \bar{A} = the set of all bands/images, where \bar{A} is a matrix of size a \times N \times M
• Sat. B has b = 3 bands/images of size P \times Q such that:
  • b = number of bands/images, where b \in \mathbb{Z}^+
  • P = number of rows, where P \in \mathbb{Z}^+
  • Q = number of columns, where Q \in \mathbb{Z}^+
  • B_i = the i-th band/image, where B_i is a matrix of size P \times Q
  • \bar{B} = the set of all bands/images, where \bar{B} is a matrix of size b \times P \times Q

Let C be the function that partitions the full wavelength space of possible photon wavelengths and gives us the band images as defined by the camera/sensors parameters/specs. That is C takes in a 3D vector of R \times n \times m and outputs a 3D vector of a \times n \times m where a is the number of bands/images that the camera/sensor has. Let us call the actual mapping of wavelengths reflected by the surface of the earth R which

Do we have to take into account just the set of possible wavelengths or do we leave it as all possible wavelengths? (ie: possible wavelengths of light go from 0 to infinity but the earth only reflects a certain range of wavelengths.)

Lets define the set of all possible wavelengths as \Lambda = \{~0 \dots \infty$\} and the set of all possible wavelengths capturable by the sensor as \Lambda_C = \{~\lambda_{min} \dots \lambda_{max}$\}. Then the resulting set of wavelengths represented by the bands is the set \bar{\Lambda}_C = {\lambda_1, \lambda_2, \dots, \lambda_a} where \lambda_i \in \Lambda_C and \lambda_i \neq \lambda_j for i \neq j and a is the number of bands.

A more rigorous re-derivation models the comparison as a five-phase pipeline: from continuous physical ground truth, through the sensor's 3D-to-2D capture, orthorectification onto a shared grid, the difference metrics, and finally the exponential-decay similarity score.

flowchart LR
  gt["Phase 1
Ground truth
(continuous 3D + spectrum)"] --> cap["Phase 2
Raw image capture
(3D→2D sensor model)"]
  cap --> ortho["Phase 3
Orthorectification
(align to shared grid)"]
  ortho --> metrics["Phase 4
Difference metrics
(Δ, MSE, SAM)"]
  metrics --> score["Phase 5
Similarity score
(exp-decay S)"]
      

Phase 1 — The continuous 3D physical reality (ground truth)

Before the satellite takes a picture we should be modeling the reality of the situation as a continuous state of physics. Since we want to be as realistic as possible we want to take into account the Earth's topography and the full electromagnetics spectrum.

• Spatial Domain (Base): Let \Omega \subset \mathbb{R}^2 be the continuous spatial domain of the image with coordinates (x, y).
• Topography: Let h(x, y) be the true continuous height function of the Earth's surface at the coordinates (x, y).
• The 3D Surface Manifold (S): Let S = {(x, y, z) \in \mathbb{R}^3 | z = h(x, y), (x, y) \in \Omega}
• Spectral Domain: Let \Lambda = (0, \infty) be the continuous spectrum of all possible photon wavelengths, with \lambda_i \in \Lambda.
• The True Signal (L): Let L = f(S, \Lambda) be the true spectral radiance reflecting off the 3D point at coordinates (x, y, h(x, y)) and wavelength \lambda_i.

Phase 2 — Raw image capture (the 3D-to-2D sensor model)

The sensors discretize the continuous 3D reality into 2D matrices. The integration occurs over the warped surface area of the terrain, not a flat plane.

Let dA be the surface area element on S, defined as:

dA = \sqrt{1+(∇h)^2}dxdy

• Hardware Specifications: Sat. A captures a bands/images of size n \times m and Sat. B captures b bands/images of size p \times q such that:
  • a, b \in \mathbb{Z}^+
  • n, m, p, q \in \mathbb{Z}^+
• Sensor Footprints: Let S^A_{i,j} and S^B_{i,j} be the specific physical surface patches on S intersected by the instantaneous field of view (IFOV) of the i-th pixel of the j-th band for Sat. A and Sat. B respectively.
• Spectral Response: Let R^{(k)}_A(\lambda) and R^{(k)}_B(\lambda) be the spectral response functions for the k-th band of Sat. A and Sat. B respectively.

The raw capture tensors, \bar{A}_{raw} \in \mathbb{R}^{a \times n \times m} and \bar{B}_{raw} \in \mathbb{R}^{b \times p \times q} are defined element-wise for band k and pixel (i, j) as:

A^{(k,i,j)}_{raw} = P_A(\int_\Lambda(\int\int_{S^A_{i,j}} L(x, y, h(x, y), \lambda) \cdot dA) \cdot R^{(k)}_A(\lambda) \cdot d\lambda) + \mathcal{N}_A

B^{(k,i,j)}_{raw} = P_B(\int_\Lambda(\int\int_{S^B_{i,j}} L(x, y, h(x, y), \lambda) \cdot dB) \cdot R^{(k)}_B(\lambda) \cdot d\lambda) + \mathcal{N}_B

(Where P is the signal-dependent Poisson shot noise, and \mathcal{N} is the Gaussian read noise).

Phase 3 — Pre-processing and co-registration (orthorectification)

To compare the disparate raw matrices they must be projected into a shared coordinate system using an estimated Digital Elevation Model (DEM), \hat{h}(x, y) which is an imperfect representation of the true topography h(x, y). The protocol's canonical DEM is IrisDEM (see §IrisDEM below) — a Foundation-maintained, version-pinned product whose tier (D0 → M1 → V1 → V1+) is fixed by the protocol version, not chosen by the operator.

• Target Space: We defined a unified, resampled vector space \mathbb{R}^{a \times N \times M} where N and M are the dimensions of the target space.
• Transformation Operators: Let \mathcal{T}_A and \mathcal{T}_B be the orthorectification and resampling algorithms that attempt to flatten the 3D perspective and align the pixels for Sat. A and Sat. B respectively.
• Residual Error: Because \hat{h} \neq h and interpolation is a lossy process there will be a residual error \mathcal{E_A} and \mathcal{E_B}

The final aligned tensors ready for analysis are:

\bar{A} = \mathcal{T}_A(\bar{A}_{raw}) + \mathcal{E_A}
\bar{B} = \mathcal{T}_B(\bar{B}_{raw}) + \mathcal{E_B}

Where both \bar{A}, \bar{B} \in \mathbb{R}^{a \times N \times M}. (This is assuming that b = a now).

Phase 4 — The difference metrics

With perfectly dimensioned and aligned tensors we evaluate similarity and detect anomalies using four mathematical formulations:

1. The Difference Tensor (\Delta): An a \times N \times M tensor that represents the absolute difference between the two tensors. Used to visually or algorithmically locate where anomalies or alignment failures exist.

   \Delta = \bar{A} - \bar{B}

2. Mean Squared Error (MSE): A scalar value that represents the average squared difference between the two tensors. Used to determine if the difference is significant enough to be considered an anomaly.

   MSE = \frac{1}{aNM}\sum_{i=1}^{a}\sum_{j=1}^{N}\sum_{k=1}^{M}(\bar{A}^{(i,j,k)} - \bar{B}^{(i,j,k)})^2

   • Note: This would be where I would also include the Frobenius Norm but since it is proportional to MSE it is redundant. It also doesn't help us much since the Frobenius Norm scales infinitely with the dimensions of the images (N and M). That means that a score for an image of 100x100 would be 100x smaller than an image of 1000x1000, even if the relative difference between the two images was the same. MSE is normalized by the number of pixels making the score independent of the image dimensions.
3. Spectral Angle Mapper (SAM): An N \times M matrix isolating changes in physical material (spectral signature) while ignoring changes in illumination or shadow intensity. For the a-dimensional spectral vectors v^{(i,j)}_A and v^{(i,j)}_B at each pixel (i,j)

   SAM_{(i,j)}(\bar{A}, \bar{B}) = \arccos(\frac{v^{(i,j)}_A \cdot v^{(i,j)}_B}{||v^{(i,j)}_A||_2 ||v^{(i,j)}_B||_2})

Phase 5 — Similarity index & scoring

Our feature vector is now strictly:

\mu = [\mu_1, \mu_2, \mu_3]^T

Here \mu is a vector of three independent, normalized properties of the difference between the aligned tensors \bar{A} and \bar{B} with:

• \mu_1 = the Mean Absolute Distance between \bar{A} and \bar{B}.
• \mu_2 = the Mean Squared Error between \bar{A} and \bar{B}.
• \mu_3 = the Mean Spectral Angle Mapper between \bar{A} and \bar{B}.

1. \mu_1 (Mean Absolute Distance): The spatial mean of the Difference Tensor \Delta. This acts as a linear penalty for total absolute deviation.

   \mu_1 = \frac{1}{aNM}\sum_{i=1}^{a}\sum_{j=1}^{N}\sum_{k=1}^{M}|\bar{A}^{(i,j,k)} - \bar{B}^{(i,j,k)}|

2. \mu_2 (Mean Squared Error): The statistical variance. This acts as a quadratic penalty, meaning it heavily punishes a few pixels with extreme noise/error, while being forgiving of tiny, uniform noise.

   \mu_2 = \frac{1}{aNM}\sum_{i=1}^{a}\sum_{j=1}^{N}\sum_{k=1}^{M}(\bar{A}^{(i,j,k)} - \bar{B}^{(i,j,k)})^2

3. \mu_3 (Spectral Angle Mapper): The spatial mean of the SAM matrix. This metric is strictly blind to intensity, penalizing only changes in the physical material (spectral signature).

   \mu_3 = \frac{1}{N \dot M} \sum{SAM(\bar(A), \bar(B))}

Final scoring function

Using the physics based exponential decay model, we define a tuning vector \beta = [\beta_1, \beta_2, \beta_3]^T \in \mathcal{R}^3. These \beta values dictate how aggressively a specific type of error destroys the similarity score.

The Similarity Score \mathcal{S} is defined as:

\mathcal{S}(\mu) = 100 \cdot e^{-\beta \cdot \mu} = 100 \cdot e^{-(\beta_1 \mu_1 + \beta_2 \mu_2 + \beta_3 \mu_3)}

The four-phase pipeline above assumes the residual ortho error \mathcal{E} in \bar{A} = \mathcal{T}_A(\bar{A}_{\text{raw}}) + \mathcal{E}_A is small enough that it does not dominate the difference tensor \Delta. That assumption breaks at oblique view angles: as the satellite's line-of-sight tilts away from the local vertical (the Nadir), terrain-induced parallax grows monotonically with the off-nadir angle, and \mathcal{E} bleeds into MAD, MSE, and SAM as a geometric bias rather than as physical signal. A manifest reporting a steep enough off-nadir angle can therefore be rejected by the similarity matrix not because it is wrong, but because \mathcal{T}_A could not flatten it.

To prevent that, Iris computes a per-AoI per-sensor Effective Nadir Angle \theta_{\text{eff}} — the upper bound on the raw off-nadir angle \theta_{\text{raw}} a manifest may report before validators reject it before Phase 3 ever runs. It is the minimum of three independent caps:

\theta_{\text{eff}}(\text{AoI}, \text{sensor}) = \min\bigl(\theta_{\text{ortho}},\ \theta_{\text{terrain}}(\text{AoI}),\ \theta_{\text{sensor}}(\text{sensor})\bigr)

flowchart TB
  ortho["θ_ortho
orthorectifier accuracy envelope"] --> minCap{"min()"}
  terrain["θ_terrain(AoI)
terrain-ruggedness derate"] --> minCap
  sensor["θ_sensor(sensor)
sensor-model residual cap"] --> minCap
  minCap --> eff["θ_eff
effective nadir angle"]
  raw["manifest θ_raw"] --> gate{"θ_raw ≤ θ_eff ?"}
  eff --> gate
  gate -->|"pass"| phase3["proceed to Phase 3"]
  gate -->|"fail"| drop["dropped before Phase 3
no round credit"]
      

The three independent caps

\theta_{\text{ortho}} — Orthorectifier accuracy envelope

The protocol's geometric stress cap on the active IrisDEM tier (see §IrisDEM). The cap's numeric form evolves by phase per the design_q1_effective_nadir_angle.md decision ladder; the §Open block below summarizes the resolution. Phase trajectory: [Demo v0.0.1] single scalar bar at 10° equivalent, but expressed as a composite stress score \mathcal{S} = \alpha \cdot \sigma_{\text{px/m}} + \beta \cdot \sec(\theta_g) with Foundation-set (\alpha, \beta) (no on-chain vote), flat-earth bilinear + IrisDEM-D0; [MVP v0.1.0] per-sensor table \sigma_{\text{px/m}}^{\text{max}}[\text{sensor}] + sigma_max_default fallback (15°-equivalent for unknown sensors that have cleared the §1.2.3 reputation gate), per-detector-class formulas, DEM-aware 3D + IrisDEM-M1, BRDF term dropped (\beta = 0); [V1 v1.0.0] same shape as MVP but calibrated under the AND-combined §1.4.1.c success metric + provider-supplied RPCs in attestation user_data; [V1+] BRDF-aware similarity kernel revisits whether the \beta radiometric term returns. This is the protocol-wide ceiling — no manifest can exceed it regardless of AoI.

\theta_{\text{terrain}}(\text{AoI}) — Terrain-ruggedness derate

A function of the DEM slope statistics over the AoI: rugged terrain amplifies parallax, so the cap tightens. A working form is

\theta_{\text{terrain}}(\text{AoI}) = \theta_{\text{ortho}} \cdot \frac{1}{1 + \kappa \cdot \overline{\lVert\nabla h\rVert}_{\text{AoI}}}

where \overline{\lVert\nabla h\rVert}_{\text{AoI}} is the mean gradient magnitude of the true topography h(x,y) (in practice, of \hat{h}(x,y) from the active IrisDEM tier) over the AoI, and \kappa is a governance-tunable sensitivity calibrated empirically against the medoid-stability harness in testing_strategies.md. This is what makes the bound Effective rather than nominal: a 30° image over Iowa farmland and the same 30° image over the Andes are not equally orthorectifiable, even with the same \mathcal{T}.

\theta_{\text{sensor}}(\text{sensor}) — Sensor-model residual cap

The largest off-nadir angle for which the published rational polynomial coefficients (RPCs) or rigorous sensor model produce ray directions accurate to within \mathcal{T}'s sub-pixel budget. Sensor-specific; defaults to \theta_{\text{ortho}} for sensors with no published bound. Guards against trusting vendor RPCs past the angle range they were fit on, which is a known failure mode for older constellations.

A manifest passes the geometry check iff \theta_{\text{raw}} \le \theta_{\text{eff}}; otherwise it is dropped before Phase 3 ever runs, and the contributing node accrues no credit for the round (failure semantics in error_handling_strategies.md).

Protocol-economic framing

The looser the envelope cap, the more satellite passes per AoI per day are eligible to contribute to a round, which directly drives data-provider diversity, panel availability, and tail-latency for low-demand regions. The Demo → MVP lift (single-scalar 10°-equivalent → per-sensor \sigma_{\text{px/m}} table) is the single biggest near-term win for orbit eligibility, since the per-sensor table admits high-altitude tasking imagery (Maxar, Planet) that a single near-nadir scalar bar would reject. The architecture.html §2.3 framing of that tradeoff is the protocol-level companion to this section.

The questions originally raised in this section — per-sensor vs. single-constant \theta_{\text{ortho}}, sensor-identity provenance, angle equivalence across heterogeneous sensors, calibration target — resolved into the following protocol shape:

Parameter shape and governance

(design_q1 §1.1) The on-chain knob is a layered scalar + table rather than a single constant. IrisGovernance stores sigma_max_default (a uint16 σ_px/m × 100 cap covering unknown sensors and the demo's single bar) plus a mapping(uint32 sensorId => uint16 sigma_max_centi) per-sensor override table. Rotating a value is a 7-day-timelock soft-governance action (§1.1.2.c); changing the shape (e.g. switching the table to a different key type or adding columns) is a hard fork via MIN_PROTOCOL_VERSION bump per versioning_strategies.md.

Default trajectory: [Demo] 10° equivalent expressed as the composite \mathcal{S} = \alpha \cdot \sigma_{\text{px/m}} + \beta \cdot \sec(\theta_g) with Foundation-set (\alpha, \beta) (§1.3.1.d, §1.4.4.a grid search); [MVP] \beta = 0, per-sensor table populated empirically + 15° fallback for unknown sensors; [V1] same shape, harness-calibrated.

Sensor-identity provenance

(design_q1 §1.2) Sensor identity is explicit in attestation user_data from the demo onward (§1.2.1.b). iris-fetch parses a uint32 sensor_id in-enclave from the GeoTIFF metadata and binds it into the BLAKE2b user_data commitment per architecture.html §5.2 / §5.4. The sensor_id indexes a per-protocol registry mapping(uint32 => SensorMeta) (§1.2.2.d) that the IrisGovernance contract maintains; SensorMeta carries (f, h_s, p, \text{detector\_class}) — the inputs the §1.3.1.b σ_px/m formula needs, so a single registry serves both the envelope lookup and the stress computation.

Adopting the in-enclave parse from demo onward (rather than the hybrid §1.2.1.d "implicit at MVP, explicit at V1") avoids re-rolling every per-vendor iris-fetch build during MVP and closes the "wrong-sensor-claimed" fraud-proof gap from day one. The cost is one per-provider GeoTIFF-metadata parser inside every enclave build.

Unknown-sensor handling (§1.2.3): [Demo] hard-reject; [MVP] graduated hybrid — soft-reject (excluded from medoid, no slash) for a contributor's first 10 successful rounds with that sensor, then fall back to sigma_max_default (the §1.4.5 reputation gate, decided value successful_rounds == 10 for MVP); [V1+] switch to a weighted reputation score once [4.3] simulation-harness data fires either of the two triggers in design_q1 §1.4.5 (medoid-flip-rate correlates with cells that fixed-10-rounds still admits, or the harness produces calibrated score-weighting coefficients against at least one adversarial attack profile). A FraudType::WrongSensorClaimed mismatch slashes regardless of reputation since that path is forgery, not enrollment lag.

Angle-equivalence formula

(design_q1 §1.3) The protocol caps mis-registration per meter of relief rather than raw \theta_{\text{raw}}. The Tier-1 verifier computes

\sigma_{\text{px/m}}(\theta_{\text{raw}}, h_s, f, p) \;\approx\; \frac{\sin\theta_g \cos\theta_g \cdot f}{h_s \cdot p}

per contributor, pulling (f, h_s, p) from the SensorMeta entry keyed by the sensor_id in user_data. Demo wraps this in the composite \mathcal{S}; MVP+ uses σ_px/m alone.

Detector geometry (§1.3.3): [Demo] single sensor-agnostic formula (accepting the approximation error); [MVP] 2–3 per-detector-class variants — pushbroom / whiskbroom / frame — selected by the SensorMeta.detector_class field; [V1] provider-supplied RPCs inside attestation user_data (§1.3.3.c), which iris-fetch commits and Tier-1 uses directly rather than recomputing geometry.

BRDF / atmospheric path-length (§1.3.2): deferred to V1+ — absorbed by the BRDF-aware similarity kernel (next_steps.md V1+ candidate) rather than a separate governance cap. The envelope is geometric across demo and MVP.

Calibration

(design_q1 §1.4) Calibration produces multiple targets per phase, not a single number — see the table in design_q1 §1.4. Highlights:

• [Demo] Single-metric calibration against the fixed pixel-budget target (\mathcal{E} \le 1.5 px median) on a Sentinel-2-only corpus (§1.4.1.a, §1.4.2.a). Foundation grid-searches (\alpha, \beta) before demo round 1 (§1.4.4.a). Cadence: frozen until MVP cut (§1.4.3.a, hard-fork-only governance posture at demo).
• [MVP+] Layered success metric — pixel-budget and medoid-flip-rate (§1.4.1 a+b) — across a Sentinel + Maxar + Planet held-out sample plus iris-sim-generated synthetic perturbations (§1.4.2 b+c). Cadence: Foundation re-runs the harness every 90-day governance epoch and proposes adjustments via the soft-governance timelock (§1.4.3.b).
• [V1] AND-combined strictness (§1.4.1.c) across the tiered §1.4.2.d corpus; if a per-sensor cap can't clear both gates, that sensor exits the registry.

Working approach during MVP development: use the pixel-budget target during ortho development and validate against the medoid-flip-rate target before each governance update to the per-sensor table.

The orthorectifier \mathcal{T} in Phase 3 needs a height function \hat{h}(x, y) to evaluate the sensor's RFM at every output pixel. Two nodes that disagree about \hat{h} produce different orthorectified tensors \bar{A} and surface that disagreement as fake similarity-matrix divergence. Because Iris is a consensus protocol, \hat{h} has to be byte-identical across the committee — which means the protocol cannot just say "use a 30 m DEM" and leave the choice to operators. It has to pin one canonical product.

That product is IrisDEM — a Foundation-maintained, content-addressed reference elevation model, versioned alongside the orthorectifier. IrisDEM rolls out in three tiers, each one a strict superset of the previous tier's coverage and accuracy. The tier in force is a protocol-version constant, not an operator choice.

flowchart LR
  d0["IrisDEM-D0
(Demo) constant-plane"] --> m1["IrisDEM-M1
(MVP) Copernicus GLO-30"]
  m1 --> v1["IrisDEM-V1
(V1) Copernicus ⊕ NASADEM void-fill"]
  v1 --> v1p["IrisDEM-V1+
(post-V1) commercial / radar / LiDAR"]
      

IrisDEM-D0 (Demo) — Constant-Plane

A single reference elevation \hat{h}(x, y) = h_{\text{ref}} per AoI, taken from the AoI bounding-box centroid's published mean elevation. No tile fetch, no interpolation, no DEM raster on disk. Mathematically this is a degenerate DEM — "DEM = constant" — paired with the flat-earth bilinear ortho in iris-normalize::ortho and the demo's single-scalar 10°-equivalent envelope cap (expressed as the composite \mathcal{S} = \alpha \cdot \sigma_{\text{px/m}} + \beta \cdot \sec(\theta_g) with Foundation-set (\alpha, \beta) per design_q1_effective_nadir_angle.md).

Valid only for near-nadir captures over modest relief. Bit-exact across nodes by construction (one float per AoI). Ships with the Phase-1 demo.

IrisDEM-M1 (MVP) — Copernicus GLO-30

A frozen snapshot of Copernicus DEM GLO-30 (ESA, 30 m, derived from TanDEM-X 2011–2015), redistributed by the Iris Foundation as a versioned, content-addressed tile-set. Global coverage including the poles. Permissive license. Pairs with DEM-aware 3D reprojection and the MVP per-sensor \sigma_{\text{px/m}}^{\text{max}}[\text{sensor}] envelope table calibrated against the §1.4.1 a+b harness per design_q1_effective_nadir_angle.md.

The MVP manifest pins a specific Copernicus release (e.g., COP-DEM_GLO-30-DGED__2023_1). Nodes that fetch a different release fail their startup tile-hash check; there is no silent fallback.

IrisDEM-V1 (V1) — Copernicus GLO-30 ⊕ NASADEM (primary + void-fill)

A two-source composite. Copernicus GLO-30 is the primary surface across its native coverage; NASADEM (NASA's reprocessed SRTM, 30 m, 60°N–56°S) fills tiles where Copernicus carries a documented void or low-confidence flag. The composite is not a per-pixel weighted average — each output pixel comes from exactly one source, recorded as a source ∈ {COP, NASA} byte in the per-tile manifest entry.

Why primary + void-fill rather than a weighted blend:

• Determinism is trivial. Per-tile source selection is a discrete choice baked into the manifest, not a floating-point combination that has to be made bit-exact across CPU architectures.
• Failure modes are debuggable. A bad pixel traces to exactly one source, not to a fusion of two.
• Coverage is the only thing this blend is trying to win. Copernicus already wins on quality where it has data; NASADEM only fills holes. A weighted average would degrade Copernicus pixels for no benefit.

Pairs with full DEM-aware 3D reprojection and the V1 per-sensor envelope (same shape as MVP, calibrated under AND-combined success metric per design_q1_effective_nadir_angle.md §1.4.1.c + provider-supplied RPCs inside attestation user_data per §1.3.3.c).

IrisDEM-V1+ (Post-V1) — Commercial / Radar Augmentation

Once IrisDEM-V1's free-tier composite is stable, the Foundation evaluates commercial and adjacent-mission supplements that either lift resolution above 30 m or fill remaining low-confidence regions. Candidates under consideration:

Acceptance gate for any post-V1 augmentation, regardless of source:

1. Strict \mathcal{E} improvement on the iris-sim medoid-stability harness for the tiles it covers, measured against the IrisDEM-V1 baseline.
2. Redistribution license compatible with the Foundation's tile-hosting model, or a clear bilateral arrangement that does not break the chain-of-provenance attestation flow.
3. Determinism preserved. Same per-tile-source-byte mechanism in the manifest; no per-pixel floating-point fusion.

Distribution and pinning (all tiers ≥ M1)

IrisDEM-M1 onward ships as a Foundation-hosted, content-addressed tile-set:

• Each tile (1° × 1° on the WGS84 grid) is a GeoTIFF with deterministic encoding parameters: compression algorithm, tile/strip layout, byte order, and resampling method are all fixed in the IrisDEM spec.
• A manifest file lists (tile_id, blake3_hash, source_layer, version) for every tile in the release.
• The manifest itself is BLAKE3-hashed and the manifest hash is pinned in iris.toml (and, post-MVP, in a governance-managed registry contract).
• Nodes refuse to start if any tile they fetch fails its manifest hash check. There is no silent fallback DEM.
• DEM tile fetches receive the same TLS-in-TEE attestation treatment as the satellite GeoTIFF fetch (architecture.html §5), so the DEM cannot become a soft underbelly for a chain-of-provenance attack.

Tier-to-phase mapping

Implementation tracking

Implementation tasks are tracked in implementation_demo.html (Phases 0 → 4.5) and implementation_mvp.md (Phase 5) under the [X.Y.Z.Ω] convention (Z = stable sub-task / work unit; Ω ∈ .a/.b/.c/.d = product-phase variant; gap-on-no-work where a phase has no work for that sub-task):

• [3.1] IrisDEM Tile Encoding Spec & Reference Encoder — byte-exact GeoTIFF encoder ensuring same input → same BLAKE3 hash across machines. Sub-tasks: [3.1.1] profile pin, [3.1.2] encoder, [3.1.3] CI determinism harness.
• [3.2] IrisDEM Deterministic Resampling Kernel — bit-exact bridge from tiles on disk to \hat{h}(\phi, \lambda) fed into the sensor RFM. Sub-tasks: [3.2.1] trait + test vectors, [3.2.2] per-tier resampler, [3.2.3] cross-platform bit-equivalence harness.
• [2.9] IrisDEM Manifest & Tile Fetch — Foundation tile-hosting, manifest distribution, on-chain registry post-V1. Sub-tasks: [2.9.1] trait + manifest schema, [2.9.2] hosting + URL/registry config, [2.9.3] content-addressed cache + integrity check, [2.9.4] wiring into ortho path.
• [2.10] IrisDEM Fetch through TLS-in-TEE Attestation Envelope — extends the chain of provenance to cover DEM fetches so an attacker can't swap the elevation grid. Sub-tasks: [2.10.1] AttestedDemFetcher adapter, [2.10.2] hostname allowlist + cert policy, [2.10.3] tampered-tile rejection tests.

Each conceptual sub-task carries .a / .b / .c / .d variants for the four product phases (Demo / MVP / V1 / V1+); letters absent from a ladder mean that sub-task has no work for that phase. See implementation_demo.html § Sub-task Numbering Convention for the full rules.

Different missions arrive with different upstream preprocessing already applied and different radiometric conventions. The normalization pipeline cannot assume "one warp fits all" — Sentinel-2 MSI ships orthorectified, in TOA or BOA reflectance, push-broom optical; Sentinel-1 SAR ships in slant-/ground-range geometry with σ⁰ backscatter; Landsat-9 OLI ships orthorectified like Sentinel-2 but with different scaling and calibration; PlanetScope SuperDove arrives analysis-ready. The pipeline therefore looks up a per-tuple preprocessor against the (mission, processing_level, radiometric_units) triple declared in the contributor's Manifest and cryptographically bound into the attestation's user_data (architecture.html §5.3 / §5.4 step 6, [4.5.10]). The dispatch surface is documented at architecture.html §6.1.1; the accepted-tuple matrix lives at parameters.html §14.2.8. This section is the longer-form per-mission narrative.

Sentinels are fleshed out first because (a) Sentinel-2 is the Demo-target mission and (b) Sentinel-1 forces the registry to handle a fundamentally non-optical chain — keeping it adjacent in the matrix surfaces the optical-vs-SAR seam early.

Sentinel-2 MSI (optical, push-broom)

ESA Copernicus operates a constellation of two satellites (Sentinel-2A, Sentinel-2B) carrying the MultiSpectral Instrument (MSI) — 13 spectral bands from 443 nm (Coastal Aerosol) to 2202 nm (SWIR-2) at 10 m / 20 m / 60 m GSD per band. Both satellites share Mission = Sentinel2Msi; sensor_id (per [5.12] SensorRegistry) distinguishes A from B because the response functions per band differ enough to matter for SAM-based metrics.

Two product levels are accepted at Demo:

• (Sentinel2Msi, L1C, Toa) — TOA reflectance scaled by QUANTIFICATION_VALUE = 10_000 (so a pixel value of 5000 means \rho_{TOA} = 0.5). Vendor preprocessing: radiometric calibration ⟶ geometric refinement against ESA's MSI camera model ⟶ orthorectification to UTM zones using PlanetDEM 90 (processing baselines ≤ 04.00) or Copernicus GLO-30 (baselines ≥ 05.00). The output is a per-band GeoTIFF in the AoI's UTM zone, 10980×10980 pixels per 100×100 km tile for 10 m bands.
• (Sentinel2Msi, L2A, Boa) — BOA reflectance from the same L1C chain plus ESA's sen2cor atmospheric correction (Lambertian-flat surface assumption, aerosol optical depth retrieved from band-12 / band-8a ratios, water-vapor from band-9). The L2A package also includes a Scene Classification Layer (SCL) flagging clouds, cloud shadows, vegetation, water, etc.; Demo does not consume SCL but a V1 enhancement could use it to mask the metrics computation.

Iris handler. Both tuples route to the existing pure-Rust orthorectify_with_dem (crates/iris-normalize/src/ortho.rs). Per-pixel parallax correction is applied on top of the vendor-supplied UTM grid — see architecture.html §6.1 concern (a) for the redundancy. The handler is correct (DEM accuracy within the parallax term bounds the residual error) but wastes the vendor's ortho work; a [3.6] V1 follow-up branches on processing_level to skip the DEM term entirely.

Radiometric implications for the similarity metrics: L1C TOA vs. L2A BOA reflectance differ by the atmospheric correction. Two contributors who fetch the same AoI as L1C and L2A respectively will produce measurably divergent tensors — the same physical scene, but in different unit systems. The medoid filter does not automatically reconcile this; mixing levels in a single round produces inflated \mu_1/\mu_2 and possibly \mu_3 scores against the L1C/L2A boundary. The accepted-tuple matrix in §14.2.8 admits both tuples; the operator-level convention (configured per Data Provider in iris.toml) should pick one level per round to keep the cohort homogeneous. Heterogeneity at the level boundary is a forward-compatibility cost the [5.12] parameter table can encode (a per-Provider preferred_processing_level knob that the Requester's DataRequest echoes); not Demo-tier.

Sentinel-1 SAR (C-band, fundamentally non-optical)

ESA Copernicus operates a constellation of two C-band SAR satellites (Sentinel-1A, Sentinel-1C — Sentinel-1B was lost in 2022 and replaced by Sentinel-1C in 2024). The geometry is fundamentally different from optical: SAR measures the round-trip time and phase of a microwave pulse, so pixels are coordinated by range (across-track distance from the antenna) rather than by the optical ground-projection of a focal-plane detector. The radiometry is also different: backscatter coefficient σ⁰ (or γ⁰, β⁰) in linear or dB, not reflectance.

Two product levels are documented at Demo (both fail closed):

• (Sentinel1Sar, L1Grd, Sigma0Db) / (_, _, Sigma0Linear) — Ground Range Detected. Vendor preprocessing: SAR focusing (matched filter against the chirp replica) ⟶ ground-range projection (re-project slant-range pixels onto the WGS84 ellipsoid using the satellite orbit) ⟶ multilook (averaging adjacent slant-range looks for speckle suppression, e.g. 5×1 in Interferometric Wide IW mode) ⟶ thermal-noise correction ⟶ radiometric calibration to σ⁰ (linear, or 10·log₁₀ for dB). The output is a single-polarization or dual-polarization image at ~10 m GSD in IW mode.
• (Sentinel1Sar, L1Slc, _) — Single Look Complex. Per-swath, per-burst, slant-range, complex-valued (preserves phase for interferometry). Each IW scene contains 3 swaths × 9 bursts; TOPS (Terrain Observation with Progressive Scans) deramping is needed before any downstream geometry work.

Iris handler. Neither tuple is supported at Demo. The MVP track adds a dedicated SAR preprocessor with the chain:

1. Orbit-file ingest — replace the broadcast ephemeris in the GRD/SLC product header with the precise orbit file (POE_OPOD) for sub-meter geolocation.
2. (SLC only) Deburst — concatenate the 9 bursts of a swath into a continuous image; TOPS deramping required to remove the Doppler centroid variation.
3. Range-Doppler Terrain Correction — re-project from slant-/ground-range onto the IrisDEM-resampled WGS84 grid using the orbit state vectors and the SAR collinearity equations. This is the SAR analogue of the optical orthorectification but uses a completely different math kernel (no focal length, no detector pitch — the geometry is encoded in the chirp parameters and the satellite ephemeris).
4. Speckle filter — refined Lee filter or 7×7 boxcar to suppress the coherent-imaging speckle noise. Required for the optical similarity metrics to produce stable scores; raw σ⁰ is too noisy.
5. dB conversion (if input is linear σ⁰) — 10 · log₁₀(σ⁰_linear). The MAD / MSE metrics then operate on dB-scale backscatter rather than reflectance; β-tuning (NormalizationConfig.beta_*) is re-calibrated separately for SAR rounds — SAR dynamic range is ~30 dB whereas optical reflectance is bounded in [0, 1].

The MVP track is a separate handler trait impl that registers (Sentinel1Sar, L1Grd, Sigma0Db) and adjacent tuples; it does not share code with the optical handler. Cross-mission medoid rounds (Sentinel-2 and Sentinel-1 in the same cohort) are out of scope until the similarity metrics can normalize across radiometric units — itself a research problem touching the data_normalization.md "Non-Intersecting Band Problem" / "Subset Band Problem" open items.

Other missions (forward-compatibility)

Landsat-9 OLI, PlanetScope, Maxar WorldView-3, Sentinel-3 OLCI, and Sentinel-5P TROPOMI are documented at full row-shape in parameters.html §14.2.8 — including their respective upstream preprocessing chains, the Iris handler outlook (optical-reuse vs. new-impl), and the ⚪ V1+ state markers. That section is the canonical wire-format-aware reference (it uses the iris-core::types::ProcessingLevel enum tuples); this data_normalization.html per-mission narrative ends at the Sentinel-2 / Sentinel-1 deep-dives above because those two are the only Demo-tier missions with active code.

Why the level names cannot be taken at face value. Expanding past the Sentinels means leaving the vocabulary the ProcessingLevel enum is named after. The numeric ladder (L0 raw → L1 calibrated → L2 derived geophysical variable → L3 gridded composite → L4 model output) is standard — it originates with NASA's EOSDIS processing levels and is adopted broadly by ESA, USGS and CEOS — but the letter suffixes are per-mission and do not carry across providers. ESA's L2A is surface reflectance; Maxar's Standard (2A) is a geometric level whose radiometry is still top-of-atmosphere, and it maps to (WorldView3, L1C, Toa). Planet's 3B means orthorectified, not a Level-3 composite. The enum is Iris's normalized vocabulary that vendor names map into, and §14.2.8's vendor-label translation table is what fixes each mapping.

This belongs here rather than only in the parameter reference because the consequence is radiometric, and it lands in this document's metrics. The homogeneity argument above assumes a round's cohort shares a processing level; a product admitted under the wrong level is not caught as a mislabel, because processing_level is bound into the attestation's user_data and the enclave faithfully attested whatever it was asked to fetch. It surfaces instead exactly as the L1C/L2A mixing failure described under Sentinel-2 above — inflated μ₁/μ₂ and possibly μ₃ against a unit-system boundary that no participant declared and no verifier can see. RadiometricUnits is the field that keeps the physics explicit; derive it from what the product is, never from how its level string is spelled. See: glossary § Vendor Level-Name Collision; § Processing Level.

The matrix is intentionally narrow at Demo — fewer accepted tuples means less surface area for radiometric-mismatch ambiguity in the similarity metrics. Each non-Sentinel row in §14.2.8 corresponds to a discrete MVP / V1 / V1+ ticket that lands additively as the network's mission coverage expands. Two cross-cutting expansions worth flagging because they bleed into Sentinel handler choices:

• RPC-based projection (WorldView-3). Vendor-orthorectified products (Sentinel-2 L1C/L2A, Landsat L1TP/L2SP, PlanetScope ortho_*) feed the existing optical_parallax_warp handler. RPC-only products (WorldView's Standard 2A, also most Maxar imagery before delivery customization) need a separate worldview_rpc_warp impl driven by gdalwarp -rpc. Settled in design_q1_effective_nadir_angle.md §1.3.3.c; revisit if a V1+ calibration target needs WV-3's 0.31 m pan-sharpened resolution.
• Non-reflectance radiometry (Sentinel-3 OLCI L1B, Sentinel-1 SAR σ⁰). The Demo-tier metric kernel (μ₁ MAD on reflectance, μ₂ MSE on reflectance, μ₃ SAM on reflectance) is calibrated for the [0, 1] reflectance band. Radiance (W·m⁻²·sr⁻¹·µm⁻¹) feeds μ₁ / μ₃ cleanly but not μ₂ (squared radiance is dimensionally inconsistent with squared reflectance). dB-scale SAR backscatter needs a separate β-tuning entirely — the dynamic range is ~30 dB rather than [0, 1]. V1+ work on the metrics has to encode unit-aware weights, which is itself research territory adjacent to the "Non-Intersecting Band Problem" / "Subset Band Problem" open items below.