Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/bitwikiorg/init.md/llms.txt

Use this file to discover all available pages before exploring further.

After the VALIDATE stage completes, initialization concludes with a report that includes one of four standard result states. The result state is the primary answer to the question: is this target operational? It is not a summary of effort — it is a factual statement about the target’s current condition based on what was actually validated.
Do not report OPERATIONAL without a validation step tied to the target’s actual operation. Completing the CREATE and CONFIGURE stages without running any validation does not constitute a successful initialization.

OPERATIONAL

All required validation passed. The target is ready to operate as intended.

OPERATIONAL_WITH_WARNINGS

The target can operate, but minor issues remain. Warnings are documented in the report.

BLOCKED

One or more critical requirements cannot be satisfied. Operation is not possible until resolved.

DRY_RUN_COMPLETE

Used exclusively for dry-run mode. No changes were made. The report contains proposed work.

​
OPERATIONAL

OPERATIONAL
Report OPERATIONAL when all required validation steps have passed and the target is ready to function as intended. This state asserts that initialization succeeded fully — nothing critical is missing, nothing is misconfigured, and the target can be operated without further setup. Report should include:
  • what was validated and which checks confirmed operational status
  • the location of key output artifacts
  • any optional steps that were skipped with an explanation of why they were not required

​
OPERATIONAL_WITH_WARNINGS

OPERATIONAL_WITH_WARNINGS
Report OPERATIONAL_WITH_WARNINGS when the target can operate but one or more non-critical issues remain. The target is usable, but the operator should be aware of the outstanding items. This state is not a failure — it is an honest account of a target that works while acknowledging imperfections. Report should include:
  • what was validated and confirmed working
  • a clear list of each warning, what it refers to, and why it does not block operation
  • recommended follow-up steps to resolve the warnings when convenient

​
BLOCKED

BLOCKED
Report BLOCKED when one or more critical requirements cannot be satisfied and the target cannot operate in its current state. Blockers are requirements that must be resolved before initialization can be completed successfully. Report should include:
  • what was validated and what passed before the blocker was encountered
  • a clear description of each blocker: what is missing, what failed, and why it is critical
  • what the operator must do to resolve each blocker
  • whether partial initialization work was performed and whether it is safe to leave in place

​
DRY_RUN_COMPLETE

DRY_RUN_COMPLETE
Report DRY_RUN_COMPLETE exclusively when the initialization was run in dry-run mode. This state confirms that the procedure completed its inspection and determination phases, produced a full report of proposed work, and made no changes to the target. Report should include:
  • what was inspected and what the current state of the target is
  • a complete description of what Active mode would create, configure, validate, and report
  • any issues identified during inspection that would become blockers or warnings in Active mode
  • an explicit confirmation that no changes were made to the target

Build docs developers (and LLMs) love

Get started for freeTalk to us