@photivra/engine 1.5.0 → 2.0.0

package/docs/IMAGE_FORMATION.md

@@ -1,247 +0,0 @@
-# Image-Formation Contract
-
-Release context: **package 1.2.0 candidate / root API 1.2.0**. Subsystem/model versions and dated introduction or measurement records below are independent historical identities; they are not distribution versions. See [developer navigation](DEVELOPERS.md) and [release contract](RELEASE_1_2_0.md).
-
-Photivra's image-formation contract defines **scientific ownership, coordinate semantics, and dependency/coupling boundaries** for current and future camera effects.
-
-It is not a claim that every stage is implemented, and it is not a requirement that renderers execute one literal serial filter chain.
-
-Use:
-
-```ts
-import { getImageFormationContract } from "@photivra/engine";
-
-const contract = getImageFormationContract();
-```
-
-## Six scientific domains
-
-The contract groups image formation into six domains:
-
-1. **scene / ray geometry**
-2. **scene radiance formation**
-3. **lens mapping + pupil / throughput**
-4. **field- and wavelength-dependent PSF**
-5. **time-dependent exposure / readout**
-6. **native sensor sampling -> orientation -> output / display**
-
-These are scientific ownership domains. Some effects couple more than one domain.
-
-Examples:
-
-- scene illumination, material optical response, geometry/visibility, emission, indirect transport, and time belong upstream in `scene-radiance-evaluation`; source metadata or RGB renderer values are not sensor input;
-- focus breathing changes projection/magnification and therefore couples lens mapping to scene projection;
-- lateral chromatic aberration is wavelength/channel-dependent field mapping and may share wavelength basis with the PSF model;
-- illumination vignetting is throughput-only;
-- mechanical/pupil vignetting can change both throughput and PSF/bokeh shape;
-- diffraction consumes the effective pupil and belongs to the PSF domain;
-- rolling readout couples native sensor timing to temporal integration;
-- camera rotation should be evaluable as a function of physical exposure time so global and rolling readout can consume the same motion model.
-
-## Scene-radiance ownership
-
-`scene-radiance-evaluation` is a partial foundation between `scene-ray-projection` and `lens-field-pupil-evaluation`.
-
-Its authoritative quantity is **outgoing scene spectral radiance** produced from illumination, scene geometry/visibility, material response, emission, indirect transport, and physical time. The renderer-neutral scene request/result boundary supplies declared radiance samples; the production composer validates a bound sample and consumes #110 optical throughput. It does not execute a complete scene renderer or establish a measured radiance field.
-
-The existing `SceneRadiometry` metadata remains separate. `absolute-luminance` is a photometric luminance anchor, not a wavelength-resolved radiance field. Likewise, a light-source SPD, RGB HDR environment, source irradiance, and sensor-plane spectral irradiance are different quantities and must not be substituted for one another.
-
-See [Scene Radiance and Illumination](SCENE_RADIANCE_AND_ILLUMINATION.md).
-
-Shared spectral planning now distinguishes continuous support from discrete lines. Continuous scene/optics/sensor factors may share an explicit air/vacuum coverage intersection and breakpoint union. Delta-like line spectra remain wavelength-integrated measures and are summed without a dλ multiplier; they are never converted into synthetic continuous density merely to enter the continuous sensor quadrature path.
-
-Time-varying illumination now uses a separate temporal profile. Source waveforms are relative multipliers evaluated in physical seconds and must be explicitly registered to the capture `first-opening-boundary-phase` reference before flash/flicker can participate in exposure integration. The local exposure window—not total sensor data-readout duration—defines the integration interval. The temporal foundation returns multiplier/time measures only; source magnitude, material/visibility transport, outgoing radiance, optics, sensor response, metering and automatic exposure remain downstream/separate.
-
-## Coordinate spaces
-
-The contract explicitly distinguishes:
-
-- `scene-metric` — scene/world metric coordinates;
-- `image-plane-metric` — optical-axis origin, +X right, +Y up, millimetres;
-- `native-sensor-physical` — optical-axis origin, +X right, +Y down, millimetres;
-- `native-raster` — top-left origin, +X right, +Y down, pixels;
-- `oriented-capture-raster` — explicit physical-orientation transform of native raster coordinates;
-- `output-raster` — digital crop/resampling result;
-- `display` — consumer/display coordinates, which are never authoritative camera-science coordinates.
-
-Native sensor/raster coordinates remain invariant under physical camera orientation.
-
-Use `mapOrientedPhysicalUvToImagePlanePoint()` and
-`mapImagePlanePointToOrientedPhysicalUv()` when a renderer or integration
-boundary must cross between a normalized oriented physical raster region and
-the pre-orientation `image-plane-metric` space. These transforms explicitly
-undo/apply physical orientation and convert the capture contract's physical
-+Y-down basis to/from the optical image plane's +Y-up basis. They do not apply
-projection, distortion, crop, or lens equations, and asymmetric physical bounds
-remain asymmetric.
-
-## Partial ordering and coupling
-
-`requiredUpstreamStages` defines hard scientific dependencies.
-
-`coupledStages` identifies interactions that must not be treated as independent post-processes.
-
-The required-dependency graph is acyclic. Coupling may be bidirectional because it describes shared scientific state rather than execution order.
-
-An implementation may combine stages for performance only when the combination is mathematically equivalent and the public stage/effect semantics remain intact.
-
-## PSF contribution foundation
-
-The `field-wavelength-psf` stage has a dedicated public foundation documented in [PSF and Pupil Foundation](PSF_FOUNDATION.md).
-
-Current implementation:
-- geometric defocus-circle diagnostic;
-- ideal circular-pupil Airy first-zero diagnostic;
-- explicit field/depth/wavelength/pupil context.
-
-Reserved contributions:
-- non-circular diffraction;
-- mechanical pupil clipping;
-- field curvature;
-- field-dependent aberration;
-- field-dependent bokeh.
-
-No combined PSF is currently calculated.
-
-## Temporal basis
-
-Physical time is measured in **seconds from exposure start**.
-
-A normalized `[0,1]` shutter parameter may be derived for an algorithm, but it is not the authoritative time coordinate.
-
-Exposure duration and sensor readout timing are independent:
-
-- global readout does not mean zero motion blur;
-- rolling readout changes when different native sensor locations are sampled/integrated;
-- native readout direction remains defined in native sensor coordinates even when the camera is physically rotated.
-
-This allows later rolling-shutter work to consume the same time-parameterized camera-motion model used for global exposure.
-
-The standalone `calculateSensorReadoutTiming()` foundation now supplies an invariant native-raster spatial readout phase schedule. Its first model is a caller-declared uniform-linear single-axis approximation with independently evidenced data-readout duration and rolling spatial skew. It does not define exposure windows or shutter-curtain motion, and it does not infer physical hardware readout lines from the effective native image raster.
-
-The additive `assessReadoutExposureTimingLinkage()` layer can validate an explicitly evidenced normalized spatial-phase relationship between rolling readout and an electronic exposure boundary. It never infers absolute temporal synchronization; total data-readout duration is not a surrogate for exposure timing, and matching direction/span alone is insufficient evidence of a shared clock.
-
-The standalone `calculateCaptureExposureWindows()` foundation separately describes local opening/closing exposure boundaries. It uses the first opening-boundary phase as its explicit time reference, preserves independent nominal/opening/closing timing, validates positive local duration across the whole active rectangle, and keeps mechanical/EFCS/electronic actuator identity separate from timing. It does not automatically bind those exposure boundaries to sensor readout phase or to the existing camera-rotation time origin.
-
-The standalone `calculateCaptureRotationTrajectories()` bridge now explicitly binds that first opening-boundary phase to `t = 0` of the existing pure-camera-rotation model and evaluates stationary reference rays at local exposure start/end. It remains forward temporal geometry only: it does not consume sensor readout timing, solve the implicit rolling-shutter image warp, or integrate motion blur over the exposure interval.
-
-The additive `calculateCaptureRotationInverseMappings()` layer now supplies an instantaneous destination-to-reference mapping at a caller-selected phase within each local exposure window. Under the current pure-rotation model the inverse is analytic once destination location fixes local capture time, so no iterative solver is used. This remains pre-lens, pre-output temporal geometry and does not replace finite-exposure integration.
-
-The additive `calculateCaptureRotationTemporalQuadrature()` layer now supplies deterministic uniform-midpoint time nodes and separate normalized-average/seconds-valued temporal measures across each local exposure. It preserves the instantaneous inverse mapping as the geometry source of truth but does not itself integrate radiance, visibility, shutter transmission, sensor response, PSF, or output pixels.
-
-## Production composition consumer
-
-The ownership graph is now consumed by a separate production-plan contract.
-
-The production planner:
-
-- expands required upstream stages from this graph;
-- preserves coupled-stage metadata;
-- never creates a second hidden stage order;
-- records modeled-zero, omitted, unsupported, and blocked states explicitly;
-- keeps renderer capability declaration separate from scientific stage ownership.
-
-Current plan schema `0.7.0` supports the physical sample path, attached-RAW processing and the bounded [executed environment capture](PRODUCTION_ENVIRONMENT_CAPTURE.md). Complete declared environment input can execute all fourteen graph stages through RAW and optional output. Sample-only and attachment-only routes preserve their missing upstream blockers; temporal geometry alone does not integrate radiance. See [processed output](PROCESSED_OUTPUT.md) for the attachment boundary. See [V1 composition and consumer map](V1_COMPOSITION_MAP.md) for current consumers and required handoffs.
-
-See [Production Image-Formation Plan](PRODUCTION_COMPOSITION.md).
-
-## Renderer semantics
-
-Renderer implementations may use a bounded real-time preview approximation or a higher-fidelity deterministic reference evaluation, but both must consume the same engine-owned scientific contract.
-
-For geometric warps:
-
-- destination samples are inverse-mapped to source locations;
-- premultiplied-alpha semantics are preserved;
-- scene depth/occlusion order is preserved across warps;
-- renderer backend choice may change implementation/fidelity, not model semantics.
-
-## Sensor ordering and standalone boundaries
-
-The static ordering registry 0.4.0 retains broad foundation/reserved maturity labels; these are not route-specific capability checks. Plan 0.7.0 records actual bounded execution and blockers. The standalone layers below explain each primitive’s ownership and do not negate the separate executed environment route.
-
-The contract owns this sensor ordering. Individual descriptive profiles do not execute the whole path; the bounded environment production route explicitly composes supported terms:
-
-```text
-optical PSF
-  -> sensor optical stack (OLPF / cover glass / microlens)
-  -> photosite / CFA sampling
-  -> photon / charge statistics
-  -> electronic read noise / conversion
-  -> ADC / quantization
-  -> reconstruction (demosaic / remosaic / capture-mode combination)
-  -> physical orientation transform
-  -> output crop / resampling
-  -> display processing
-```
-
-Temporal exposure/readout couples into the photosite/charge stages rather than acting as an unrelated display blur.
-
-The standalone capture-mode profile now describes acquisition sequence, per-frame effective sampling, optional inter-frame sensor offsets, reconstruction-stage labels, processed-image raster, and downstream dependencies. It does **not** implement the reserved CFA/photosite/reconstruction algorithms. A mode's processed raster remains upstream of physical orientation and final output crop/resampling and cannot redefine physical sensor geometry or FOV.
-
-The standalone color-sampling topology profile now describes monochrome, arbitrary periodic mosaic phase/channel assignment, and layered color declarations with an explicitly unresolved spatial relationship. The periodic topology lives on a distinct native sensor sampling-site lattice rather than `NativeImageRaster`; no binding to effective image samples or physical photodiodes is inferred. This metadata foundation does not yet implement the reserved photosite/CFA sampling stage, spectral response, sparse site exceptions, RAW sampling, or reconstruction.
-
-The additive native-effective-raster/color-site binding now provides the missing structural bridge between capture-mode effective samples and monochrome/periodic topology. It requires evidence for the exact native raster relationship and grouped-mode phase, preserves full-frame absolute CFA phase, and reports compact pre-reconstruction source regions/channel counts. This still does **not** implement the reserved photosite/CFA sampling stage: no signal weights, spectral response, photons/electrons, RAW values, aliasing, or reconstruction are calculated.
-
-The standalone sensor optical-stack profile now makes the upstream stack boundary explicit without claiming a complete stack response. Ordered physical component roles and microlens presence are descriptive. Effective anti-aliasing response is separately modeled as unknown, absent, present-but-unresolved, or a normalized native-physical point-splitting approximation. The resolver exposes only that AA spatial term; cover/filter transmission/refraction, microlens angular/collection behavior, wavelength/field/polarization dependence, and convolution with the lens PSF remain future work. The profile alone is not a complete optical-stack simulation. The production environment route consumes the supported explicit spatial/response bindings and records approximation limits.
-
-The standalone sensor sampling-aperture profile now supplies explicit native-physical registration for the color-site center lattice and a first geometric sensitive-region footprint. The rectangle is a normalized spatial-area averaging support plus a separately reported geometric area/fraction; it is **not** QE or radiometric collection efficiency. AA point splitting, microlens redirection, diffusion/crosstalk, spectral response, photons/electrons, and RAW values are still absent. This advances the geometry needed by the reserved `photosite-cfa-sampling` stage without claiming that stage is fully implemented.
-
-The additive sensor spatial-quadrature layer now combines the resolved AA point-splitting term with the geometric aperture using deterministic native-physical midpoint nodes. AA is applied by inverse source lookup, the destination site's CFA channel remains fixed, and off-active-area pre-AA source support is preserved. The result is still a geometry/measure plan only: no optical field, spectral response, radiometry, temporal integration, RAW value, or reconstruction is calculated, so the `photosite-cfa-sampling` stage remains reserved.
-
-The additive spatial-sample reducer can now apply those weights to caller-supplied nonnegative linear relative values or physical irradiance. It does not turn a channel ID into spectral filtering, does not integrate over time/wavelength, and does not calculate photons, electrons or RAW codes. Consequently this is still a pre-response site sample and the full `photosite-cfa-sampling` stage remains reserved.
-
-The standalone sensor spectral-response profile now establishes explicit wavelength-dependent meaning for linked semantic channels. It can resolve effective external QE, effective A/W responsivity, or declared filter×detector-EQE at one wavelength while preserving response scope and reusable-data provenance. It performs no spectral irradiance integration, exposure-time integration, photon/electron conversion, or RAW reconstruction, so the complete `photosite-cfa-sampling` and downstream charge stages remain only partially founded/reserved.
-
-The additive sensor spectral-quadrature plan supplies deterministic wavelength nodes and dλ measures without turning them into signal. Response knots and explicit caller breakpoints define segment boundaries, a maximum subinterval width bounds midpoint spacing, and the selected response scope/provenance remain visible. Sensor-response coverage is not treated as scene/optics coverage, response values are not applied, QE is not conflated with A/W responsivity, and continuous-density quadrature does not silently approximate discrete spectral lines.
-
-The shared spectral-coverage layer can now derive the sensor channel's usable range and interpolation knots and combine them with separately declared scene/optics/material coverage. This is planning metadata only. Discrete illumination lines use a separate integrated-line measure path and are not accepted as additional continuous quadrature breakpoints.
-
-The additive spatio-spectral reducer now performs the first explicit spatial × wavelength measure composition for caller-supplied sensor-plane E_lambda(x,y) in W/m²/nm. It requires exact color-profile/channel linkage, retains every required edge/off-frame spatial source sample, caps the Cartesian product, and produces pre-response wavelength-integrated irradiance plus geometric-aperture incident flux.
-
-The additive response-application compatibility gate now checks whether that pre-response result is structurally eligible for a later spectral response. It requires exact response/color/aperture/stack linkage, source-plane compatibility with response scope, matching geometric-aperture normalization, explicit spatial response uniformity/separability, resolved wavelength basis, and compatible reference conditions or an explicit approximation. Full-site-cell and effective-collection-area normalizations remain blocked because the current reducer has not integrated those radiometric area bases.
-
-The additive response operating-range gate evaluates optical input against an evidence-backed linearity range with explicit wavelength applicability, reference conditions, uncertainty and nonlinearity criterion. It distinguishes broadband-total evidence from per-spectral-bin applicability and requires an explicit maximum bin width for the latter. Wavelength-dependent response conversion is authorized only when each spectral bin and the spatially reduced aperture satisfy the declared linearity model. Exposure characteristic-curve linearity, accumulated-charge/full-well saturation, conversion gain, readout electronics and ADC linearity remain downstream temporal/electrical contracts.
-
-The photon-energy wavelength foundation resolves the physical energy-per-photon basis used by EQE conversion. Vacuum wavelengths use exact SI h and c. Air wavelengths must first be converted to vacuum wavelength through a sourced phase refractive index at the exact wavelength, with explicit atmospheric-condition compatibility; no implicit air≈vacuum shortcut is allowed.
-
-The EQE electron-rate foundation applies the photon-domain response conversion after all prior gates. It evaluates each wavelength-bin radiant-power contribution independently, divides by photon energy to obtain incident-photon rate, applies effective external QE through the authoritative spectral-response resolver, and sums expected generated-electron rates with compensated summation.
-
-The sibling A/W responsivity foundation applies the current-domain response independently per wavelength bin and sums detector-terminal photocurrent magnitude. Its calibration is additionally bound to explicit detector bias and current-readout load conditions. This current is not treated as electron rate, accumulated charge, transimpedance voltage, or circuit-polarity truth.
-
-Both paths still stop before exposure-time integration, accumulated-charge/full-well behavior, stochastic noise, analog electronics, ADC/RAW and reconstruction.
-
-The local sensor-rate/exposure binding carries each engine-produced response rate back to its exact color-sampling site, through an evidenced one-to-one native-effective-raster relationship, and into the authoritative local shutter-window schedule. This establishes which local time interval belongs to that rate but deliberately does not assume the rate is constant through the interval.
-
-The constant-rate temporal-integration foundation now permits rate × local-duration only under a stationarity declaration bound to the exact site/window. EQE rates produce fractional expected photon/electron counts; A/W current produces photocharge magnitude in coulombs without carrier inference.
-
-The dark-current foundation adds pre-compensation thermally generated expected electrons to the EQE-side charge model using exact local exposure duration and explicit temperature applicability. It does not model black-level compensation, hot-pixel/defect excess, leakage/injection, dark-current nonuniformity unless separately evidenced, or dark-current shot-noise realization. A/W integrated charge is still not treated as stored pixel electrons.
-
-The accumulated-charge completeness foundation combines photo, dark and explicitly incremental other stored-electron expectations only when all terms bind to one exact local exposure. Completeness is not inferred from missing components; an evidence-backed declaration must enumerate the supplied additional charge components and state that all material stored-electron contributors are accounted for.
-
-The physical charge-capacity foundation compares the complete expected stored-electron total with an evidence-backed storage limit. It remains an expectation-domain assessment: no stochastic saturation probability, clamp, post-capacity charge, overflow amount, anti-blooming or neighbor redistribution is modeled.
-
-The camera saturation-capacity foundation is separate: it compares dark-corrected photo-signal electron-equivalent expectation against a measured/calibrated camera response-chain capacity. Dark/other stored charge is not added to that signal-domain comparison, and physical full-well is not reused. The first camera-capacity contract does not identify whether analog electronics, ADC/digital clipping, or another stage is the actual limiter.
-
-Stage-specific clipping transfer functions, stochastic noise, analog electronics, ADC/RAW and reconstruction remain downstream.
-
-## Current implementation status
-
-Each stage is labeled:
-
-- `existing-foundation` — the root engine already contains the relevant foundation;
-- `partial-foundation` — some low-level science exists, but the full stage contract is not implemented; spatial camera rotation in the temporal domain plus declared-scale focus breathing, radial distortion, RGB-channel lateral CA, and illumination throughput in the lens-field domain are current examples;
-- `reserved-contract` — ordering/ownership is reserved for future work only.
-
-Do not infer capabilities from a stage merely because it is present in the contract.
-
-## Test Fixture relationship
-
-External consumer fixtures may provide browser regression targets; engine implementation and independent conformance remain the scientific source of truth.
-
-Engine analytical/invariant tests establish model correctness. Test Fixture images provide secondary integration and renderer evidence.
-
-In particular:
-
-- the LDR/sRGB optics target may verify deterministic field/channel mapping behavior;
-- it does not establish spectral lens calibration, MTF, RAW/CFA truth, HDR radiometry, or real-lens performance.

