LLM Quick Reference

Use the installed Signox SDK 0.3.1 (0.3.1-SNAPSHOT for Java). Read the language guide for exact signatures. The public entry point for new integrations is ActivationClient.

1. Workflow model

App creates a public request → customer portal resolves app branding → customer signs in and selects an owned license → explicit device approval → server reserves the registration and issues a signed response → app verifies/applies it → actual feature gate.

Automatic transport: start returns a portal URL, the host opens a system browser, and poll receives the result. Manual transport: export request text/file, import at customer portal /activate on a connected computer, carry activation.signox back, and apply its contents. These transports use the same ownership and one-device policy.

2. Decision defaults

• Use the SDK matching the app language. Do not implement signature checks or hardware enumeration in application code.
• Let the SDK select the device provider. Do not ask an end user to choose TPM versus another device technology.
• Use the provided evaluation API URL. Default SDK URLs do not prove that a test environment exists there.
• Ask once for missing real inputs. Do not invent keys, replace the SDK with a mock, or silently use a new state directory after corruption.
• An offline grant requires supported and explicitly trusted device protection. A machine without it must connect to apply its initial approval; network grace cannot bootstrap an empty installation.

3. Inputs and invariants

Input	Meaning
Product UUID	Product ID from the vendor dashboard URL.
Product SPKI PEM public key	Pinned in the trusted app distribution; not fetched from an untrusted request.
API base URL	Supplied evaluation or production endpoint.
Private persistent state directory	Unique to the installation; preserve through restarts and updates.
Test customer/license	Owned or claimed in the customer portal; never embed a customer password in the SDK app.
Feature code	A concrete permission such as demo_export.

One license has exactly one active server registration. Issuance reserves the device; it is not proof of application. The customer’s realm is separate from vendor and administrator realms. Product branding comes from server data and does not substitute for ownership checks.

Only VALID and IN_GRACE_PERIOD permit use. Require valid AND the relevant feature value inside the real operation. A valid license without the CSV feature must not write a file.

4. SDK entry points

Language	Construction	Operations
Node	new ActivationClient({productId, productPublicKey, baseUrl, stateDir})	async start, createRequest, poll, applyResponse, validate, deactivate
Java	new ActivationClient(productId, config, File stateDir)	synchronous camelCase operations with the same names
C#	new ActivationClient(productId, options, stateDir)	synchronous Start, CreateRequest, Poll, ApplyResponse, Validate, Deactivate
Python	ActivationClient(product_id, product_public_key, state_dir=..., base_url=...)	synchronous start, create_request, poll, apply_response, validate, deactivate

Import receives response TEXT, not a file path. A create-request method returns public JSON; keep private credentials app-side. Poll at intervals of at least 3 seconds. pending is not success. application_failed means a response arrived but validation did not succeed; inspect its result. applied plus a valid result confirms application.

5. Scenario entry points

Scenario	Sequence	Documentation
First connected activation	start → customer browser approval → poll → validate → feature	/guides/activation-online/
Disconnected device	createRequest → portal file import/approval → applyResponse(text) → feature	/guides/activation-offline/
Expired request	create a renewed request using the preserved identity; repeat approval	language SDK guide
Restart/update	reuse the same private state	/guides/hwid/
Same protected identity	request recovery; do not allocate a second active target	/guides/hwid/
New device/lost unrecoverable identity	customer reason → vendor review of the exact destination request	/guides/activation-online/
Real app acceptance	run the language sample; verify actual CSV write and refusal	/samples/{language}/ and /guides/integration-checks/

6. Device protection and recovery

Linux uses the TPM 2.0 runtime. Windows uses the Microsoft Platform Crypto Provider; macOS uses a Secure Enclave key. Each has a separate provider implementation under the common SDK entry point. Check the runtime matrix and recorded verification scope before claiming OS/device support. Software RSA/ECDH fixtures prove wire interoperability, not hardware origin.

An operator must verify a public key on the real device through a trusted channel before enrollment. A provider label in customer JSON is not attestation. No automatic manufacturer-certificate validation or USB provider is supplied.

Windows recovery requires the platform key to remain accessible. macOS retains only Secure Enclave-wrapped signing/agreement handles in private state. Losing those handles or a full format may require reviewed transfer. Do not infer recoverability merely from a matching machine name. The Linux trusted hardware anchor can recover a registration with a new local AK.

7. Failures and grace

• STATE_INVALID: restore state; do not silently replace installation credentials.
• DEVICE_TRUST_REQUIRED: operator enrollment is needed before the portal can issue.
• TRANSFER_REQUIRED: request review from the destination device; never clear a protected slot automatically.
• ACTIVATION_RESPONSE_INVALID: wrong product/request/device, corrupt envelope or invalid signature. Deny use.
• REQUEST_EXPIRED: request lifetime is seven days; renew the request.
• NETWORK_ERROR: temporary transport/service failure. Only previously valid signed rights may cover disconnection.
• REQUEST_ERROR: permanent HTTP/input/access failure. Correct it instead of endless retry.
• SUSPENDED, REVOKED, EXPIRED, signature or nonce failure: do not override with an old grant. Retain signed denial across subsequent connection failures.

Network grace follows signed networkGraceDays, capped by the SDK’s local limit. Expiry grace uses gracePeriodDays. Neither supplies new permanent offline rights.

8. Common mistakes

Do not treat request registration, response issuance, receipt confirmation and active use as the same event. Do not export the state directory, raw retrieval secret, decrypted wrapping key or customer credentials.

Do not claim that deleting a license file or formatting a machine proves secure return. Protected/offline grants cannot be immediately revoked while permanently disconnected. Software clock/denial records do not resist full state rollback. Vendor-approved replacement records this uncertainty; it does not prove zero overlapping physical use.

9. Verification and documentation routing

Use real packages and real app operations. Test valid and feature-denied licenses, altered response, restart, replacement review, wrong app and explicit denial followed by disconnection. Record command, exit code, expected/observed result and local evidence. Mark unavailable hardware and unexecuted checks not_run; approval waits are pending.

Preserve the initial attempt, collect Q&A in a separate local file, and propose improvements after the independent test. Do not call a mock or a test fixture a real device result.

Start at /start/install/, then /sdk/{node|java|csharp|python}/. Prefix /en for English. The documentation MCP provides list_docs({locale?}) and read_doc({slug,locale?}), default locale ko. llms.txt lists pages; replace a page’s final / with .md for source. The page title includes a Markdown copy action.