Three steps. Configure your actors, configure the stand-ins for any system without a live connector, then go live.
Each card is one actor type. Open it to edit profiles. The chip on the right shows whether that actor's profile data is actually feeding the live platform, or whether a stand-in is still supplying legacy seed data for that surface.
Up through v1.0.c.6, ConnectedCargo ran two parallel stand-in engines: a profile-driven layer on top of a legacy seed layer (6 hardcoded carriers, random truck plans, hardcoded GHA markers). That's why earlier builds sometimes showed flights from airlines you hadn't picked, and trucks that didn't belong to any LSP.
v1.0.c.7 retired the legacy seed engine. state.carriers is now derived from CC.airlines.list(), state.ghas from CC.gha.list() joined to airport coordinates, and the truck network from the union of every LSP's truck-mode lanes. All three reconcile live when you edit a profile in another view.
If you edit profiles and want to see the changes propagate without a full reload, no action is needed — the reconcile hooks fire on every onChange event from the affected registry.
Parameters for the synthetic stand-ins that run only where an actor system has no credentialed connector. In a fully integrated deployment none of these apply. The full editors live where each control was implemented; this panel shows the current value and a link to edit. v1.0.c.5 pulls these into native controls on this page.
Pre-flight checklist. Items marked ✓ are ready; ⚠ means the platform will still start but with a known stand-in in place (e.g. seed carriers if no airline is active).
| Booking | Truck · Driver | AWBs | Pickup at | Drop at GHA | Planned pickup | GHA slot | AWB cut-off | Status |
|---|---|---|---|---|---|---|---|---|
| Loading bookings… | ||||||||
| Truck · Driver | AWBs | GHA | Slot | Arrived | Dwell | Cut-off in | Status |
|---|---|---|---|---|---|---|---|
| Loading at-GHA trucks… | |||||||
dwell.breach.detected published to all subscribers
074-12345678). One row per AWB.
AKE12345KL) = the airline container holding the cargo. Number is the load (% of cube/weight used). ❄ = refrigerated container.
AKE12345KL) — IATA-format: 3-char type + serial + owner code. Click for full detail later.
In one line: this page decides how the platform fixes value leaks — you set the priorities, pick the “brain” (engine), then watch and compare. Full reference: OPTIMISATION-GUIDE.md.
⚙ Engines marked “needs backend” use the local solver service (auto-starts at login). The rest run in the browser. If a backend engine shows a “fallback” note, the service or model isn’t available yet — the platform keeps working on the in-browser fallback.
CC.kafkaA cargo control-tower Digital Twin. The browser is a thin client; the intelligence — event detection, the case spine, the decision/policy/governance engines, and the air-cargo compliance vertical — runs on the EIE service. Off (default) everything runs in the in-browser sandbox; point it at the service to delegate, byte-identically, with graceful fallback.
Open Configuration (the ⚙ control on the Control Tower) and set the EIE service URL
(e.g. http://127.0.0.1:8091). Then flip the toggles you want:
compliance.* events stream live on the Decisions Feed. At deploy the in-process bus
becomes Kafka + Flink — same shapes, same topics.signal.telemetry → compliance.* events stream in.case.* fan-out until the cloud CMP is deployed.
/decide). Falls back to the local engine if the service is unreachable. The defining thin-client move — decision intelligence lives server-side.