package/docs/LINEAR_CAPTURE_ENCODING.md

@@ -1,25 +0,0 @@
-# Deterministic linear capture encoding: #15C
-
-Release context: **package 1.2.0 candidate / root API 1.2.0**. Subsystem/model versions and dated introduction or measurement records below are independent historical identities; they are not distribution versions. See [developer navigation](DEVELOPERS.md) and [release contract](RELEASE_1_2_0.md).
-
-`calculateLinearCaptureEncoding()` produces format-neutral unsigned 16-bit linear codes from one bounded inline `SimulatedCapture` plane. The exact plane/image-state identity is mandatory. The master stays unchanged; color, WB application, source reference value and upstream capture-saturation history accompany the encoded data. It neither chooses a file format nor invents a color conversion.
-
-Encoding schema `0.1.0` uses one uniform channel mapping. Let B be `blackValue`, b be `blackCode`, R be the source plane's `referenceWhiteValue`, and r be `referenceWhiteCode`. R must exceed B, codes satisfy 0 ≤ b < r ≤ 65535, and all derived ranges/scales must be finite and representable. The continuous code is `b + (sample-B)/(R-B)*(r-b)`; scale is `(r-b)/(R-B)` codes per relative source unit. Same normalization/scale on every channel preserves linear color ratios after subtracting the declared black baseline.
-
-| Contract | Meaning |
-| --- | --- |
-| blackValue / blackCode | Relative source baseline and its integer code; blackCode can reserve room for negative samples. |
-| referenceWhiteValue / referenceWhiteCode | Source normalization and its code; reference white can be below the code maximum to preserve headroom. |
-| representable limits | B − b/scale and B + (65535−b)/scale; these are encoded range limits, not physical capture saturation. |
-| headroomFactor | (65535−b)/(r−b), relative to the above-black reference-white interval. |
-| negativeValues | Explicit reject of any sample < 0, or preserve-if-representable. The latter still obeys the independently declared out-of-range policy. |
-| outOfRange | Explicit reject, or clip to 0/65535 with separate low/high source-sample counts. |
-| rounding | Nearest code; exact binary64 half ties toward the larger code. No dither or hidden stochastic state. |
-
-The implementation compares finite source values with representable limits before arithmetic, so extreme finite samples can clip without overflowing the mapping. Exact black/reference/endpoints return their declared codes; remaining in-range mapped values round with floor(code+0.5). Only endpoint arithmetic roundoff is bounded back to the code interval. Ideal in-range rounding error is at most 0.5/scale source units; this bound excludes clipping and binary64 arithmetic error. No promise of correctly rounded arbitrary-precision real arithmetic is made. NaN/Infinity/sparse source arrays and invalid or numerically unrepresentable ranges fail. Identical validated inputs produce identical codes across the supported JS runtimes.
-
-An encoded maximum or quantized sample at 65535 does not prove sensor saturation, and a sample rounded to an endpoint is not counted as source clipping. Source `captureSaturation` remains upstream history in its original capture domain. `defaultRenderingExposureEv:null` means the encoder selects no rendering exposure or display white. It performs no gain/WB/adaptation, gamma/transfer curve, tone/look/gamut mapping, resampling, RAW reconstruction or recovery of upstream LDR losses.
-
-Output is serializable numbers plus explicit metadata, in row-major interleaved source channel order. `captureMetadata` carries the sanitized source manifest without float planes: geometry/settings, resolved WB intent, adopted white, noise/source identities and model/evidence provenance remain available to serializers. `sourcePlane` carries color/WB/history/saturation and raster/channel identity without float storage. Packing bytes, endianness, checksums, TIFF/DNG tags and required format-specific range restrictions belong to #16; a serializer must honor the declared scientific meaning and reject mappings it cannot represent. XYZ, virtual channels and transformed RGB retain different identities, even if all can be quantized. Quantizing unresolved channels does not establish a usable sensor color profile or a DNG export-readiness claim. External float references remain manifests; this synchronous bounded executor rejects them rather than performing IO or trusting unverified bytes.
-
-Tests share #130 camera/seed metadata with the color tests. They check reference/headroom/clipping invariants, exact half ties and neighbors, offset-preserved negatives, independent negative/range rejection, extreme finite clipping, nonunit source reference/black, retained saturation, color→encoding consistency, deterministic results, state substitution, private/malformed policies and invalid samples/ranges. Implementation and arithmetic fixtures are independently authored, without third-party code/data or new runtime dependencies. Human science/provenance review and contributor DCO certification remain required before inclusion.

