Integration verification
Use an installed SDK and real sample operations. Read the language sample first; fixture values are not real customer credentials.
| Case | Expected result |
|---|---|
| Customer activation | start → customer login/approval → poll → valid result |
| Manual transport | request → portal import → activation.signox → apply on the same protected device |
| CSV permission | Write two rows only when valid AND demo_export is true; missing feature exits 3. |
| Tampering | Wrong product, request, signature or target cannot unlock the app. |
| Repeat request | Same request is idempotent; no second active device. |
| Replacement | Another target requires vendor approval tied to that request. |
| Explicit denial then disconnect | A protected client retains the signed denial and does not unlock from an old grant. |
| App branding | Login, signup, reset and separate request tabs keep the server-provided app identity. |
Record command, exit code, expected value, observed value and local evidence path. Pending approval, unavailable hardware and unexecuted checks are pending/not_run, never pass. Do not include license keys, tokens, private state or decrypted proofs in a report. The current physical offline revocation/rollback limits remain even if every software test passes.