Documentation

Rust platform

Proposed workspace & crate layout

An illustrative Cargo workspace showing how domain, service, UI and edge crates could relate.

Educational / conceptual specification · Not a released implementation contract

Isometric processor core wired to dock sensors, a scanner, a scale and a truck
Illustrative

Illustrative workspace

Planned

The layout below is a conceptual sketch for discussion. Names, boundaries and dependencies will change once implementation is public. It is not an installable project and there is nothing to clone today.

ILLUSTRATIVE CONCEPTUAL SCHEMA — NOT AN IMPLEMENTED API CONTRACT
kaporeal/            # conceptual Cargo workspace
  crates/
    kp-domain/       # Load, Stop, Carrier, ShipmentEvent types
    kp-lifecycle/    # state transitions + validation
    kp-store/        # PostgreSQL persistence (SQLx, proposed)
    kp-api/          # HTTP service core (Axum, proposed)
    kp-events/       # outbox, subscriptions, provenance
    kp-edi/          # X12 mapping research
    kp-edge/         # no_std-friendly device protocol
  apps/
    dispatch-ui/     # Dioxus web + desktop
    dock-tablet/     # Dioxus mobile
    edge-gateway/    # embedded / ARM gateway

Dependency direction

Domain crates depend on nothing operational. Storage, API and UI crates depend on the domain, never the other way around. Edge crates stay small enough to compile for constrained devices.

Early access

Follow the Core TMS MVP — or ask us anything.

Join the early-access list for build updates and collaboration invites, or send an operational question straight to the Kordspace team.

Don't include credentials or sensitive freight documents.