package/docs/MOTION_AND_SIGNAL.md

@@ -1,250 +0,0 @@
-# Motion and Signal Foundation
-
-Release context: **package 1.2.0 candidate / root API 1.2.0**. Subsystem/model versions and dated introduction or measurement records below are independent historical identities; they are not distribution versions. See [developer navigation](DEVELOPERS.md) and [release contract](RELEASE_1_2_0.md).
-
-## Projected subject motion
-
-Subject-motion blur is modeled from image-plane displacement rather than broad labels such as "fast sport" or "slow subject."
-
-`calculateProjectedMotionBlur()` projects one representative scene point at shutter open and shutter close after applying constant world-space linear velocity. The difference is the sensor-plane displacement.
-
-Projection has two explicit modes:
-
-- when `focusDistanceM` is omitted, nominal focal length is used as the backwards-compatible infinity-focus/pinhole projection distance;
-- when `focusDistanceM` is supplied, the ideal Gaussian thin-lens image distance for that focus plane is used.
-
-Projected displacement therefore depends on:
-
-- focal length;
-- optional focus-plane extension;
-- shutter duration;
-- starting object position/distance;
-- motion direction;
-- object velocity;
-- optional sensor pixel pitch for pixel-domain reporting.
-
-The low-level motion primitive still accepts one scalar pixel pitch. The newer sensor-geometry API preserves independent X/Y geometric pitch. The composed POC therefore fails closed when X/Y pitch differs by more than 1% rather than silently applying horizontal pitch to materially different vertical sampling.
-
-The model can represent a representative point moving laterally and/or along the optical axis. It does **not** yet model an extended object's changing apparent scale across the exposure, rotational subject motion, acceleration, deformation, or occlusion changes. A large object moving significantly in depth can therefore exhibit real scale blur that this point-displacement primitive does not describe.
-
-Camera motion is not folded into subject motion. Camera shake is modeled separately by `estimateCameraShakeBlur()`; panning detection/intent is not currently modeled.
-
-The returned `deltaXmm`/`deltaYmm` components are legacy camera/image-plane components: +X right and +Y up. They are preserved for compatibility.
-
-Capture raster coordinates use +X right and +Y down. POC API 0.19 therefore converts a legacy image-plane vector to native raster axes as `{ x, y: -y }` before applying the native↔oriented rotation helper. The additive capture diagnostics expose `nativeRasterDeltaPixels`, `orientedCaptureDeltaPixels`, and `outputDeltaPixels`; the legacy motion fields are not reinterpreted.
-
-## Spatial camera rotation
-
-`calculateCameraRotationImageMapping()` now provides the rotation-only primitive reserved by the image-formation contract.
-
-The function:
-
-- accepts one image-plane point at exposure start;
-- uses physical time in seconds from exposure start;
-- accepts constant pitch/yaw/roll angular velocity resolved in the camera axes at exposure start;
-- integrates the simultaneous angular velocity as one axis-angle vector;
-- transforms the stationary world ray by the inverse camera rotation;
-- returns field-position-dependent image-plane displacement;
-- optionally reports axis-aware geometric sample displacement.
-
-For pure yaw/pitch, image displacement varies with field position because the rectilinear projection denominator changes away from the optical axis. Pure roll leaves the optical-axis center fixed while rotating off-axis points.
-
-This is camera **rotation only**. Translation is excluded because parallax requires scene depth.
-
-The returned image-plane/sample components use +X right and +Y up. Native raster remains +X right/+Y down and requires the existing explicit coordinate transform at capture composition boundaries.
-
-## Sensor readout timing
-
-`calculateSensorReadoutTiming()` provides a standalone capture-specific **native sensor scan-timing** foundation.
-
-The model deliberately separates two evidence-backed seconds-valued facts:
-
-- **capture data-readout duration** — the caller's declared duration for the selected capture mode's sensor data-readout operation;
-- **rolling spatial-sampling skew** — the timing span that drives the first-to-last spatial scan phase in the current approximation.
-
-Photivra does not assume those values are equal, and it does not infer an ordering relationship between them. For global readout, spatial skew is zero in this model even when the declared data-readout duration is non-zero.
-
-For rolling readout, the caller also supplies an independently evidenced native scan direction. The current schedule is a `uniform-linear-single-axis` approximation over continuous native raster edge coordinates. This is intentionally **not** a claim that one `NativeImageRaster` row/column equals one physical photodiode row or one hardware readout line. Segmented, center-out, interleaved, multi-tap and other non-uniform schedules remain unsupported rather than being silently approximated as equivalent hardware.
-
-Native sensor timing is orientation-invariant. `calculateSensorReadoutTiming()` therefore does not accept physical camera orientation or output raster geometry. When presentation/capture orientation is needed, callers compose the returned native direction vector with the existing native-to-oriented vector transform. Digital output crop/resolution cannot alter the native timing schedule.
-
-Active-capture timing is also explicit: Photivra never scales a full-frame timing fact by crop dimensions to invent a cropped-mode timing. A caller must provide timing evidence appropriate to the selected capture mode/active area; later capture-mode work can bind those declarations more formally.
-
-Mechanical, electronic-first-curtain and fully electronic shutter mechanisms are reported independently but remain scientifically inert in this slice. The function does **not** define local exposure start/end times, mechanical curtain travel, EFCS curtain interaction, rolling-shutter image distortion, flash/flicker bands, or motion integration. Those later models must combine their own timing with this sensor schedule explicitly rather than treating sensor readout as a surrogate shutter-curtain model.
-
-## Readout/exposure spatial linkage
-
-`assessReadoutExposureTimingLinkage()` is the explicit boundary between the native sensor readout schedule and the capture exposure-window schedule.
-
-The contract deliberately distinguishes **spatial phase/order** from **absolute temporal synchronization**.
-
-A caller may declare:
-
-- `unlinked` — Photivra asserts no relationship for this capture. This is not evidence that the physical processes are independent.
-- `spatial-phase-linked` — one or more electronic exposure boundaries are asserted to share the rolling readout's normalized native spatial phase, either in the same direction or reversed.
-
-Every positive link carries its own provenance. The underlying readout direction/skew and exposure-boundary direction/traversal facts keep their own separate evidence.
-
-A positive spatial-phase link is valid only when:
-
-- sensor readout is rolling and therefore has a spatial scan;
-- the selected exposure boundary is electronic;
-- the selected exposure boundary is itself a uniform-linear native scan;
-- `same` phase orientation uses the same native scan direction;
-- `reversed` phase orientation uses the exact opposite direction on the same native axis.
-
-The rolling-readout spatial skew and exposure-boundary traversal duration do **not** have to be equal. Their dimensionless ratio is reported diagnostically. A ratio of 1 still does not prove a shared clock origin or temporal coincidence.
-
-`captureReadoutDurationSeconds` is preserved with units/evidence but is never used to validate an exposure linkage. Data transfer/readout duration can describe a different physical interval from exposure-boundary traversal.
-
-Absolute temporal alignment remains `not-established` in this foundation. A future mode profile may supply an evidence-backed temporal offset/synchronization relationship if defensible data exists, but Photivra will not infer it from shutter mechanism, scan direction, matching timing spans, output resolution, or adjacent camera specifications.
-
-## Capture exposure windows
-
-`calculateCaptureExposureWindows()` adds the next standalone timing layer after native sensor readout timing.
-
-It represents **opening and closing exposure boundaries separately**. Each boundary can currently be simultaneous or a caller-declared uniform-linear scan in invariant native sensor coordinates. The nominal exposure duration is another independent evidence-backed seconds-valued quantity.
-
-The output time reference is the **first opening-boundary phase**, not a claim that every native location has the same local exposure start. For each point, local start and end offsets are derived independently, and the engine reports local exposure duration.
-
-Mechanical, EFCS, and electronic shutter mechanisms determine only which conceptual actuator owns the opening/closing boundary. They do not invent traversal timing:
-
-- mechanical: mechanical opening and closing;
-- EFCS: electronic opening, mechanical closing;
-- electronic: electronic opening and closing.
-
-The complete active rectangle is validated so a zero/negative local exposure duration cannot hide in an unsampled region.
-
-This contract remains deliberately separate from `calculateSensorReadoutTiming()`. Sensor readout phase is not automatically an exposure boundary. It also remains separate from `calculateCameraRotationImageMapping()`: that API still accepts seconds from its existing exposure-start reference, and the capture rotation and production adapters explicitly bind local capture-window times to that motion basis.
-
-The first exposure-window model does not include curtain acceleration, nonlinear or segmented electronic scheduling, flash/flicker interaction, shutter shock, EFCS-specific pupil/bokeh behavior, or rolling-shutter image distortion.
-
-## Capture rotation exposure trajectories
-
-`calculateCaptureRotationTrajectories()` is the first explicit integration between local capture exposure windows and the existing pure-camera-rotation mapping.
-
-For each caller-selected native raster point, the engine:
-
-1. resolves the point's local exposure start/end with `calculateCaptureExposureWindows()`;
-2. maps that native point into the pre-orientation image plane at the **first opening-boundary phase**;
-3. explicitly binds that capture reference to `t = 0` of `calculateCameraRotationImageMapping()` for this composition;
-4. evaluates the same stationary world ray at the local exposure start and end;
-5. reports the two mapped endpoints plus their image-plane chord.
-
-The output is deliberately a **forward stationary-reference-ray trajectory**, not a rolling-shutter image warp.
-
-That distinction matters because in a rolling capture the exposure/capture time depends on image location while camera motion also changes where a world ray lands. A renderer-ready rolling-shutter transform therefore requires a self-consistent inverse destination-to-source mapping rather than one forward displacement evaluated at a destination coordinate.
-
-The endpoint chord also is **not a blur kernel**. Pure rotational image motion can follow a curved image-plane path, and exposure integrates radiance over the entire local interval rather than only its two endpoints.
-
-Sensor data-readout timing from `calculateSensorReadoutTiming()` is intentionally absent. A particular electronic capture mode may have a documented relationship between sensor readout and exposure boundaries, but Photivra will require that relationship to be declared explicitly rather than assuming it universally.
-
-The trajectory foundation remains rotation-only. Camera translation/parallax, subject motion, panning intent, object rotation/deformation, occlusion changes, exposure integration, flash/flicker, shutter shock, and the final inverse rolling-shutter warp remain future work.
-
-## Capture rotation temporal quadrature
-
-`calculateCaptureRotationTemporalQuadrature()` extends the instantaneous inverse mapping into a deterministic **temporal-geometry quadrature** over each destination point's complete local exposure interval.
-
-The first model uses the uniform midpoint rule. For `N` temporal samples, normalized local phases are:
-
-```text
-phase_i = (i + 0.5) / N
-```
-
-so the exact opening and closing boundaries are not sampled. Each phase is evaluated through the already-public `calculateCaptureRotationInverseMappings()` contract rather than introducing a second camera-motion equation.
-
-Every temporal node reports two different measures:
-
-- `normalizedTimeWeight = 1 / N` — dimensionless weight for a downstream **time average** under the declared uniform temporal-response approximation;
-- `timeMeasureSeconds = localExposureDuration / N` — seconds-valued `dt` measure for a downstream **time integral**.
-
-These are intentionally separate. The seconds-valued measure is not shutter transmission, photon count, radiometric throughput, scene radiance, sensor response, or a calibrated energy measurement.
-
-The local exposure interval remains destination-dependent. A scanned opening/closing schedule can therefore shift node times between sensor locations, and different opening/closing traversal schedules can produce different local durations and therefore different `timeMeasureSeconds` values.
-
-The first temporal-response model is `uniform-over-local-exposure`. That is an explicit approximation. This geometric primitive does not model shutter-transmission ramps or exposure-dependent sensor response. Registered temporal illumination/manual flash and explicit scene/EQE exposure APIs separately integrate declared changing light; geometry nodes alone provide no radiometric weighting.
-
-The API returns **nodes and weights only**. It does not average reference coordinates, compute a blur radius/kernel, sample scene radiance, resolve visibility/occlusion, or write output pixels. Averaging geometric coordinates is not a substitute for integrating the radiance seen along the time-varying rays.
-
-No geometry-only quadrature error estimate is reported. Image-integration error depends on downstream scene radiance, visibility, texture/edge frequency, and reconstruction as well as the camera trajectory. Renderer/reference implementations can compare increasing temporal sample counts in their radiance domain when convergence evidence is needed.
-
-## Instantaneous capture rotation inverse mapping
-
-`calculateInverseCameraRotationImageMapping()` is the exact inverse of the existing forward pure-rotation ray mapping under the same constant-axis assumptions. Once capture time is known, the captured image-plane ray is rotated analytically back into the exposure-start reference camera frame. There is no numerical root/fixed-point solve.
-
-`calculateCaptureRotationInverseMappings()` composes that inverse with local exposure-window timing.
-
-For each destination native sensor point:
-
-1. the destination point selects its local exposure window;
-2. the caller supplies `localExposurePhase` in `[0, 1]`;
-3. capture time is `start + phase × localDuration`;
-4. the destination native point is mapped into the ideal pre-lens image plane;
-5. the captured ray is analytically inverted to the first-opening-boundary reference frame;
-6. image-plane, native effective-sample, and physically oriented sample displacements are reported.
-
-The phase is mandatory because a finite exposure has no single sharp geometry. Phase `0` means local exposure start, `0.5` is the local temporal midpoint, and `1` is local exposure end. None is automatically privileged as the final rendered image.
-
-This inverse is renderer-oriented in the limited sense that it maps **destination capture location -> reference ray**. It still is not a finite-exposure renderer. Motion blur requires integration over the local interval, with an explicit exposure-weighting model if weighting is not uniform.
-
-Sensor data-readout timing remains absent. A documented mode-specific relationship may later link readout and electronic exposure timing, but no such equality is assumed here.
-
-The mapping is evaluated in the ideal pre-lens image plane. Radial distortion, chromatic aberration, PSF, output crop/resampling, camera translation/parallax, subject motion, occlusion changes, flash/flicker and shutter shock remain separate stages.
-
-Reference rays are not clamped to the active source frame. Under camera motion, a valid captured destination can map to reference geometry outside the available reference image; a renderer must treat that as missing source coverage rather than silently stretching or clamping edge pixels.
-
-The current inverse does not claim that an arbitrary rolling/capture-scan camera is globally one-to-one. More general motion models can produce folds, repeated visibility or other multi-perspective behavior; those cases require additional validity analysis rather than being inferred from this pure-rotation slice.
-
-## Temporal image-formation basis
-
-The image-formation contract defines physical time in **seconds from exposure start**.
-
-The separate spatial camera-rotation model is evaluable at arbitrary supported physical times rather than returning only one finished full-frame displacement. That allows global exposure and later rolling readout to consume the same camera-motion model.
-
-Exposure duration and sensor readout timing are independent concepts:
-
-- global readout can still contain subject/camera motion blur;
-- rolling readout changes the exposure/readout schedule across native sensor locations;
-- physical orientation does not redefine native sensor scan direction;
-- depth-dependent camera translation is not part of the initial rotational-flow model because parallax depends on scene depth.
-
-## Exposure relations
-
-`calculateExposureValue100()` implements EV100 from aperture and shutter duration.
-
-`calculateRelativeOpticalExposure()` compares the proportional image-plane exposure relation `t / N²`.
-
-These calculations do not imply a photon count because they do not include scene radiance, lens transmission/T-stop, vignetting, spectral response, or sensor calibration.
-
-`calculateRelativeRenderedExposure()` combines the relative optical exposure with the nominal ISO gain ratio (`iso / referenceIso`) and reports both the linear factor and stop difference. It is intended for deterministic relative rendering against a declared reference, not for radiometric calibration; it does not model photon creation, sensor noise, clipping, tone mapping, or lens transmission.
-
-`calculateEquivalentIso()` treats ISO as nominal gain/brightness compensation needed to preserve rendered exposure after an aperture/shutter change. It is not used as a shortcut for noise or photon creation.
-
-## Signal/noise primitives
-
-The root package also exports low-level deterministic sensor primitives:
-
-- `calculatePhotoelectrons()`: caller-supplied mean incident photons × caller-supplied quantum efficiency;
-- `calculateSignalToNoise()`: Poisson shot-noise standard deviation plus independent caller-supplied RMS read noise, reported as linear and dB SNR.
-
-These functions do **not** derive incident photon counts from scene imagery.
-
-They do not currently model dark current, fixed-pattern noise, PRNU/DSNU, ADC quantization, clipping/full-well behavior, CFA/demosaic, downstream denoising, or a particular commercial sensor.
-
-The composed POC intentionally does not expose photon/noise output.
-
-The root package now includes a **radiometry-readiness gate** that validates whether a declared prerequisite package contains scene spectral radiance, optical transmission, pupil/vignetting behavior, explicit photosite collection-area semantics, exposure integration, sensor response, evidence, and uncertainty declarations.
-
-Readiness is deliberately separate from signal/noise calculation:
-
-- `not-ready`: prerequisite categories are missing;
-- `approximate-only`: all categories exist, but at least one is approximate or has unquantified uncertainty;
-- `calibrated-ready`: all categories are declared calibrated with quantified uncertainty.
-
-These states describe the declared prerequisite package only. They do not prove a calibration is correct, do not calculate incident photons, and never enable photon/noise output in `simulatePocCamera()` automatically.
-
-Geometric pixel/sample pitch is not accepted as photon-collection area. An explicit effective collection area or geometric cell area plus fill factor is required.
-
-## Provenance
-
-The equations in this slice are independently implemented from established projective geometry, exposure relations, and elementary photon/statistical noise models. No third-party source code or calibration dataset is incorporated by these modules.

