Skip to content
Systems

AI Systems,
Shaped by Real Operations

Bespoke systems deployed into live workflows, built around the constraints, incomplete data and exceptions that commercial operations actually contain.

The discipline

Operate. Build. Model.

Commerce

Catalogues, campaigns and imagery running against real budgets.

Operations

Software that sits where the work happens: evidence, intake, and records you can retrieve later.

Modelling

A working model of the firm, built from identity, intake and the records the operation actually writes.

Deployed system - live operation

Fulfilment Evidence

Continuous multi-camera recording, per-slot browsing and exportable MP4 evidence for shipment disputes. Featured below.

View the case

Deployed system - live operation

Commerce Optimisation

Marketplace bid management, budget pacing and controlled campaign experiments designed around real advertising budgets, explicit guardrails and automatic rollback.

Read the vignette

Active pilot

Enterprise Twin

An event-sourced operational model for structured identity, intake and traceable records, exploring how a firm's activity can become a calibrated, simulatable model. It is an active pilot, not a finished ERP.

Read the vignette

Operational Systems

Every Package,
On the Record

A continuous multi-camera recording system for packing operations: so any dispute about what went into a shipment can be answered with footage of the exact slot, at the exact time.

Fulfilment Evidence camera tool: timeline, slot close-up and packing table.

"This wasn't in my parcel"

Fulfilment teams pack orders into numbered slots. When a customer claims an item was missing, there is usually no way to prove otherwise, and the seller may be unable to provide sufficient evidence. Putting a camera over every slot is not practical. Recording everything and being unable to find the relevant thirty seconds is no better.

Continuous recording, slot-level retrieval

Continuous recording and slot-level retrieval for packing operations: so a dispute about what went into a shipment can be answered with footage of the relevant slot, at the relevant time, and exported as evidence. The system is used across tens of thousands of packed shipments.

Status
Deployed system - live operation
Deployment
Deployed in a live fulfilment operation.
Scope
Used across tens of thousands of packed shipments in a fulfilment operation. Camera count, slot grid and start date are withheld.
Result
Slot-level footage can be matched to a customer complaint and exported as marketplace evidence.

Commerce Systems

Marketplace optimisation with explicit guardrails

The problem

Marketplace advertising changes continuously, while manual bid adjustments, scheduling and campaign comparisons are slow and difficult to reproduce.

What we built

An operational service that records campaign snapshots, manages bids and active hours within configured limits, and supports clone-based controlled experiments. Spend, duration and return guardrails can stop an experiment and restore the original campaign automatically.

Deployed system - live operation

Running on live marketplace campaigns.

  • In continuous operational use on live marketplace campaigns.
  • Markets: EMEA.
  • Update cycle: roughly every 10 minutes.
Guarded bid and schedule updates on live campaigns
SKU-level readout during controlled experiments

Active pilot

An operational model built from events

The problem

Commercial operations are commonly spread across spreadsheets, person-specific conventions and repeated hand-offs. Facts are re-entered, exceptions are discovered late and the reasoning behind a decision disappears.

What we built

A system that records operational facts as structured events and derives identity, intake and publication views from them. It is an active pilot in a live workflow, not a finished ERP. The longer-term research asks whether declared interactions and the resulting event history can support calibration, simulation and constrained optimisation.

Active pilot

Deployed in a live commerce workflow.

Enterprise Twin overview: station pipeline for a live batch.

Architecture

Event-sourced kernel

Adapters and stations propose events. Constraints reject invalid state. Projections feed the operational UI.

01

Propose

  1. Channel adapters

    Storefront and marketplace flows enter as structured facts.

  2. Stock and order hub

    Inventory and fulfilment state, not a second ledger.

  3. Stations

    Count, review, enrichment and related operational stages. They offer a change to be recorded.

02

Record

  1. Versioned configuration

    Vocabularies, rulebooks, templates.

  2. Constraint engine

    Invariants reject; norms flag.

  3. Event log

    Append-only, bitemporal: the single source of truth.

  4. Projection engine

    Tables and graphs the operation can actually read.

03

Read

  1. Operational UI

    Forms, review queues, dashboards.

  2. Proposed events

    Visible for review before they enter the log.

  3. Committed record

    Only accepted events become the history of the firm.

Similar operational problem?

We build these systems for specific operations rather than selling them as a product. If something here matches a problem you have, tell us about it.

Talk to us