Production Readiness

Vorliq readiness is a technical quality gate that combines health, deployment, security, storage, derived index, migration readiness, backup, incident, audit, API, node, and release signals into one pass, warning, or fail result.

Included Checks

• Backend health, API version, version metadata, and deployment commit availability.
• Security status, admin route protection, storage health, derived index health, backup freshness, and incident state.
• Migration readiness metadata, expected JSON backend status, storage adapter interface availability, PostgreSQL shadow rehearsal availability, and confirmation that no PostgreSQL adapter is active in production.
• Audit manifest availability and server-side hash-shape verification.
• Snapshot endpoint availability, regenerated snapshot verification, snapshot secret-scan status, signed snapshot status, and signed snapshot archive status.
• Network manifest source metadata, registry active node count, node sync comparison, public node activity, chain validity, mining status, treasury, faucet, and analytics availability.

Node Sync Signals

Node sync comparison is available at /api/nodes/compare, node monitoring is available at /api/nodes/monitor, and both appear on the live Node Sync page. synced means active, valid, same trusted height, and same latest hash. behind means valid but lower. ahead is a warning because a higher height is not automatically trusted until signed snapshots and audit exports verify the newer state. forked means a comparable latest hash mismatch. stale, unreachable, and unknown mean the operator should repair heartbeat, DNS/HTTPS, diagnostics, or missing data.

Readiness includes node_monitor_status, node_monitor_warning_count, and node_monitor_critical_count. A stale old community node is a warning-only operator signal by default. An active fork, trusted public node outage, trusted public node fork, trusted snapshot signature failure, or missing trusted state is critical and can create a public incident.

Status Meaning

• Pass: score is at least 90 and no critical or high-severity gate failed.
• Warning: score is at least 70 with no critical failure. Operators should review the warning checks before release confidence is claimed.
• Fail: a critical gate failed or the score is below 70. Operators should not claim production is ready until the failing checks are fixed.

Migration Readiness

Database migration preparation is expected to pass while storage_backend is json, active_storage_adapter is json, database_enabled is false, postgres_active is false, postgres_adapter_enabled is false, and postgres_write_mode is disabled. That is intentional: production has not migrated. The public endpoint /api/migration/readiness and the live Migration Readiness page describe dry-run support, PostgreSQL schema presence, shadow rehearsal tooling, adapter parity checks, CI fixture rehearsal, import simulation tooling, and rollback requirements.

Snapshot Readiness

Readiness includes snapshot_endpoint_available, snapshot_verify_passed, snapshot_secret_scan_passed, snapshot_signature_available, snapshot_signature_verified, snapshot_signature_required, and snapshot_signature_status. These confirm that the public snapshot endpoint responds, regenerated hashes and public status checks are coherent, forbidden secret markers are absent, and signature configuration is visible without exposing private keys.

Readiness also includes snapshot_archive_available, snapshot_archive_latest_verified, and snapshot_archive_signature_valid. An empty archive is a warning. Once an archive exists, invalid archive hashes or signatures fail readiness.

Production signed snapshots are required after live signature verification. If VORLIQ_REQUIRE_SNAPSHOT_SIGNATURE=true, missing or invalid signatures fail readiness. If signing is temporarily disabled and signatures are not required, readiness may still pass with a low-severity unsigned note until operators restore signing.

Run the CLI Gate

node tools/check_readiness.js https://vorliq.org
node tools/check_readiness.js https://vorliq.org --allow-warning

The command exits with code 0 on pass, 1 on warning unless --allow-warning is provided, and 2 on fail.

Operator Response

For a warning, review the named checks and decide whether the release should proceed. For a failure, pause the release, fix the underlying service or configuration, rerun tests, and rerun the readiness gate. Readiness is technical quality evidence only; it is not a promise of legal status, banking safety, investment value, or financial outcome.