Conceptual specifications
Modules & extension contracts
Proposed module ownership, typed custom fields and versioned interfaces without unsafe direct record coupling.
Educational / conceptual specification · Not a released implementation contract
Extensions should respect domain ownership
A warehouse adapter should translate readiness into a transportation operation through a defined interface. It should not change dispatch, commercial and document records directly because it happens to know their table names. The same principle applies to future portals and specialized modules.
Proposed contracts should declare required scope, accepted input, possible outcomes and emitted events. Core invariants remain owned by the domain. This keeps incremental adoption meaningful: an added module does not silently redefine what a delivered load means.
Custom fields need a schema of their own
Customer-specific reference fields are useful when their meaning is clear. Types, validation, organization scope and export behavior should be explicit. An untyped blob that contains a hidden carrier assignment undermines the very relationship the core is supposed to preserve.
Module interfaces, custom fields and subscriptions are planned extension directions, not a shipped plugin SDK. Public source release should distinguish stable contracts from experimental internals and describe migration behavior when a contract changes.
Test the boundary, including failure
A future extension test should cover invalid references, denied scope, duplicate delivery and partial failure as well as a successful handoff. An adapter that creates a second load on retry is not safe merely because its happy-path payload validates.
Early contributors can supply anonymized contract examples and exception narratives. Do not submit credentials, production payloads containing personal information or commercially sensitive documents. The contact page provides a genuine path to Kordspace rather than a private repository link.