Documentation

Operations

Secure operation & data ownership

Proposed organization boundaries, least privilege, auditability and recovery requirements—not a security certification.

Educational / conceptual specification · Not a released implementation contract

Isometric stacked platform tiers with trucks, warehouses and servers linked by orange lines
Illustrative

Access must apply across the relationship

Organization scope needs to cover loads, stops, events, attachments, exports and integration mappings. Hiding a record in the UI is not access control. A future implementation must enforce permissions wherever information can be read or changed, including background exchanges.

Role design should reflect operational responsibility and least privilege. External portal actors should receive only the freight context they need, not another organization's records or internal commercial terms. Authentication and permission controls remain planned or unverified until source and behavior can be reviewed.

Audit and secret handling

An audit trail should explain important actions, source messages and state changes without collecting unnecessary sensitive information. Integration credentials need protected storage, rotation and redaction from logs. Attachment access should follow its related entity's authorization boundary.

Transport security, dependency maintenance, retention, recovery and incident procedures are requirements for future secure operation. No certification, compliance outcome or enterprise-grade security claim is made by this guide.

Access review and incident preparation

A future access review should inventory operational roles, service identities and external portal actors, then verify both allowed and denied actions across loads, events, documents and exports. Revocation must remove access at the enforcement boundary, not only hide a screen. Integration credentials should be separately scoped so a compromised connector cannot become an unrestricted operator.

Incident preparation should identify the responsible owner, containment options, credential-rotation process and evidence to preserve. Recovery work should distinguish restoring availability from confirming data integrity after interrupted mutations or integrations. These are requirements to implement and test before production use, not a current incident-response service or security certification.

Ownership includes recovery

Data control should include exportable records, preserved document references and a tested restore path. An organization cannot meaningfully own its operational system if its backups exclude delivery evidence or its export loses the relationships needed to interpret a load.

The self-hosting design must document responsibility for upgrades, storage and security. Future intelligence features should be explainable and human-reviewed; they must not make unverified safety, compliance or financial decisions. None of these controls are represented as deployed here.

Read deployment requirements

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.