The API for real-world work

Every Deckhand workflow is an API path. You make one call and get back a standards-traceable HTML report URL — same input, same output, every time. Chat is one client of that call, not the product.

Built on the open-source digitalmodel library — 7,000+ standard-mapped functions, 42 standards implemented.

Browse the API-path catalog See the proof

One contract, every workflow

You don't learn a new interface per discipline. You learn one call. The ref selects the workflow; the report URL is the deliverable.

Request

POST /api/run { "ref": "digitalmodel:mooring-fatigue@2", "domain": "floating-marine", "subdomain": "mooring", "inputs": { "objective": "screen mooring fatigue", "configuration": "...", "environment": "...", "line_material": "chain" } }

Response

{ "status": "PASS", "report_url": "https://vamseeachanta.github.io/ deckhand-sandbox/.../report.html", "artifacts": ["summary.json", "inputs.yml", "..."], "coordinate": { "repo": "digitalmodel", "domain": "floating-marine", "subdomain": "mooring", "resolved_version": "2" }, "duration_s": 12.4 }

The report_url is the work itself — a self-contained, standards-traceable HTML report you can open, archive, and hand to a checker. Browse real reports on the public deckhand-sandbox gallery.

What every response carries

A report URL

report_url — a standards-traceable HTML report with the number, the governing clause, and the assumption ledger. Not a chat blurb you have to trust.

A coordinate

coordinate pins the exact repo, domain, subdomain, workflow, and resolved version that produced the result — so the same call is reproducible later.

A status + artifacts

status (PASS / FAIL / escalate) and artifacts (inputs, summary, plots). Out-of-scope or unbuilt paths return an honest 404, never a fabricated answer.

Chat is one client of the API

The same /api/run call is reachable from anywhere. The chat bot is a thin front-end — not a different product.

💬Chat (Telegram / WhatsApp). Ask in plain language; the front-end resolves your message to a ref + inputs and calls the path for you.

💻Web button. Our calculators and "try it" buttons are the same call from a webpage.

⏱Cron / automation. Schedule a path to run on new data and post the report URL.

🔗Partner systems. Any system that can POST JSON can fire a path and consume the report URL.

Deterministic by contract

The same call returns the same result — because the compute runs on the digitalmodel engine, not free-form model output.

Field	Meaning
`ref`	The workflow path to run — a row in the API-path catalog (`domain-workflows.yaml`), optionally version-pinned.
`domain` / `subdomain`	The knowledge-pack coordinate that scopes the run (e.g. `floating-marine` / `mooring`).
`inputs`	The required clarification keys for that path. Missing branch-first inputs are asked, never guessed.
`status`	`PASS` / `FAIL` / escalate. A path with no runnable workflow escalates honestly rather than inventing a number.
`report_url`	The standards-traceable HTML report — the deliverable.
`coordinate`	The resolved repo / domain / subdomain / workflow / version — the reproducibility receipt.
`duration_s`	Wall-clock run time of the call.

Reproducibility is enforced below the model: 680 byte-identical golden cases, PR-only changes, fine-grained credentials per scope. See how the guardrails work.

Live today — and what's onboarding

We only call a domain "live" when it has a firable workflow row and a published report URL.

Live: subsea-pipeline and floating-marine (mooring) screening — DNV-traceable, deterministic, with report URLs on the public gallery.
Onboarding (roadmap): CAD/CAM, manufacturing, electrical, wells & subsurface and more are API paths being onboarded — not shipped capability yet.

See the full API-path catalog