FAQ: What are bus and BusDK?

What is bus?

bus is the public command entrypoint for BusDK workflows. It is the command users run first, and it dispatches to focused module commands such as bus journal, bus invoices, bus reports, and bus vat.

bus is designed for scriptable, non-interactive use. The same commands can be used directly in terminal sessions, CI jobs, and deterministic .bus script files.

What is BusDK?

BusDK is the broader Business Development Kit around bus. It includes the command ecosystem, documentation, schema-driven workspace data conventions, and module-level implementations that cover accounting and business operations workflows.

In short, bus is the main executable entrypoint, and BusDK is the full system and module family behind it.

How do bus and BusDK relate?

bus is part of BusDK. BusDK provides architecture, contracts, modules, and docs. The bus command gives users one stable way to invoke those capabilities.

When a workflow needs specialization, bus routes to the corresponding module surface. This keeps the top-level command simple while still supporting deep domain functionality.

Is BusDK one monolith or many modules?

BusDK is modular by design. The superproject pins multiple module repositories and exposes a consistent command surface through bus.

This modularity allows independent lifecycle management by domain area while preserving predictable user-facing behavior.

Why not just one big CLI?

A single monolithic CLI becomes harder to evolve safely across multiple business domains. BusDK uses module boundaries so changes remain reviewable, testable, and easier to audit per capability area.

Users still get a coherent experience through the shared bus command structure and global flag conventions.

What problem does BusDK solve?

BusDK focuses on deterministic, replayable, and review-friendly business operations. In accounting-oriented flows this means schema-backed data, explicit workflow steps, traceability, and CLI-first automation that can run the same way in local environments and CI.

Is BusDK only for accounting?

No. Accounting is a major current use case, but the architecture is broader. BusDK also includes development and automation modules such as bus-dev and bus-run, API integration paths through bus-api, and UI modules such as bus-ledger and bus-factory built on shared components.

The core model is reusable: explicit data contracts, deterministic command behavior, and modular capability boundaries.

What is a BusDK workspace?

A workspace is a repository-shaped working area that contains datasets, schemas, and .bus automation scripts. Commands run against this workspace data and produce outputs deterministically from declared inputs.

This keeps operations reproducible and easier to review over time.

What are .bus files?

.bus files are deterministic command scripts for Bus workflows. They let teams encode repeatable sequences instead of relying on manual command history.

They are useful for standard operating procedures, periodic runs, and machine-verifiable replay of workflows.

How do I decide whether to use bus or a module command directly?

Start with bus. Use module subcommands when the workflow needs specific domain controls. In practice this is usually bus <module> ..., which keeps commands discoverable and consistent through the module CLI reference.

Direct module binaries exist in module repositories, but normal user workflows should prefer the bus command surface unless there is a module-specific reason not to.

Is BusDK open source?

BusDK is partly open source, but mostly commercial subscription-based software. The superproject, bus, docs, and busdk.com are public, while many bus-* modules are private/commercial repositories.

For users, the command surface remains consistent. For maintainers, this separation keeps public orchestration and documentation clean while allowing private module implementation boundaries.

Does BusDK include a web UI?

Yes. BusDK includes UI modules such as bus-ledger and bus-factory. These UIs use shared bus-ui components and still follow the same deterministic, workspace-local operating model as CLI workflows.

Where should I start?

Start with the docs overview, then the workflow pages, then module reference pages for concrete commands. If you are implementing or integrating modules, continue from there to the private SDD workspace for detailed design contracts.