Industrial Field Services
You built the turnaround-management software. It’s Day 3 of the shutdown, 5:30 a.m., and an NDT inspection slips — which blocks the weld, the scaffold pull and the E&I loop check downstream of it, each burning idle plant time.
You may never set foot on that unit — but your code decides whether four contractor crews work or idle at 5:30 a.m. Re-planning around a dependency chain under permit and cert rules is the code you don’t want to own. Your app flags the blocking activity priority: "p0"; Crisphive re-sequences the chain against permits, certs, activity dependencies and crew availability; your app confirms and re-tasks the contractors.
Try it in your language
Pick a scenario, switch the server SDK. Every snippet is the actual call the API reference generates — with turnaround values filled in.
import { Configuration, JobRequestBusinessApi } from "@crisphive/sdk"; const config = new Configuration({ accessToken: "chsk_test_4eC8xQ9mZ2pL7Ka0rT" }); const api = new JobRequestBusinessApi(config); const res = await api.createJobRequest({ jobRequestCreateRequest: { "customer_id": "a1b2c3d4-0000-4a01-8c01-000000000001", "description": "UT thickness survey — V-402, critical path", "job_dates": [ { "date": "2026-07-24", "periods": [ { "business_view": [], "period": "morning" } ] } ], "job_type_id": "b2c3d4e5-0000-4a02-8c02-000000000002", "priority": "p1", "skill_ids": [ "c3d4e5f6-0000-4a03-8c03-000000000003" ], "sla_deadline": "2026-07-24T14:00:00" }, }); const { error_code, message, data } = res.data;
Switch to Go, Ruby, PHP, Java or .NET — the class names, model types and method casing all follow that SDK’s generated conventions. Swap chsk_test_ for chsk_live_ and the same code runs against production.
▼Three ways this bites
These are the shifts that blow a turnaround budget — each a chain of idle crews on an invoiced clock. Every one maps to a field the API already carries.
The pain ·A slipped inspection strands a weld crew, a scaffold mod and the final signoff — every idle crew-hour is invoiced and the critical path slides.
Crisphive ·The emergency re-sequence preview resequences every affected crew in one solve, protecting the critical-path sla_deadline.
The pain ·Precedence lives in someone’s head, so a weld crew arrives at a deck the scaffold crew hasn’t modified yet — a full crew mobilised with nothing to do.
Crisphive ·Precedence is declared in dependencies and enforced in every plan — weld can’t sequence before its scaffold node clears.
The pain ·A crew is scheduled to enter on a lapsed permit, can’t go in, and stands down — idle hours plus a re-mobilisation once it re-issues.
Crisphive ·A permit pull is modelled in dependencies with real time; the solver schedules entry only inside a live permit.
▼Reading the cascade call
The An activity slipped scenario above is the re-sequence itself — it previews the moves so nothing is re-tasked until you confirm. Its fields map to the story like this:
| Field | What it is |
|---|---|
emergency_job_id | The blocking activity driving the re-sequence — the slipped NDT inspection the chain hangs on. |
technician_id | The crew in play for that activity. |
start_at | When the slip lands — 05:30 in the story. |
mode | How hard the solver may push to hold the path (here, allow overtime). |
displacement_mode | What may happen to the activities it moves (here, reschedule them rather than drop them). |
The urgency flag from the intro — priority: "p0" — is set when you schedule or update the activity on POST /job-requests (the UT survey scenario shows a critical-path p1). The full priority ladder and the allowed values for mode and displacement_mode live in each endpoint’s Full reference.
▼Hard constraints, not suggestions
A scheduler that ignores these isn’t planning — it’s sending a crew to a vessel with no permit. Each one is a first-class field in the API.
| The rule | What the API enforces |
|---|---|
| Activity dependencies | Inspect before weld; weld before scaffold pull. The chain is first-class dependencies — move one node and the rest re-sequence. |
| Permits & isolations | No activity starts without its permit. A permit pull is modelled in dependencies with real time. |
| Certifications | API-510 for the inspection, CWB for the weld. Only crews whose skill_ids cover the activity get assigned. |
| Critical-path protection | Critical-path activities carry a hard sla_deadline. The solver protects the path before it touches float. |
| Shift & fatigue rules | Turnaround shift limits and fatigue rules are hard constraints. The compliant sequence is the only one the API returns. |
▼What you ship
You ship re-sequencing that holds the path.
- No hand-rolled dependency engine — permits, certs, activity chains and critical path are API fields.
- Deterministic means auditable: replay the exact shift for a claims or delay analysis.
- Reporting copy comes back with the plan, ready for the turnaround log verbatim.
▼What their day feels like
One slip stops idling four crews.
- Coordinators stop re-sequencing on a whiteboard.
- The critical path is protected; no crew is sent without its permit or cert.
- Four downstream crews stay working — the slip is absorbed by float, not idle plant time.
▼Every job has stakeholders
A slipped inspection touches far more than the crew behind it. Every activity is a web of stakeholders who feel it when the path drifts — and a tighter operation quietly serves all of them.
Gets the turnaround back on the day it was promised — every idle hour has a cost the client is watching.
Confirms a resequence in one click instead of replanning the wall chart at 5:30 a.m.
The critical path and end date are protected — fewer idle crew-hours, a tighter, defensible operation.
Deterministic re-sequences replay for a delay or claims analysis — granular proof of exactly why the path moved.
Hitting the end date protects the contractor’s standing for the next bid — reputation is the pipeline.
Permit, cert and fatigue rules honoured keep crews safe and working — no one sent to a vessel without a permit.
▼What you get back, and what gets pushed
The An activity slipped preview returns the whole re-sequence in data: moves and reassignments (which activity shifts, from and to which crew and time), a total_moves count, and warnings such as TECH_NOT_FEASIBLE — so coordinators can see the re-sequence before you commit it. Every call — success or not — comes back in the same { error_code, message, data } envelope, so you branch on error_code once and handle the 409 eligibility cases (e.g. EMERGENCY_RESCHEDULE_NOT_ELIGIBLE) the same way everywhere.
To keep the turnaround log live as crews re-task, register a webhook endpoint and Crisphive POSTs each event to your URL with a Crisphive-Signature header. Verify it against your whsec_… secret over the raw body before you trust the payload — Webhooks has the event shape and copy-paste verify snippets.
Start building
The snippet above imports @crisphive/sdk — grab the package for your language, drop in a key, and the same call runs. Every response comes back in one { error_code, message, data } envelope.