Systems we have built

Each one is titled by what it does. A client is never named, and our own work says so. No percentages either: what follows is the workflow, the engineering decisions, and how far each system actually went.

One instinct, three problems

A freight workflow, an automation harness and a spatial prototype have almost nothing in common on the surface. The engineering decision underneath each is the same one: separate what has to stay stable from what is certainly going to change.

In the freight platform it is an API boundary holding while the process behind it moves. In WorkShip it is execution mode as configuration, so the harness that built a workflow is the one that runs it. In the spatial system it is plan editing, rendering, display and gesture kept as four replaceable layers, so a new output format does not reach back into the other three.

That is the part worth hiring for. It is also the part that does not show up in a demo, which is why these pages describe decisions rather than screenshots.

  • Freight Operations Platform

    The API boundary

    • carrier systems
    • the API boundary
    • operations workflow

    Carriers were always going to keep changing. The workflow above them was not.

  • WorkShip

    The workflow model

    • tools and models
    • the workflow model
    • one traced run

    Execution mode moves between simulated and live. The model underneath it does not.

  • Spatial Visualization

    The layer boundaries

    • gesture input
    • the scene
    • synchronised views

    A change of output format reaches the display layer and stops there.

The other thing we build for ourselves: CanonOS

Bring the problem, not a specification

Send a paragraph about the workflow that is not working. We reply within two working days with questions, a rough shape, and an honest answer on whether we are the right people for it.

Discuss a problem