Craton documentation

Ten minutes, one terminal, no SDK. By the end you will have turned a location schedule into a canonical risk object — the machine-readable primitive everything else in Craton is built on — and read it back over the API.

The canonical risk object is Craton's core primitive, and its JSON Schema is open. You can fetch it, read it, validate against it and build on it **with no Craton account** — nothing to authenticate, nothing to install, nothing that expires. The engine is paid; the vocabulary is not.

A page for the same work the API does, for when you would rather click than curl. It is a thin client and nothing more: every panel on it is one call from the published route table, made from your browser with your own key, and the whole request and the whole answer are on the page beside every result.

One terminal, no key in advance. By the end you will have an account of your own, a complete parametric object, and a technical price for it with every assumption behind the number attached to the same response.

Forty years of history for a parametric structure, over HTTP, in one block. Read the quickstart first: it explains the two values you export (CEDE_BASE_URL, CEDE_API_KEY), how to get a key from POST /signup, and the job pattern every Craton verb answers with.

Fifteen minutes, one terminal, no SDK. By the end you will have composed a parametric rainfall trigger model out of platform primitives, watched Craton backtest it over forty years of pinned public data, read its auto-generated model card, and used it to produce a technical price for a structure.

One block, one terminal, no key in advance. By the end you will have read what an account has used in the units Craton bills in, cancelled its plan self-service, and seen that the record of what was used survives the cancellation.

You have priced an object and backtested a structure cut from it. This page is where those runs become one document you can hand to a person: an exposure summary, the technical price with its complete assumption set, the backtest behind it, and a draft slip laying the terms out the way a reader expects to meet them — assembled, addressable, and watermarked DRAFT on every page.

POST /structures/{id}/monitoring records that a structure is in force. GET /monitoring and GET /monitoring/{id} read the measurement back, and recompute it every time you ask. POST /monitoring/{id}/webhooks has the measurement delivered to an address of yours when it moves, and GET /monitoring/{id}/webhooks shows you every delivery that was attempted.

POST /objects/{id}/analyse runs named analyses over a canonical risk object and records what they found on that object's provenance. It is a job: the call returns 202 with a job id, you poll GET /jobs/{id}, and the finished job carries the artifacts.

GET /hazard, with peril, lat and lon in the query, answers one question — *what has happened at this place, in the record this build pins* — and answers it synchronously. There is no object to create first and no job to poll: a coordinate goes in, a hazard metric comes out, and the response names the exact snapshot it was computed from.

POST /accumulation takes a set of your own canonical objects and answers the three questions a book raises once it is more than one file: **how much sits behind each peril, **how much sits in each region you declared, and where the value is concentrated. It answers synchronously — the numbers come from the exposures already stored on those objects, so there is nothing to compute against and nothing to wait for.

A backtest tells you six years paid and names the events it paid on. This page is where those names come apart into the record itself: the catalogue Craton read, the exact solutions that qualified, and the rule that collapsed several of them into one occurrence.

Every number Craton produces comes out of a pinned snapshot: a dated copy of a public publisher's response, committed to the build with the SHA-256 of its bytes. A price, a backtest and a model run read those files and nothing else, which is why a result replays byte for byte a year later.

Every refusal the API makes has one shape, whatever route made it and whatever went wrong. This page is the specification of that shape: the envelope, every field in it, every code this build reports, and the rules that say what can change under you and what cannot.

A parametric structure pays on a measurement, and trigger is the block where that measurement is written down: which pinned feed is read, what is measured in it, over what window, and what fraction of the limit each level pays. It is the one block nothing else can supply — a schedule of buildings does not carry it, and Craton will not invent it — so POST /objects/{id}/price refuses an object without one.

A number is worth what its working is worth. This page takes **one real price run** — made on 2026-08-12 against the environment this build deploys to — and puts the whole of it in public: the run id, the complete assumption set, the data vintage the number was computed from, and a block you can run that reproduces that recorded receipt byte for byte.

The honesty exhibit: what Ingest reads, what it admits it guessed at, and what it will not read at all — measured on the golden corpus rather than described. Every number below is computed from the corpus manifests and the pinned oracle outputs by tests/unit/test_honesty_exhibit.py, which re-renders this page and fails the build if a single figure has moved. Nothing here is typed by hand, and nothing here is a target: it is a measurement of what this build does with the ugliest files we could find.

Two of this product's own production checks are stopwatches, and their budgets come from the operating brief rather than from anybody's judgement: a stranger gets from the published documentation to a first authenticated call in under ten minutes, and from the published documentation to a technical price out of a model they composed themselves in under fifteen.

Terms for Craton, the risk-analytics platform. They say what the software does, what you may expect of it, what it costs, and what happens to the data you send. Read them with the acceptable-use page, which holds the rules of use these terms refer to.

The rules of use for Craton: what the platform is for, what it must not be used for, and what happens when a rule is broken. It is the companion to the terms of service, which refer to this page rather than restating it.

Status: first edition (CEDE-075), authored under adr/ADR-0021-go-to-market-mandate.md.

You may be an agent working for an underwriting team, a program designer, a broker, a corporate risk manager — or for a developer building for one of them. This page is written for you. It is short on ceremony and exact about requests, because the two things visiting agents most often lose time to are guessing hosts and guessing request bodies.