HubBook a working session

AiNOS One

One model of every hub, compiled from the systems the hub already runs. Nothing is replaced.

AiNOS One is our connected operational foundation. It compiles your records into an ontology: a model of assets, relationships, events and rules, linked to source evidence. Twins and AI agents use that context to assess impact and propose actions for review.

How a hub becomes one model

An agent asks a cutoff question of six raw systems and finds no meaning and no links. Compiled into typed, linked objects, the same question gets an answer with its sources.

The interface agents work on

A frontier agent answers a cutoff question through typed tools, cites what it read, and waits for approval.

From records to decisions

Five steps, the same in a terminal, a warehouse and an airport.

  1. Records

    Every system stays where it is. One reads its records and keeps each one’s source and time.

  2. Context

    Records become typed objects, relations, events and rules: vessels, cranes, orders, stands, cutoffs.

  3. Twin

    The model replays and simulates, so a decision is tested before anyone makes it.

  4. Agents

    Frontier agents work through typed, permission-scoped tools. They cite their sources or they escalate.

  5. Improve

    Approved decisions and their outcomes return to the model as memory.

What One reads

The systems each hub already runs. They stay the authority; One links them.

Container terminals

  • Terminal operating system
  • Berth plan
  • Crane PLC and telemetry
  • Yard and block system
  • Gate and truck booking
  • AMR and AGV fleet manager
  • EDI messages
  • Customs, dangerous goods and reefer holds
  • Radio and supervisor notes
  • Safety rulebook

Warehouses, 3PLs and transport

  • Warehouse management system
  • Order management system
  • Transport management system
  • Yard management
  • Carrier departures and tracking
  • Temperature sensors
  • Quality system
  • EDI messages
  • Labour roster
  • Messenger and call records

Airside operations

  • Airport operational database
  • A-CDM milestones
  • Departure control
  • Ground handling and equipment dispatch
  • Baggage reconciliation
  • Resource management
  • ATC slots
  • Refuelling records
  • Airside rulebooks

An interface built for frontier agents

Agents don’t query tables. They call typed tools on the model, scoped to what their user may see, and every answer carries the records it came from.

find
Locate the objects a question is about: a vessel, an order, a turnaround.
inspect
Read an object with its relations, its current state and the records behind it.
trace_impact
Follow a change through everything it touches, up to the cutoff at stake.
compare_options
Score feasible responses on time, cost and who each one affects.

From proposal to outcome

Every object has a source, every constraint has an owner, and every answer has a trace.

  1. Proposal

    An agent proposes, with the records it read.

  2. Approval

    The person who owns the decision approves, edits or rejects.

  3. Existing system executes

    The TOS, WMS or dispatch system carries it out. Agents hold no write tool.

  4. Outcome recorded

    What happened is kept with the decision, as memory for the next one.