Available now
Fast repeat work on a live working set
Conterminal feels instant because your working set is already in the browser. Screens open, filters snap, container details preview. No round trip to the server.
Why it matters
The dock doesn't wait. Neither does the screen.
Dispatch desks live in the seconds. Every filter that spins and every screen that reloads gray is time you're not spending on the box about to rack demurrage. Rebuild the same report for every look and the friction piles up across a full board on a busy morning.
Conterminal flips the model. Your organization's working set is pre-computed once and cached right in the browser: the containers, vessels, and deadlines you actually touch. Filter, sort, page, or open a detail, and the answer is already local. The server sits out every look. It's only in the loop for a change.
When the data sits that close, the interface stops feeling like a website you wait on. It starts feeling like a tool you work in. Dashboards let you look. Operating systems let you build. And an operating system has to keep up with your hands.
How it works
From signal to action.
- 01
Assemble the working set once
Conterminal gathers the containers, vessels, and deadlines in your operating scope into one shared working set, instead of fetching each screen on its own.
- 02
Cache it in the browser
The snapshot lands in IndexedDB on the client. Filtering, sorting, and paging run against that local copy. A look never costs another trip to the server.
- 03
Keep it live over sockets
A lightweight live-update channel patches the open view when a container changes. No full page reload.
- 04
Preview details with no gray flash
Opening a container drops straight into its detail context. The working screen never blanks to a loading state.
What's inside
The details that carry the weight.
The working-set snapshot
Your org's active containers, vessels, and deadlines are pre-computed into one snapshot, not fetched screen by screen. One assembly feeds every view.
Client-side cache in IndexedDB
The snapshot lives in the browser's IndexedDB, so filtering, sorting, and navigation resolve against local data at native speed.
Live updates in place
Lightweight change signals patch the open screen in place. No full page reload, and the shared working set stays current.
Skeleton-free detail preview
Click-to-preview keeps your surrounding work in place and opens the record with no gray-flash transition.
One engine under every screen
This is not a mode you turn on for one page. The snapshot store is the shared layer every workspace screen reads from.
Operational safeguards
Built into the workflow.
- 01
The working-set engine is the default in forwarder and carrier workspaces, not an opt-in mode.
- 02
One assembled working set feeds filtering, sorting, navigation, and detail context across supported workspaces.
- 03
Live update signals patch the open view without rebuilding the whole page.
- 04
The shared working-set engine replaced page-by-page loading paths across the workspace.
Everyone on the platform benefits: the snapshot engine is the shared speed layer under every forwarder, carrier, and BCO (Beneficial Cargo Owner) screen.
Questions
Good to know.
If the data lives in the browser, is it stale?
No. The working set is cached for speed, and lightweight live-update signals push changes into the open screen in place. You read from the local copy while the channel keeps it current. No full reload.
What happens when my working set is large?
The snapshot is assembled as one operating payload and reused across the supported views. During rollout, lookback and workspace scope are confirmed against the operator's real volume.
Do I have to turn this on?
It's already on in supported forwarder and carrier workspaces. The working set is the shared engine under the experience, not a setting you configure.
See it live
See Instant by Design on your own freight.
Bring a handful of container numbers and we'll show you this capability working on your real operation.