One HTTPS request per operation. No SDK is required and none is privileged — every example here is curl because anything that speaks HTTP speaks this API. Responses are application/json, serialised through orjson, with IEEE-754 doubles round-tripped exactly.
This page says how to call the engine. That one says how you know the numbers coming back are right — with the method, the reference, and what each result does not establish.
curl -sS https://api.geodesicspacesystems.com/v1/opm/elements \ -H "x-api-key: $GDS_KEY" \ -H "Content-Type: application/json" \ -d '{ "position_km": [7000.0, 0.0, 0.0], "velocity_km_s": [0.0, 7.5461, 0.0], "mu": 398600.4418 }'
{
"semi_major_axis_km": 7000.0,
"eccentricity": 1.4e-16,
"inclination_deg": 0.0,
"period_s": 5828.517,
"specific_energy": -28.4715,
"engine": {
"module": "geodesic.elements",
"operation": "elements.osculating",
"execution_ms": 0.0084,
"offloaded": true
}
}
It names the module and the operation, the wall time spent inside the native call, and whether the call was offloaded from the event loop. When two tools disagree the first useful question is which code actually ran; that should be answerable from the response rather than from a support ticket.
A bearer token on every request. Keys are stored as HMAC-SHA-256 digests — the plaintext is shown once at issue and never again, so a compromised database does not yield working keys.
| Tier | Who | Requests per minute |
Compute rate steps per minute |
Per call max steps |
Total allowance | Validity | Telemetry |
|---|---|---|---|---|---|---|---|
| GDS_Burner_Key | Students, academics, researchers and engineers on a verified institutional domain. 3 keys per domain. | 300 | 300,000 | 6,000 | 1,000,000 steps | 48 h | — |
| GDS_Dev_Key | Integration, trade studies, commercial evaluation | 1,200 | 12,000,000 | 12,000,000 | 40,000,000,000 steps | subscription | — |
The Allowance column above is what a key may spend in total. A single request is bounded separately, by the endpoint's own schema: /v1/opm/propagate accepts at most 100,000 steps per call and answers 422 above that. Longer arcs are several calls, each chained on the state the last one returned.
Your tier may bound a single call lower than the schema does, and the lower of the two wins. A GDS_Burner_Key is capped at 6,000 steps per call — enough for one full low-Earth orbit at one-second resolution in a single request.
That ceiling is the response, not the physics. Every step returns a state, so a hundred thousand of them is roughly 15 MB of JSON — measured here, 17.8 ms of integration inside a 693 ms call. Append ?want_trajectory=false and only the final state comes back: the same integration, the same state to the last bit, in 21 ms and 522 bytes. Ask for the arc when you want the arc.
Every tier runs on the same fleet, which spans two regions so no tier depends on a single machine. Capacity is provisioned rather than elastic — there is no autoscaling, and nodes are started deliberately rather than in response to load.
Redundancy is a property of the platform rather than something a tier buys. A machine reserved for one customer is still one machine, and its failure is total for whoever is on it; spreading work across many is the stronger guarantee, so it is how the service is built for everyone.
Isolation of your data does not depend on any of this. Every computation executes inside the enclave, and the parent host has no address translation into that memory — whichever machine serves the request. A catalogue uploaded for signed derivation is the one exception: it is fingerprinted and signed inside the enclave, then held in memory on the Sweep server for 24 hours until it expires.
The two keys are cumulative: a Dev key reaches everything a Burner key does.
GDS_Burner_Key — message validation on /v1/opm/validate, /v1/cdm/validate and /v1/oem/validate, plus real propagation on /v1/opm/propagate. The validators are free: they run Pydantic only, never reach an engine, and never draw down your allowance, so you can lint a message generator against the real schema without spending anything. Propagation is metered.
GDS_Dev_Key — the full engine set: harmonic, ephemeris and non-conservative propagation, covariance and realism, conjunction assessment and screening, avoidance design, manoeuvre detection, ballistic estimation and decay, constellation planning, libration-point orbits and manifolds, thermal, atmospheric density, SRP and low-thrust spiral.
These are not tiers of the key above and are not reached by upgrading one. Each is arranged separately and deployed on a dedicated server.
Flight Ops service — everything above, with no compute ceiling of any kind, plus the near 100 Hz telemetry channel at /v1/stream/telemetry. The streaming channel is what the service provides and is the one capability a custom key cannot purchase separately.
Evidence service — signed receipts and an exportable audit chain, for compliance and underwriting. Arranged under agreement.
Engine Licence — the attested execution layer beneath your own service rather than an endpoint you call. Annual and negotiated.
Signed execution is available on every tier. Append ?certify=true to a physics call and the enclave signs the result — a free key can verify that claim rather than take it on trust.
If the node serving your stream fails hard, nothing will tell you. A WebSocket cannot migrate between nodes, so the stream ends — but a node that loses power or its network sends no close frame, no FIN and no RST. Your socket stays open and silent, and the frames simply stop. We measured this deliberately rather than assuming it.
So the detection time is yours, not ours. Set a read timeout on the socket and reconnect when it fires. At roughly 100 Hz a gap of more than a few hundred milliseconds is already anomalous; a timeout of 5 s costs nothing and bounds your exposure. A client with no read timeout will wait on a dead node indefinitely.
Reconnection itself is fast and is sized for the case where every stream comes back at once: a fleet-wide reconnect after a node loss was measured at 64 of 64 streams restored with zero throttled and zero refused, the whole burst completing inside 100 ms. A graceful node stop is different and better — the socket closes cleanly, your client learns immediately, and the measured gap was 0.30 s. It is the ungraceful case that needs the timeout.
Measured on the shared evaluation fleet. Every figure in this box came from keys served over shared connections. A dedicated deployment has not been measured, and these numbers should not be assumed to carry across to one.
A long-lived stream will be closed on you, repeatedly, while everything is working correctly. Over a 60 minute run of 120 concurrent streams we measured 50.8% closed before the hour was out — a half-life of roughly 59 minutes. Nothing was wrong. Plan for a stream to last tens of minutes, not days.
It is the connection path, not our origin, and we can show that rather than assert it. The same load driven straight at the service, bypassing the public path, held 60 streams for 40 minutes with zero closes and again 60 for 35 minutes with zero closes — 14.4 million and 12.6 million frames, both at a clean 100 Hz. At the public rate those runs should have lost about twenty streams between them. They lost none. We cannot remove this, so we are telling you about it instead.
So treat a close as a reconnect, not as an incident. Reconnect on any close and on your read timeout, with a short jittered backoff — a few hundred milliseconds, randomised, so a fleet of your own clients does not return in lockstep. Do not page a human on a closed stream. Do not treat close frequency as a service-health signal; it measures the network between us, not the service.
A reconnected stream resumes from live, not from where it stopped. Telemetry is a sampled feed of a running propagation, not a replayable log — there is no cursor, no backfill and no gap-filling on reconnect. You lose the samples in the gap and nothing else. If your application needs continuity across a gap, interpolate locally or re-request the interval over /v1/opm/propagate, which is deterministic and will give you the same states.
During a failover you may also see a brief 530 on ordinary requests. That is the edge reporting it could not reach an origin; the request never arrived, so nothing was executed, recorded or metered. Retry it. During a failover the window is seconds and a retry succeeds. A 530 that persists means no node is currently serving — the fleet is started for evaluation rather than held up continuously, and that is a documented dormant state rather than an outage. A 530 is the one status on this API that means “ask again” rather than “something about your request was wrong”.
All of the above was measured on the shared evaluation fleet, where connections are shared across evaluating users. A contract is deployed on a dedicated server and has not been measured; expect to reconnect either way, but do not plan against these particular rates on one.
Four limits, four distinct answers. Each names which one you hit, so you never have to guess.
| You did this | Status | error | reason |
|---|---|---|---|
| Called an endpoint above your tier | 403 | FORBIDDEN | INSUFFICIENT_TIER |
| One call exceeded your per-call step ceiling | 422 | STEP_CEILING_EXCEEDED | TIER_MAX_STEPS_PER_REQUEST |
| Too many requests, or too many steps, this minute | 429 | RATE_LIMIT_EXCEEDED | TIER_RATE_CAP |
| Spent your total allowance | 429 | QUOTA_EXCEEDED | TIER_QUOTA_EXHAUSTED |
A refused request costs you nothing. The meter reads before it writes, so a call rejected for any of the reasons above does not draw down your allowance. Nor do the validators, or health and documentation endpoints.
Institutional domains are added and burner keys approved by a human at Geodesic. Requests beyond the three-key allocation enter a queue rather than being refused outright. This is deliberate: an automatic issuer for a free tier in this domain is an automatic issuer for anyone.
If a mission profile does not fit a tier — a hundred runs of a hundred thousand steps, a fixed window, a specific module set — the key builder in the portal composes one. Ceilings exist to keep shared capacity honest, not to force an upgrade.
BASE · https://api.geodesicspacesystems.com
| Method | Path | Purpose | Tier | Status |
|---|---|---|---|---|
| ORBIT PARAMETER MESSAGE | ||||
| POST | /v1/opm/validate | Check a CCSDS OPM without spending engine time | any | LIVE |
| POST | /v1/opm/elements | State vector to osculating classical elements | any | LIVE |
| POST | /v1/opm/transfer | Lambert boundary-value solution between two positions | dev | LIVE |
| POST | /v1/opm/propagate | RK4 with optional J2 and a Delta-F force term | dev | LIVE |
| POST | /v1/opm/propagate/harmonic | Zonals J2–J8 plus post-Newtonian terms | dev | LIVE |
| POST | /v1/opm/propagate/ephemeris | As above, plus third bodies from your ephemeris | dev | LIVE |
| POST | /v1/opm/propagate/nonconservative | As above, plus atmospheric drag and solar radiation pressure | dev | LIVE |
| POST | /v1/opm/covariance | Map a 6×6 covariance to a target epoch by state transition matrix | dev | LIVE |
| POST | /v1/opm/covariance/realism | Uncertainty realism index: is the linear map still meaningful | dev | LIVE |
| POST | /v1/ballistic/decay | Secular decay rate and orbital lifetime with an uncertainty bracket | dev | LIVE |
| POST | /v1/ballistic/estimate | Estimate CdA/m from a residual arc | dev | LIVE |
| CONJUNCTION & EPHEMERIS | ||||
| POST | /v1/cdm/validate | Check a CCSDS CDM | any | LIVE |
| POST | /v1/cdm/screen | Foster probability of collision and risk tier | dev | LIVE |
| POST | /v1/conjunctions/screen | Find every close approach between two states over a window | dev | LIVE |
| POST | /v1/conjunction/assess | Screen, propagate both covariances, and score Pc in one call | dev | LIVE |
| POST | /v1/cam/design | Minimum-ΔV avoidance manoeuvre at a chosen lead time | dev | LIVE |
| POST | /v1/oem/validate | Check a CCSDS OEM | any | LIVE |
| HARDWARE & ENVIRONMENT | ||||
| POST | /v1/hardware/spiral | Edelbaum low-thrust transfer budget | dev | LIVE |
| POST | /v1/hardware/microkinetic | Perturbing-force recovery from a residual series | dev | LIVE |
| POST | /v1/sda/maneuver | Impulsive manoeuvre detection: ΔV, epoch, and classification | dev | LIVE |
| POST | /v1/hardware/thermal | Transient node temperatures with an orbit-driven eclipse fraction | dev | LIVE |
| POST | /v1/hardware/density | NRLMSISE-00 atmospheric density | dev | LIVE |
| POST | /v1/hardware/srp | Projected area toward the Sun from an ingested mesh | dev | LIVE |
| CONSTELLATION & STREAM | ||||
| POST | /v1/constellation/plan | Walker slot geometry with secular drift and resonance | dev | LIVE |
| WSS | /v1/stream/telemetry | Continuous propagated frames at a fixed cadence | flight ops | LIVE |
| CISLUNAR | ||||
| POST | /v1/cr3bp/manifold | Libration-point periodic orbit — planar Lyapunov or halo — with its monodromy spectrum and invariant manifolds | dev | LIVE |
| SERVICE | ||||
| GET | /v1/dictionary | Machine-readable interface dictionary: channels, ids, units, limits | any | LIVE |
| GET | /v1/entitlements | What this key may do, and what remains | any | LIVE |
| POST | /v1/keys/burner | Request a free institutional key | none | LIVE |
| GET | /healthz · /readyz | Liveness and readiness, including per-engine load state | none | LIVE |
| ATTESTATION | ||||
| GET | /v1/attestation | The enclave's current signing key, its PCR measurements, and the AWS attestation document that vouches for both | none | LIVE |
| GET | /v1/attestation/keys | Every signing key this service has used, so a certificate stays checkable after the enclave that issued it is gone | none | LIVE |
| GET | /v1/attestation/{key_id} | One key and its attestation document, by id | none | LIVE |
Every physics endpoint above except /v1/hardware/density and /v1/hardware/srp can return a signed receipt for the computation it just performed. The signature is made by an Ed25519 key that is generated inside an AWS Nitro Enclave, never written to disk, and never leaves it — the parent host cannot read it, because there is no interface that returns it.
That alone would only be our word for it. What makes it evidence is that AWS signs a statement binding that public key to the measurement of the image it is running in, and the chain from that statement up to Amazon's own root is checkable without trusting anything we operate.
AWS Nitro root CA // pinned, not fetched → regional CA → zonal CA → this instance → this enclave // leaf, ~3 h validity signs the attestation document which carries PCR0 and the Ed25519 public key which signs your certificate which names your request and commits to the result
| client_digest | SHA-256 of the exact request bytes you sent |
| input_sha256 | SHA-256 of what the enclave actually received, measured by the enclave itself |
| output_sha256 | SHA-256 of the result, over the raw bytes the engine produced |
| output_bytes | those bytes, with a published layout so you can decode them yourself |
| input_bytes | the struct the enclave received, with a published layout — decode it and read whether it says what you asked for |
| engine_digest | which engine build produced it |
| key_id | the enclave key, resolvable at /v1/attestation/{key_id} |
The request itself is never stored. Only its hash travels, which is what lets you prove a certificate is yours without us holding a copy of what you sent.
One boundary, stated plainly. Those first two hashes are both signed and nothing ties them to each other: the gateway translates your request into the numbers the engines take, and the enclave does not re-derive that translation. So the certificate alone establishes that the attested engines produced this result from the input the enclave received — not that the input was derived from your request without error.
What closes it, and how far. On most certifiable operations the certificate now carries input_bytes: the exact struct the enclave measured, authenticated by the enclave’s own signed input_sha256. The verifier checks that hash for you. Reading the numbers is yours to do — no tool can know what you meant, so a certificate that passes every check on a struct you never opened still tells you nothing about whether your inputs were used. That makes a mistranslation detectable, not impossible, and we would rather state the difference than let it be assumed.
The others make it opt-in rather than omitting it, and the reason is size rather than reluctance: /v1/opm/propagate/ephemeris, /v1/opm/propagate/nonconservative, /v1/hardware/thermal, /v1/hardware/microkinetic, /v1/sda/maneuver and /v1/ballistic/estimate ingest sample arrays or ephemeris blocks. Echoing one back would add hundreds of kilobytes to a request already near the 1 MiB limit, and most callers should not pay that on every request. Ask for it and you get it: add echo_input=true beside certify=true. Leave it off and the certificate is unchanged.
The verifier now reads the struct for you. “Decode it and read it” is fair advice for a 56-byte request and useless for a twelve-thousand-element one, so geodesic_verify.py prints input_bytes as named fields with units — including the things the bytes cannot say about themselves, such as a -1.0 meaning you omitted this and the engine chose. Pass --decode-input for every element rather than the first few.
On ephemeris_sha256, plainly. That field is computed by the gateway and carries no signature of its own, so by itself it is a checksum — it catches a truncated or mis-parsed upload and proves nothing against us. It is also, exactly, the SHA-256 of input_bytes from byte 144 onwards. So request the echo once, check it with --ephemeris-sha256, and you have chained it to the enclave’s signature; after that it is a cheap check you have grounds to trust on every later call, including uncertified ones.
geodesic_verify.py is standalone. Its only dependency is cryptography, and it imports nothing of ours — a verifier that ran our code would be checking our arithmetic with our arithmetic. Read it before you run it; it is short on purpose.
An enclave leaf certificate is valid for about three hours; what it attests does not expire. The chain is therefore validated against the document's own timestamp. Checking it against the current clock would reject every certificate older than an afternoon.
PCR0 is a SHA-384 over the enclave image. The build is pinned and normalised so that two independent rebuilds produce the same measurement byte for byte — which we verify by rebuilding. So the value is stable, and any change to the image changes it. It is not something you can rebuild yourself: the image carries our engine binaries. What you check is that the attestation is genuine and that PCR0 is the one you were told to expect.
Download geodesic_verify.py, then check it against the digest opposite before you run it.
# 54,520 bytes, Python 3.9+, one dependency pip install cryptography python geodesic_verify.py --certificate cert.json \ --request request.json \ --expect-pcr0 <the measurement you pin>
SHA-256 of the file:
64a5f1d86697953d25bcc0686e8de1 a54cfbd10af390e15b416242fc864c 55ab
That digest catches a truncated or altered download. It cannot vouch for the file against anyone who controls this page — a hash published beside the thing it describes is a checksum, not a signature. The real defence is that the file is short, dependency-free and meant to be read.
Signing keys are retained for at least 90 days from issuance. In practice the register is append-only and cannot be pruned, so keys are not going anywhere — but 90 days is the part we commit to, and a floor we can keep is worth more than a promise of forever that no service can.
Capture within 60 days and the question stops applying. An attestation document carries its own AWS certificate chain, so an exported bundle is self-contained: it re-verifies with no network access, no API, and no Geodesic. Insurers and flight-ops teams should capture on receipt.
// once, while the certificate is fresh python geodesic_verify.py \ --certificate cert.json \ --export-bundle evidence.json // any time after, offline, with no request to us python geodesic_verify.py \ --offline evidence.json
If the API is unreachable the verifier falls back to attestation-keys.json, a static mirror of the key register served from this site. Keep a copy of the verifier beside your bundles: formats change, and every published version stays downloadable so evidence never outlives the tool that reads it.
POST /v1/opm/propagate/ephemeris { "state": [42164.17,0,0, 0,3.0747,0], "dt_seconds": 600.0, "steps": 52596, // one year "jd_tdb_int": 2451545.0, // split epoch — "jd_tdb_frac": 0.0, // see note below "zonal_max": 8, "integrator": "sc8", "third_bodies": [ { "jd_start": 2451545.0, "block_days": 4.0, "n_blocks": 95, "n_coef": 13, "mu": 4902.800118, "coefficients": [ /* 3705 doubles */ ] } ] }
{
"steps": 52596,
"zonal_max": 8,
"integrator": "sc8",
"integrator_path": "sc8",
"third_body_count": 1,
"ephemeris_sha256":
"c5e8ac141dbe2b86…",
"states": [ … ],
"engine": {
"module": "geodesic.propagator",
"operation": "propagate.ephemeris"
}
}
You supply the Chebyshev coefficients — DE440, DE441, an agency set, or your own fit. We evaluate what we are given and hash it. Body positions are your input, not our output, which is what “you certify the inputs” means in practice. Twenty-five years of Sun and Moon is roughly 843 KiB, uploaded once.
One unit in the last place of a J2000-era Julian Date is 40 microseconds. At the Sun's 29.8 km/s that quantises its position to 1.2 metres before any physics runs. Passing whole days and a fraction separately removes that, and is the same split JPL and SPICE use.
A Chebyshev fit diverges outside its block, so the engine refuses rather than extrapolates. If your series does not span the whole arc the request is rejected with the JD range it does cover — before you spend the run, not partway through it.
Four fields turn a result into something you can defend to a reviewer years later. None of them require trusting us — each is checkable against material you already hold.
| Field | What it binds | How you check it |
|---|---|---|
| engine.module engine.operation |
Which module and which operation produced the numbers | Compare against the release manifest; a substitution is visible without asking us |
| integrator_path | The scheme that actually executed, which can differ from the one requested | Two arcs compared across sites must show the same path, or the comparison is void |
| ephemeris_sha256 | The precise coefficient set the third-body forces came from | Re-hash your own coefficients; the digest changes on a one-ulp edit |
| engine_path | Whether the batch C loop or the reference Python loop produced the trajectory | The two are held bit-for-bit identical; this says which ran |
Identical inputs against a pinned engine image reproduce bit-for-bit. Across different images the guarantee is weaker and we will not claim otherwise: IEEE-754 mandates correct rounding for + − × ÷ √ but not for sin, cos, pow or exp, and different maths libraries can differ in the last place. That is why both integrators are fixed step — an adaptive controller turns a last-bit difference into a different step sequence, which we measured at 57 million times the spread of the fixed-step path.
Errors carry a stable machine code, a human sentence naming what to change, and an F´ severity so an existing ground system can route them without a translation table. An invalid packet is dropped at the gate with 422 and never reaches an engine.
| Code | HTTP | F´ severity | Meaning |
|---|---|---|---|
| VALIDATION_FAILED | 422 | ACTIVITY_HI | The payload did not satisfy the schema. The message names the field. |
| STEP_CEILING_EXCEEDED | 422 | ACTIVITY_HI | Requested step count is above this key's ceiling. |
| DOMAIN_NOT_APPROVED | 403 | ACTIVITY_HI | Burner key requested from an unapproved institutional domain. |
| FORBIDDEN | 403 | WARNING_LO | Valid key, but not entitled to this module. |
| RATE_LIMIT_EXCEEDED | 429 | WARNING_LO | Sliding-window rate exceeded. Retry after the header interval. |
| QUOTA_EXCEEDED | 429 | WARNING_LO | Execution allowance for the period is spent. |
| CAPACITY_EXHAUSTED | 503 | WARNING_HI | Shared capacity is saturated. Flight Ops channels are unaffected. |
| ENGINE_EXECUTION_FAILED | 502 | WARNING_HI | The engine ran and rejected the work — the physics did not converge, or an input was outside the model's domain. |
| ENGINE_UNAVAILABLE | 503 | FATAL | A required library did not load. The response carries the verbatim linker error rather than a plausible number. |
503 means the engine was never reachable and the same request will fail identically until a deployment is fixed — do not retry in a loop. 502 means it ran and refused the work, so the request itself is the thing to change. Collapsing the two would cost an operator the one piece of information that decides what to do next.
OPEN ANY ENTRY FOR THE FORMULA, THE INPUTS, AND THE MEASURED RESULT AGAINST ITS ANCHOR.
Each entry is a harness that runs against the compiled engine, not a description of one. Each note also records the trap the test is built to avoid, because a harness that can only pass is not evidence — a check has to be capable of failing for the right reason before passing it means anything.
VERDICT · Machine precision. The legacy path is verifiably unchanged.
VERDICT · Agreement to five significant figures against a value fixed in 1915.
VERDICT · The relativistic term scales correctly across four decades of μ.
VERDICT · Both terms match their closed forms to ratio 1.000000.
VERDICT · Within tolerance, with the residual gap explained rather than hidden.
VERDICT · Odd zonals are live, and their magnitude is physically plausible.
VERDICT · Exact to rounding across the block.
VERDICT · The two agree to three ulp.
VERDICT · Eleven micrometres over 400 days.
VERDICT · Position and velocity are mutually consistent.
VERDICT · Both blocks agree with the function at every seam.
VERDICT · An order of magnitude better precisely where it matters most.
VERDICT · Both ends of the published band, in the right order, Moon dominating Sun.
VERDICT · Exact recovery where the old engine returned a constant.
VERDICT · Better than square-root averaging, for the stated structural reason.
VERDICT · Every signature resolved to its physical cause.
VERDICT · Agreement alone would never have caught it. Curvature does.
VERDICT · Every coefficient in the binary matches an independent derivation.
VERDICT · Order 8 confirmed, with the floor published rather than hidden.
VERDICT · Determinism chosen over efficiency, on evidence.
VERDICT · Identical bits on every configuration tested.
VERDICT · Negligible in magnitude, non-zero in fact — so the verified path stays untouched.
VERDICT · Three independent published conditions reproduced.
VERDICT · The defining resonance of GEO, detected from the state vector alone.
VERDICT · Bracketing changed the cost, not a single answer.
VERDICT · Agreement with sampled truth across the operational envelope, including correlated and near-degenerate covariances.
Every routine states the domain on which it is valid and what happens outside it. A Chebyshev series refuses an epoch beyond its table rather than extrapolating. The low-thrust solver reports whether its quasi-circular assumption held. Force recovery publishes the cancellation limit that caps its along-track resolution. The order-8 integrator publishes its roundoff floor. None of those bounds make the engine look better — they are the part a reviewer needs, and an engine that hides them is asking to be trusted rather than checked.
VERDICT · Exactly anti-parallel to the relative velocity, and the magnitude matches the closed form to machine precision.
VERDICT · The conversion is correct and constrained from three directions at once.
VERDICT · Energy is conserved to integrator noise without drag, and removed monotonically with it.
VERDICT · The failure is impossible to mistake for an answer, and is caught before the run rather than after.
VERDICT · Sub-micrometre over the whole spacecraft altitude range, against an independently derived formula.
VERDICT · The extension is inert until it is switched on.
VERDICT · Two structural identities hold exactly, and the finite-difference check agrees at its own truncation floor.
VERDICT · One 3000 s arc equals two 1500 s arcs multiplied, and every column reproduces a real perturbed trajectory.
VERDICT · Symplectic where the physics says it must be, and decisively not where the physics says it must not.
VERDICT · Six-digit agreement between a determinant and an integral that share no code.
VERDICT · The linear map agrees with sampled nonlinear truth to inside the Monte Carlo noise floor.
VERDICT · A well-tracked object stays linear for ten days; a newly detected fragment is outside the envelope within six hours.
VERDICT · Agreement to nine digits with an independently derived geometry, and TCA is a true stationary point.
VERDICT · Every minimum found at the default density, and the adequacy flag never reads clean on an incomplete list.
VERDICT · The engine finds the model-free minimum to a tenth of a percent, and meets the threshold it was given.
VERDICT · The Clohessy-Wiltshire structure emerges from an optimiser that was never told about it.
VERDICT · Between 20% and 50% execution error the cost rises 23-fold: most of the propellant is spent overcoming the operator's own noise.
VERDICT · Exact recovery across a sixteen-fold range, from propagated truth rather than a formula.
VERDICT · Fitting the bounded response removes a systematic error a quadratic-only fit cannot even detect.
VERDICT · Every burn is caught and handed on; a clean arc is not falsely accused.
VERDICT · The degeneracy is exact, is stated rather than hidden, and drives the uncertainty that is actually reported.
VERDICT · A factor of 25.6 across the cycle on identical hardware: a lifetime quoted without a stated flux is not an answer.
VERDICT · The estimate survives a realistic arc, and the quoted interval contains the truth.
VERDICT · Magnitude within 1.4% and epoch within a second, in all three directions.
VERDICT · Sustained forces are referred on rather than claimed, and noise never manufactures a manoeuvre.
Pricing, service levels and contract terms are being finalised alongside the production deployment. Until then this section reads PENDING — the same rule the rest of the platform follows. An indicative price is a number we would be inviting you to plan against, and we do not publish numbers we cannot yet stand behind.
Burner and Dev are issued keys and will carry stated terms. Flight Ops service, Evidence service and the Engine Licence are quoted per engagement instead, because each is a deployment provisioned for one customer — the number depends on what is being provisioned, so there is no list price to publish.
Verified institutional domain. Terms pending.
40 B Steps. Terms pending.
Uncapped compute, near 100 Hz stream. Dedicated servers. Terms pending.
Signed receipts and exportable audit chain, for compliance and underwriting. Under agreement. Dedicated servers. Terms pending.
The attested execution layer beneath your own service. Not an API key. Annual, negotiated. Dedicated servers. Terms pending.
The first two are API keys and are described in full under Subscriptions. Flight Ops service, Evidence service and the Engine Licence are arranged rather than issued, and carry no step allowance of their own — a request-rate cap still applies — see Developers.
Trial keys for Flight Ops service and Evidence service are issued to prospective customers for testing. A trial runs on a shared subscription channel — same software, same engines, same attested enclave — where a contract on either service is deployed on a dedicated server instead.
Outputs are advisory computational products. Results are signed and independently verifiable; the system is not flight certified and carries no airworthiness, launch, or operational authority. All manoeuvre, avoidance, and station-keeping decisions require explicit Flight Dynamics Officer sign-off within the operator's own certified process. Simulated or unpopulated parameters are surfaced as -- or UNKNOWN and must never be interpreted as nominal values.