What is implemented, and what is proposed
Kaporeal is planned in Rust. The proposed shape is a Cargo workspace of domain crates, a modular-monolith service core (Axum and SQLx on PostgreSQL are the leading candidates) and Dioxus for web, desktop and mobile interfaces from one component model. The same language can later reach edge gateways, dock devices and embedded telematics. None of this is released; the public website is a separate TypeScript build and should not be mistaken for the product.
Architecture decisions should remain accountable to operational scenarios. The core MVP needs a consistent load, assignment, event and document workflow. The documentation therefore emphasizes domain vocabulary, ownership and exception paths before offering installation or endpoint examples.
Entities should carry responsibilities
A Load is not simply a row with a status field. It relates a transportation commitment to its customer, stops, execution partner, milestones and evidence. A Carrier is not a compliance certification; identifiers and insurance notes remain records until a verified process or integration establishes their meaning.
Engineering teams can review the conceptual relationships between Organization, User / Role, Customer, Carrier, Driver, Equipment, Load, Stop, ShipmentEvent and Document. Quote, Rate and Invoice extend later commercial workflows. These names communicate proposed boundaries, not finalized migrations or a released schema.
Extension contracts over direct table coupling
PlannedAn extension should request an operation through a domain interface, preserve organization scope and declare the events or fields it uses. A warehouse connector should translate readiness into transportation context, not mutate unrelated dispatch records through an undocumented shortcut.
Custom fields, event subscriptions, import mappings and module interfaces are planned extension points. Versioning, validation, deduplication and access controls must be part of their design. A successful module system is measured by safe interoperability, not the number of conceptual module names on a diagram.
Deployment documentation must follow verified software
PlannedSelf-hostability is a design goal. Before a quickstart can be credible, the project needs a public source release, license decision, supported configuration, reproducible migrations, storage guidance and a tested upgrade / restore path. Docker and hosting discussions remain deployment designs, not an available installer.
There are no clone commands or placeholder environment instructions here. The deployment-readiness guide explains the questions a future release must answer, so operators do not mistake architectural intention for production readiness.
Contribute a constraint, not just a feature request
Useful early input describes the actor, source of truth, required evidence and exception path. An anonymized carrier reassignment, disputed POD or warehouse short-load example can expose a model weakness more clearly than a request for another dashboard chart.
Code contribution channels will be announced with public source release. Until then, use the contact page to reach Kordspace with research or contribution interest. Do not share credentials, customer-identifiable freight records or private commercial documents in an initial conversation.
