Document integration readiness without implying live execution

A provider name in a settings screen can mean several different things: a configuration exists, credentials have been supplied, a test succeeded, or execution is enabled. Display those states separately. A single green "connected" badge can imply live behavior that nobody has exercised.

Model readiness explicitly

This synthetic provider record separates a successful test from permission to execute. All values are illustrative and refer to no real payment, messaging or calling account.

provider = {"configured": True, "credentials_present": True,
            "test_passed": True, "execution_enabled": False}
def can_execute(state):
    fields = ("configured", "credentials_present", "test_passed", "execution_enabled")
    return all(state.get(name) is True for name in fields)

assert can_execute(provider) is False
assert can_execute({**provider, "execution_enabled": True}) is True
assert can_execute({"configured": True}) is False

This decision function is only a local policy fixture. An execution path must enforce its own authorization and recheck state at the time of the action. A UI calculation cannot stop a direct API request.

Configuration, credential presence, scoped test evidence and enablement are separate inputs to an action-time policy check.

Record the test scope and age

A credential-format check is different from an authenticated read request, and both differ from sending a real message or creating a payment. Save the test type, completion time and controlled result. Credentials can expire after a successful check, so show when the observation was made and define when another check is required.

Use a schema to reject missing or unexpected fields in records exchanged between services. JSON Schema's object documentation explains that declaring properties alone does not make them required. Add a required list and an explicit policy for extra properties. Boolean readiness fields also need boolean types; the string "false" must not become truthy by accident.

Keep documentation aligned with execution evidence

Nirogidhara's public README distinguishes implemented work from production verification still pending in its phase notes. Apply the same discipline to provider descriptions: integration code or a visible provider card does not establish live calling, payments or messaging. A test performed with a sandbox account should remain labeled as sandbox evidence.

The assertions above check a synthetic policy without contacting any provider. References: JSON Schema objects and Nirogidhara README. See the project overview for the portfolio context, with implementation and operational claims read separately.