Disconnected environments

The SDK needs a reachable VeriProof endpoint for initial setup and central workflows. An entitled Edge Gateway can keep ordinary governance calls local during a central-service interruption.

Distinguish a blocked public internet connection from a fully disconnected environment. Review the actual service paths, not only the network label.

Evaluate the requirement

Document the exact boundary before deciding whether the current release can support the workload:

• Which systems have no outbound connectivity?
• Can VeriProof services run inside the same approved Azure boundary?
• Which policy checks must occur before an action?
• Which reviewers and identity services must be reachable?
• Which evidence must leave the boundary for review?
• Is a public proof provider permitted?
• Can Azure SQL Ledger and its verifier workflow operate within the approved model?
• How will releases, vulnerability fixes, backup, restore, and support enter the environment?

Current options

A Customer-managed Azure design may meet a restricted-network requirement. Confirm every required service path during solution review, then test it in the target environment.

The Edge Gateway can continue with its last confirmed running state while its signed policy lease and authenticated governance profile remain valid. It stores accepted evidence and stop acknowledgements in its journal for later reconciliation. Keep the journal volume across restarts.

The Edge Gateway fails closed when a required policy or governance profile expires. Human Review, shared portal controls, initial application binding, policy updates, and central reconciliation still require an approved path to the central service.

If a required dependency cannot be reached through an approved path, do not approve that workflow.

Start with the Edge Gateway setup, Customer-managed Azure responsibilities, and deployment overview.