package/docs/NATIVE_CAPTURE_SDR.md

@@ -1,70 +0,0 @@
-# Bounded native capture SDR execution
-
-`calculateNativeCaptureSdrPlan` and `createNativeCaptureSdrTask` are additive schema 0.1.0 APIs for authoritative external linear RGB manifests. They do not widen the unchanged `calculateCaptureSdr` or `calculateSdrRendering` reference guards. This is engine-declared tiling, with whole-capture identity and explicit ownership, rather than consumer request splitting.
-
-## Supported domain
-
-The selected `SimulatedCapture` plane must already be color-transformed linear sRGB/D65, exact profile version 0.1.0, co-sited RGB with resolved upstream WB or no WB required. All planes in the manifest must use external float32/float64 storage. The provider decodes declared little-endian bytes to the matching native typed numeric array. Precision is preserved; float32 is not promoted to a claim of original float64 fidelity. Reference white, signed values, headroom, capture saturation and source dynamic-range history stay distinct.
-
-XYZ, unresolved sensor/virtual RGB, pending WB, HDR, resampling, lens corrections and RAW generation are unsupported here. Complete color/WB through the engine-owned upstream contract before handing over this master. This executor never applies WB twice or generates a source from a preview. The upstream renderer/source still needs qualification; structural metadata is not proof of correct pixels or calibration.
-
-Coordinates are absolute top-left, +X right/+Y down in the plane's declared `oriented-active-capture` or `output` raster. Crop and physical orientation are already committed in the capture geometry and represented by the provider's plane. The executor preserves them without re-cropping, rotating, padding image edges or resampling. The output dimensions exactly equal the selected plane. Geometry includes later output intent even when the selected active-capture plane precedes that intent; this call does not execute that later crop.
-
-## Limits and ownership
-
-Maximum raster is 24,000,000 pixels, each dimension at most 16,384. Every tile is at most 256 × 32 pixels; right/bottom tiles use their actual remaining dimensions. A tile has RGB row stride in component samples, at least width × 3. Its length must exactly equal stride × height. Padding is ignored. The entire backing buffer, including offset/slack, is bounded to 32,768 components in the declared float precision. SharedArrayBuffer is rejected; provider must not mutate, detach or reuse its returned tile. No tile/output network, persistence or decoder is built into the engine.
-
-A task allocates one tightly packed Uint8Array or Uint16Array output only after admission planning. `maximumOutputBytes` must admit the exact width × height × 3 × bytes-per-code. The maximum retained output is 72 MB at 8 bits or 144 MB at 16 bits, decimal units. The input master remains external and is not retained/copied wholesale. At most one tile read is in flight.
-
-`maximumScratchPayloadBytes` is 1,441,792 bytes: one maximum float64 provider payload plus six bounded double-array payloads (packed input, parsed input, tone, gamut, transfer, codes). This counts logical numeric payloads, not JS array headers, temporary validation booleans, GC retention, decoder/GPU memory or platform overhead. It is **not** a heap/process/device peak guarantee. Callers must budget output plus measured runtime/decoder/source retention and reject unsupported devices before starting. No full-size floating-point diagnostic arrays are retained.
-
-## Processing and identity
-
-Each tile delegates to the unchanged bounded SDR reference. Exposure normalization → selected tone curve → gamut policy → sRGB transfer → nearest-ties-up integer quantization is pointwise, so tiling adds no halo, seam, altered rounding or second camera-science implementation. Counts are aggregated over actual image components; capture saturation is preserved in the plan and remains `not-consumed` in downstream rendering diagnostics. The reference's output encoding and external display-adaptation declaration accompany the output.
-
-The frozen plan retains the full parsed capture: creator/schema, source artifact/hash/history, scene/time, seed/noise/model/evidence, exposure/focus/WB, geometry/plane/color/transform identities, new output state ID and complete rendering profile. Every request and response must match capture ID, plane ID, source artifact/hash and exact rectangle. A digest match is an identity declaration, not verification of sample bytes: the provider owns authenticating the external artifact against its whole-file hash before decoding. No partial-file hash is relabeled as a full source hash.
-
-## Task lifecycle
-
-`ready → running → completed → transferred` is single-use. `run()` resolves without publishing a buffer. `takeOutput()` transfers the retained buffer once, along with its plan/encoding/diagnostics. Caller owns the returned mutable integer array; an immutable capture manifest does not make output bytes immutable. Dispose/cancel cannot revoke a transferred buffer.
-
-Before transfer, cancel/dispose aborts the provider signal, clears/releases any engine output, and prevents publication. `run()` rejects after a pending read/yield settles; providers must honor abort and release their resources. A non-cooperative pending callback cannot be forcibly stopped by this API. Caller must await settlement before reclaiming shared provider resources or launching replacement work on them. Failed tasks release partial output and abort the provider signal. A fresh admitted task is the recovery path; no automatic retry/fallback exists.
-
-The provider's required `yieldControl(signal)` must yield to the host event loop between tiles (for example an abort-aware timer, scheduler or worker handoff). A resolved promise alone does not let browser input/timer cancellation run. Host scheduling is external to the scientific package. Check current application capture identity before transferring/installing a completed output; a disposed older task cannot publish late.
-
-## Acceptance and release
-
-`test/native-capture-sdr.test.ts` compares the unchanged capture reference across tile edges, row padding, 8/16-bit encoding, upstream WB and all four committed orientations/off-center crops. It checks invalid/stale/oversized domains, finite image data, float precision, pending-read cancellation, between-tile cancellation, disposal, ownership transfer and recovery, plus independently predicted pixels in a 1.2 MP synthetic raster.
-
-See [the validation record](NATIVE_CAPTURE_SDR_VALIDATION.md) for measured host-specific evidence and [the technical review](NATIVE_CAPTURE_SDR_REVIEW.md) for the remaining human/source certification gates. Run `node --expose-gc scripts/benchmark-native-capture-sdr.mjs` after build for deterministic 6 MP/24 MP timing and sampled process memory at both 8 and 16 bits. Measurements are host-specific and use owned analytic samples, not licensed photographs or calibration. The packed example below runs through the real root package during consumer acceptance.
-
-```ts
-import { createSimulatedCapture, createNativeCaptureSdrTask, LINEAR_CAPTURE_RGB_PROFILE, resolveCaptureColorModel } from "@photivra/engine";
-const capture = createSimulatedCapture({
-  captureId: "native-example", sceneStateId: "analytic-scene", sceneTimeSeconds: 0,
-  geometry: { imagingArea: { widthMm: 36, heightMm: 24 }, nativeRaster: { pixelWidth: 2, pixelHeight: 1 }, orientation: "landscape" },
-  exposure: { focalLengthMm: 50, aperture: 4, shutterSeconds: .01, iso: 100 }, focus: { kind: "infinity" },
-  noise: { seedUint32: 0, realizationId: "none", model: { id: "analytic-noise-zero", version: "1" } },
-  source: { kind: "color-transformed-linear-master", artifactId: "analytic-source", sha256: "a".repeat(64), dynamicRangeHistory: "no-loss-declared" },
-  whiteBalanceIntent: null, adoptedWhiteXyz: null,
-  models: [{ profile: LINEAR_CAPTURE_RGB_PROFILE, scientificStatus: "calculated", publicEvidenceIds: ["photivra:analytic-example"] }],
-  planes: [{ id: "rgb", imageStateId: "linear-state", imageState: "color-transformed-linear-rgb", rasterBinding: "oriented-active-capture",
-    pixelWidth: 2, pixelHeight: 1, channelIds: ["red", "green", "blue"], colorProfile: LINEAR_CAPTURE_RGB_PROFILE,
-    encodingReferenceWhiteXyz: resolveCaptureColorModel().referenceWhiteXyz, referenceWhiteValue: 1, whiteBalanceApplication: "not-applicable",
-    captureSaturation: { kind: "not-modeled" }, appliedTransforms: [{ kind: "linear-color", profile: LINEAR_CAPTURE_RGB_PROFILE }],
-    storage: { kind: "external-float64", byteOrder: "little-endian", artifactId: "analytic-rgb", sha256: "b".repeat(64), sampleCount: 6 } }]
-}).value;
-// Digests here are synthetic identity placeholders, not verified artifacts.
-const task = createNativeCaptureSdrTask({ capture, sourcePlaneId: "rgb", outputImageStateId: "sdr-state", maximumOutputBytes: 6,
-  profile: { schemaVersion: "0.1.0", profileId: "neutral", profileVersion: "1", renderingExposureEv: 0, toneCurve: "identity",
-    gamutHandling: "clip-components", outputDynamicRange: "sdr", transferFunction: "srgb", bitDepth: 8, rounding: "nearest-ties-up", dither: "none" }
-}, {
-  async readTile(request) { return { ...request, rowStrideSamples: 6, samples: new Float64Array([0, .5, 1, 1, .5, 0]) }; },
-  async yieldControl() { await new Promise<void>(resolve => setTimeout(resolve, 0)); }
-});
-await task.run();
-const output = task.takeOutput();
-if (output.integerSamples.join(",") !== "0,188,255,255,188,0") throw new Error("Native SDR example failed");
-```
-
-Human review, merge, version/tag and npm publication are separate release steps. Consumer activation requires the published reviewed contract, a qualified native producer and measured device budgets. This API does not activate a production plan or qualify app fixtures, Print/JPEG delivery, GPU rendering or devices.