Architectural overview
Module architecture
BusDK is a collection of loosely coupled modules for CLIs, API providers, event workers, portals, runtime clients, and auditable workspace datasets. It intentionally avoids a monolithic application design. Each feature area is implemented as an independent command, service, provider, or worker with a stable external contract.
For business-data modules, the stable interface is the workspace dataset: tables governed by schemas and organized in a consistent directory structure. For AI product modules, the stable interface may also be an HTTP route, event name, token scope, portal surface, or runtime worker contract. Modules should coordinate through those public contracts instead of calling each other’s private internals.
This design mirrors the practical benefits of Unix composability in modern toolchains, where interoperability arises from stable, simple interfaces and predictable conventions. See The Art of Unix Programming: Basics of the Unix Philosophy. The preferred default for workspace data is a Git repository with CSV tables, but Git and CSV are implementation choices rather than the definition of the architectural goal. The broader goal is deterministic operation across local CLIs, self-hosted services, managed deployments, and reviewable data workflows.