KAPOREAL / OPEN-SOURCE TMS RESEARCH & DEVELOPMENT
FRAMEWORK / PRE-RELEASEOpen infrastructure for
the movement of goods.
Kaporeal is an open-source transportation management framework in development at Kordspace. Beginning with loads, dispatch, carrier coordination, shipment events and documents, its modular architecture is designed to connect freight operators, warehouses and the systems around them.
01 / The operating problem
Freight moves across systems.
Its context should travel with it.

Transportation operations span spreadsheets, inboxes, PDFs, phones, dispatch systems, telematics, WMS, ERP and accounting. A warehouse can know what is staged while a dispatcher is still chasing coverage. A delivery can be complete while its proof remains buried in an inbox.
Without shared freight context, teams repeatedly reconcile references, recover missing PODs and investigate delayed invoices or operational blind spots. Kaporeal's direction is a coherent transportation record connecting those handoffs—not an unsupported promise of instant efficiency or a replacement for every specialist system.
Why an open foundation matters02 / From dispatch to connected operations
The core is transportation.
The edges are deliberately open.

Start with a dependable freight model. Extend operational workflows. Connect outside systems through explicit contracts. Insights and automation follow reliable evidence.
Core transportation records
Load · Stop · Customer · Carrier
Operational modules
Dispatch · Documents · Milestones · Equipment
Integration edges
WMS · ERP · Telematics · EDI · Accounting
Insight & automation
Reporting · Decision support · Responsible AI research
03 / Lifecycle from quote to close
A movement is more than a status.

Requested, assigned, arrived, loaded and received are different facts. The conceptual lifecycle keeps commercial context, physical events and document evidence distinct. Core steps remain in progress; quoting and financial closure are later work.
ILLUSTRATIVE LIFECYCLE / NOT SHIPPED OPERATIONAL FUNCTIONS
- 01
Request / quote
Planned - 02
Load created
In Progress - 03
Carrier assigned
In Progress - 04
Pickup
In Progress - 05
In-transit events
In Progress - 06
Delivery
In Progress - 07
BOL / POD
In Progress - 08
Invoice readiness
Future - 09
Closure
Future
04 / Operational systems converge
Shared records.
Purposeful operational views.

The module map is conceptual, not a count of shipped capabilities. Each target exists to support an operator decision and preserve the evidence behind it.
Loads & shipment context
A shared reference links customers, facilities, freight attributes and stop expectations without becoming an inventory ledger.
Dispatch & partner records
Coverage and reassignment need clear carrier context, accountable decisions and a history that survives changed execution.
Documents & event evidence
BOL, POD and observed milestones tell different parts of the handoff. Expected evidence is not validated evidence.
Integration edges
Warehouse, ERP and accounting systems retain their authority. Proposed adapters carry references, provenance and recoverable outcomes.
Awaiting assignment
Distributor → Regional hub
Carrier context required
Pickup handoff
Manufacturing → Distribution
Loading observation expected
Document review
Hub → Receiving facility
POD completeness to review
Fictional records show intended information structure. No live loads, metrics or tracking are displayed.
05 / Warehouse meets the highway
The most important interface
may be the loading dock.

WMS
Inside the facility
- Inventory & locations
- Pick / pack / stage
- Handling units & receipt
Kaporeal / TMS
Between facilities
- Load & carrier assignment
- Appointments & movement
- Milestones & freight documents
ERP / Accounting
Commercial system of record
- Orders & customer accounts
- Financial posting & tax
- Payables / receivables
A warehouse management system controls the work inside a facility: inventory locations, picking, packing, staging and receiving. A transportation management system coordinates the movement between facilities: carrier assignment, stop windows, freight milestones and delivery evidence. An ERP supplies commercial and financial context. The three systems need shared references, not overlapping ownership of every rule.
For outbound freight, a warehouse's ready-to-ship signal can provide shipment references, handling units and dock requirements. A future Kaporeal exchange would connect that context to a load and carrier, keeping readiness distinct from an appointment, arrival, loading or departure. Pallet and case identifiers should survive the handoff without asking the TMS to manage warehouse stock locations.
Inbound receiving needs more than a vehicle position. Teams need the expected shipment, a meaningful arrival estimate, observed milestones and a way to report shortages or damage against the same references. A received quantity remains a warehouse fact; the transportation record preserves the movement and its proof. Cross-docking later adds transfer relationships between inbound and outbound freight that cannot be captured by one generic delivered status.
Appointment scheduling, ASN / receiving context, handling-unit linkage and exception exchanges are planned. No WMS adapter or standards implementation is verified today. The purpose of the warehouse direction is to make these boundaries explicit before promising interoperability, so facility supervisors and integration engineers can challenge the model with actual handoff requirements.
Read warehouse connectivity06 / The deployment philosophy
Own the model.
Choose the infrastructure.

Modular design and API-first contracts should let organizations adapt the transportation layer without surrendering their data or replacing every existing system. A proposed relational core and explicit extension boundaries favor a coherent operational model over premature distributed complexity.
Self-hostable by design is the intended deployment posture. It is not a current installer, a tested production release or a hosted subscription. Public source, licensing, migration guidance, backups and restore procedures must accompany credible deployment instructions.
07 / Who shapes Kaporeal
Operators and engineers
need a common language.

Brokers, dispatchers, fleet operators, warehouse supervisors, 3PL software teams and industrial shipping departments see different edges of the same freight story. Open-source engineers can translate that operational knowledge into durable models and contracts. Kordspace founded Kaporeal to bring those perspectives into an adaptable transportation foundation.
No customer logos, community counts or installed deployments are invented here. Useful early collaboration begins with a workflow, an exception or a handoff that needs to be explained more clearly.
Explore six operating scenariosBuilt in Rust,
from the service core to the loading dock.

Kaporeal is planned as a Rust codebase. Domain crates define loads, stops, carriers and shipment events once; a modular service core, Dioxus interfaces for web, desktop and mobile, and future edge runtimes all share those exact types.
That uniformity is the differentiator. The event a dock-door sensor or telematics gateway emits can be the same structure the dispatch board renders, with no vendor translation layer in between. Memory safety and predictable performance matter for software that has to run unattended for years.
Stated direction. No crates or binaries are public yet.
08 / Roadmap with honesty
Ambitious direction.
No imaginary release.

Website / Project Foundation
AvailablePhase 02Core TMS MVP
In ProgressPhase 03Operations Expansion
PlannedPhase 04Integrations & Automation
PlannedPhase 05Enterprise & Hosted
FutureHelp shape an open foundation for transportation.
The core TMS is in development. Bring an operational question, a modeling challenge or contribution interest to the next stage of Kaporeal.



