POST
/.netlify/functions/calculate-r16
Bearer token
mode: point — single-condition physics evaluation of one configuration document; since R11.53.0 every point carries the force-balance disclosure (physics.forceBalance: the heel excess, the lateral shortfall, the longitudinal imbalance disclosed not solved, GZ and GM, the naval-architect confirmation set); since R11.54.0 with the naval-architect review's additive leaves (the derived length basis, a status word beside every drag term, the base-curve righting arm, the GZ/GM equivalence words, the comparison re-base named as arithmetic).
op: edge_delta_grid — what-if speed-delta surface for sail-plan and tuning changes on one document.
body.sailState — since R11.56.0 the successor sail-state carrier (contract cs3): a prescribed point evaluation or a prescribed candidate set (mode point, planAuthority PRESCRIBED), prescribed evaluation across the grid (op edge_delta_grid), and the Optimal map under planAuthority AUTONOMOUS-OPTIMAL (op optimal / optimal_merge) with the five-rung depower ladder FULL, FLATTEN, TWIST, REEF1, REEF2 (since R11.63.0 — one word per control on every served definition, flatten off | on and twist off | on beside the four legacy words; the engine’s per-sail value seats derived by the server equal by construction: solve where a rung introduces a control, the exhausted bounds flat 0.53 / twist 1 where it carries one; the stage rows carry the engine’s closure.solve and closure.controls; a control the engine did not engage reads as a typed stage_unavailable; sail_state.guidance.controls names, per cell, what the winner’s stage applied; the prescribed carriers admit the seats flat / twist. Dated history: the six-stage interleaved ladder FULL, FULL+TWIST, REEF1, REEF1+TWIST, REEF2, REEF2+TWIST from R11.57.0 to R11.62.0; four-stage at R11.56.0); since R11.59.0 the caller may declare which reef stations the map may use (sailState.reef_stations, a set of served station words, FULL implicit; the server derives the ladder, evaluates only the declared stages and echoes the declaration as sail_state.basis.ladder_declaration); every carrier-bearing response carries the additive sail_state block; the raw engine option options.sailStateContract stays refused. Since R11.57.0 a carrier-bearing optimal_merge request over 5,000,000 bytes is refused typed before any merge or solve work (sail_state_optimal_request_size_exceeded; the caller submits the documented merge-carrier form rather than complete display envelopes and measures the complete serialized request against the ceiling, partitioning by cells where necessary — an irreducible single-cell request is an explicit limitation; the 4,000,000-byte response budget stays separate); the service word covers only bodies the platform delivers — the platform refuses request bodies over about 6 MB with 413 before the function runs, so a caller measures a merge request before transmitting it. Since R11.60.0 (vendoring PhysicsR16 16.9.0, the declared reef profile) a mainsail row’s declared power_settings.reefN profile is honoured under the carrier in place of the legacy reef row (a partial declaration completed by the certificate width-station rule; typed refusals; no served boat declares one today). Since R11.61.0 the Optimal map under the carrier evaluates fewer stages and resolves fewer baselines, and says which (sail_state.evaluation_extent, on every envelope and in the shared basis): a plan’s ladder is evaluated in its order to the selector’s stop, so a stage never reached reads unevaluated; a batch after a row’s first resolves only the baselines of its own plans’ kinds and names the others (the merge takes each kind from the batches that resolved it); the hull shape curves are not carried on the two Optimal ops (the diagnostics word hull_shape_curves_not_carried). The winners, scores, selected stages and guidance of a whole map are unchanged wherever R11.60.0 answered; envelopes of different extents, or of none, do not merge (batch_sail_state_mismatch), so a map in flight across a deploy is re-run. Since R11.62.0 (vendoring PhysicsR16 16.10.0, the capability wave) the engine accepts per-sail flatten and twist value seats (a number or ‘solve’) under the carrier and returns applied_state_record/2; at R11.62.0 this service sent none of the new seats (its ladder words were unchanged) — since R11.63.0 it derives them from the five-rung ladder (the R11.63.0 sentence of this paragraph); a request carrying the retired key flatten is refused typed (sail_state_vocabulary_superseded). Since R11.64.0 (DU-M4) the Edge op admits the baseline on the carrier — sailState.baseline { request, baseline_id? }, one per request, materialized first and once and evaluated per cell through the same successor leg on a second prepared working set under the legacy baseline bindings; every Edge response echoes sail_state.baseline { form, baseline_id } — and the three envelopes naHeelOverlay, boatDesignOverride and the selected-sail overlay are admitted beside the carrier on every carrier op with the legacy semantics and the typed tier word for the selected-sail family below tier 2 (the design override is admitted at every tier, as the legacy applies it). Since R11.65.0 (vendoring PhysicsR16 16.12.0, the default-move wave) the served default upwind aero model for jib-and-main cells is the ORC public composition (orc_public_low_spanc) on every lane of calculate-r16 — carrier-less and under the carrier alike, the server stating no force model of its own (a boat the composition cannot be formed on — one without HBI, say — falls back typed to unified on every lane and says so); aeroForceModel ‘unified’ is the comparison arm (the 16.11.0 default); every composed record discloses forceModel.upwindModel, upwindModelSource and fallback_reason beside the orcPublic leaf. The numbers moved at R11.65.0, a declared breaking change for carrier-less callers. A body without the carrier evaluated exactly as before through every carrier release up to R11.64.0; since R11.65.0 it evaluates on the same served default as a body with the carrier. Since R11.66.0 (vendoring PhysicsR16 16.13.0, the kite wave) the heel limit under a spinnaker — a plan whose code seat decodes ASYM / SYM / GENNAKER — is the engine’s own documented basis 21.5° (orc_spinnaker_limiter_21_5, ORC VPP 2026 §5.2.3) on every kite-plan solve naming no strictly-lower declared limit, on every lane; a declared limit strictly lower binds; a declared 21.5 ties (identical physics, the spinnaker word); CODE0 keeps 25°; the upwind composition, the kite aero tables and the datum scope are unchanged. The kite-plan numbers moved at R11.66.0 where the new limit caps, a declared default-path movement; every jib-and-main solve is byte-still. Since R11.67.0 (vendoring PhysicsR16 16.15.0, the kite-seat wave on the spinnaker set) the engine accepts the code seat of candidate_request/3 under the carrier — request.flat.code and the new control key request.reef.code, each a number or ‘solve’ (FLAT on a kite as ORC’s rotation-form algebra, REEF as ORC’s continuous spinnaker reef, ORC VPP 2026 §5.1.3, the floor from the certificate’s rig; typed refusals, never a clamp) — and the carrier gate admits the request key reef on the prescribed carriers, passed through verbatim to the engine’s own words; every cs3 record is applied_state_record/3 (four additive leaves on every record, jib-and-main records at reference). The SYM / GENNAKER → ASYM alias is retired, the engine’s and this service’s own: a symmetric kite evaluates its own family’s tables, so the SYM / GENNAKER numbers moved at R11.67.0, a declared movement; ASYM and jib-and-main solves are byte-still but for the record edition. The served Optimal ladder is unchanged by this wave (the kite ladder is a later promotion). Since 16.15.0 the kite force model of record on every kite plan is the ORC public spinnaker composition as the set (ORC VPP 2026 Tables 5.8 / 5.9 / 5.10 with the main in the set; the kite’s centre 0.565 × ISP; r12 the comparison arm by explicit option; a typed kite-only fallback where the composition cannot be formed): the kite numbers moved at R11.67.0 on every lane, a declared movement; jib-and-main solves are byte-still, their options echo now reads orc_public_spinnaker / root_default. Since R11.68.0 (the kite ladder and the Law of Sailor Trim, a service-only release) the Optimal map walks a ladder per kind — the white sails FULL, FLATTEN, TWIST, REEF1, REEF2 as before; a kite FULL, TWIST, KITE-REEF (the main’s twist under the kite, then the kite’s own reef on the code seat; a change down to a smaller declared kite is the ranking’s, never a rung) — with sail_state.ladders beside the white block, and the Law of Sailor Trim decides each wind column (white sails and kites): the largest sufficient sail holds, a smaller sail enters only where the one in hand is insufficient, and no larger sail returns at a higher wind; a decided cell reads winner_basis sailor_trim with its passed-over plan and margin disclosed. Since R11.69.0 (the interim kite ladder, a service-only release) a kite FULL, TWIST, REEF1, REEF2 — the main’s rungs under the kite; the kite’s own rung is absent and disclosed (the ease floor 0.90, an operator-supplied value, arrives with the engine’s next edition), an eased whole plan is never a kite’s closure (the kite changes down to a smaller inventory kite or hands the cell to the white sails), and the Law of Sailor Trim decides each wind column as before (winner_basis sailor_trim). Since R11.70.0 (the decisive-margin takeover, a service-only release) the Law of Sailor Trim is version 2: the next smaller headsail takes over where it beats the sail in hand by more than 0.15 kt (never a jump; no return at a higher wind), the kite selection unchanged (its takeover cells carry the leaf too); every takeover cell says which sail entered, from which and — where the sail it left still ranks — by how much (trim_law.takeover), and sail_state.trim_law names the margin (decisive_margin_kt).
op: cert_delta_grid — Compares two ORC configuration documents through the same served R16-SA physics model across a governed condition grid. Returns speed, pace and heel differences with typed refusals and complete cell accounting. No post-solve hydro gain is applied.
op: optimal / optimal_merge — the Optimal map: the best sail plan per wind cell from the certificate’s inventory under the cs3 carrier (the per-kind depower ladders and the Law of Sailor Trim), candidate-batched requests merged statelessly by the server; every cell carries kinds_aboard beside kindWinners (since R11.93.0: every kind aboard gets an entry — its pick, or its typed-out best with the reason). Since R11.93.0 a monolithic op: optimal body whose estimated solve time exceeds the service ceiling is refused before any solve with a typed 400 optimal_over_budget (the details say how many cells fit), never a timeout.
op: candidate_catalog / plan_grid / regime_compose — the one-plan-per-call form of the Optimal map: the candidate pool, each plan’s grid, and the composition over the plan records.
op: regime_defaults / regime_windows — the boat’s default sail regimes from its wardrobe, and the TWA / TWS window per regime row (the service never writes a sail plan).
op: column_guidance — since R11.93.0: the trim guidance of a whole wind column too large for one merge, derived from the guidance evidence its cell fragments carry — no solve, no boat document (sail_state.guidance.evidence and guidance_scope on every carrier-bearing op: optimal / optimal_merge envelope).