bus-status — workspace readiness and close-state status
bus-status — workspace readiness and close-state status
bus status is the quick health check for a BusDK workspace. Use it when you want to know whether the core datasets exist, whether evidence links are missing, or whether a close still has blockers before you start producing reports.
Common tasks
Check whether the workspace has the minimum datasets and whether the latest period looks ready:
bus status readiness
Check evidence coverage for one year and fail the command if anything is still missing:
bus status evidence-coverage --year 2026 --strict
Ask for a machine-readable close review report for a Finnish year-end close:
bus status close-readiness --year 2026 --compliance fi --format json \
-o ./out/close-readiness-2026.json
Synopsis
bus status readiness [--year <YYYY>] [--strict] [--compliance [fi]] [-C <dir>] [-f <text|json|tsv>] [-o <file>] [global flags]
bus status evidence-coverage [--year <YYYY>] [--strict] [-C <dir>] [-f <text|json|tsv>] [-o <file>] [global flags]
bus status close-readiness --year <YYYY> [--strict] [--compliance [fi]] [-C <dir>] [-f <text|json|tsv>] [-o <file>] [global flags]
bus status vm [--api-url <url>] [--token-file <path>] [-f <text|json|tsv>] [global flags]
bus status containers [--api-url <url>] [--token-file <path>] [-f <text|json|tsv>] [global flags]
Commands
readiness is the fastest general check. It tells you whether core datasets such as accounts, journal, and periods are present, what the latest period is, and whether the workspace looks ready for close-related work.
evidence-coverage focuses on audit evidence. It reports how many rows in journal, bank, sales, and purchase scopes have evidence links and which IDs are still missing links.
close-readiness is the higher-level year-end view. It combines artifact presence, evidence coverage, period close state, VAT filing parity, and deterministic blocker rows into one report.
vm and containers are AI Platform aggregate status views. They use the Go
clients from bus-vm and bus-containers, so
bus-status provides the status UX while those modules define the HTTP API
contracts.
Before using them, set the API URL for the deployment and authenticate with
bus auth or provide a token file. VM status requires vm:read; container
status requires container:read. The normal Bus auth token from the user
config root is used when no token file or environment token override is set.
What the output tells you
readiness includes fields such as accounts_ready, journal_ready, periods_ready, latest_period, latest_state, and close_flow_ready. This is the command to use when you want a fast “is this workspace basically ready?” answer.
evidence-coverage summarizes total_rows, linked_rows, and missing_rows by scope. The detailed rows give you the missing identifiers you need to fix, such as source_id, voucher_id, bank_txn_id, or invoice_id.
close-readiness adds blocker rows and reason codes. This is the command to use before close, evidence-pack generation, or filing preparation when you want a single machine-readable answer about what still blocks the process.
Options users typically need
--year <YYYY> scopes the check to one fiscal year. --strict turns warnings into a failing exit status, which is useful in scripts and CI. --compliance or --compliance fi adds legal/compliance demand evaluation for Finnish close checks. -f json is the easiest output choice for automation, and -f text is usually the easiest for interactive review.
These commands use Standard global flags. In practice the most useful ones here are -C for choosing a workspace, -o for saving JSON output, and -f for switching between text, tsv, and json.
Typical workflow
Many users run these commands in a simple sequence:
bus status readiness --year 2026
bus status evidence-coverage --year 2026
bus status close-readiness --year 2026 --compliance fi
bus status vm --format json
bus status containers --format json
If close-readiness still reports blockers, the blocker rows usually tell you whether to continue in bus-attachments, bus-bank, bus-journal, bus-reconcile, or bus-reports.
Examples
bus status readiness
bus status readiness --year 2026 --format json --output ./out/status.json
bus status evidence-coverage --year 2026 --format text
bus status close-readiness --year 2026 --compliance fi --strict
bus status -C ./workspace readiness --format tsv
BUS_AI_TOKEN=... bus status --api-url https://ai.hg.fi vm --format json
BUS_AI_TOKEN=... bus status --api-url https://ai.hg.fi containers --format json
For AI Platform status commands, bus status uses the normal Bus API token
from ~/.config/bus/auth/api-token or ${BUS_CONFIG_DIR}/auth/api-token by
default. Explicit --token, --token-file, BUS_AI_TOKEN, and
BUS_API_TOKEN override that default.
Exit status
0 on success. Non-zero on invalid usage, evaluation errors, or --strict runs that find failing gates or blockers.
Using from .bus files
Inside a .bus file, write this module target without the bus prefix.
# same as: bus status readiness --format json
status readiness --format json
# same as: bus status evidence-coverage --year 2026 --strict
status evidence-coverage --year 2026 --strict
# same as: bus status close-readiness --year 2026 --compliance fi --format json
status close-readiness --year 2026 --compliance fi --format json