Clavis docs

Documentation

Technical material removed from the main business-card page: implementation details, reference lists, supported policy models, and the audit architecture.

How it works

The vendor writes a signed and encrypted entitlement record. The SDK verifies the vendor signature, decrypts the payload, caches policy safely, checks revocation, and returns the current access state.

Entitlement record

Product, features, seats, validity, customer receiving key, lifecycle state, and policy metadata are signed by the vendor and encrypted for the customer.

Issue

A vendor portal, Admin SDK, back office workflow, or confirmed payment event creates or updates the entitlement record.
Verify

The Client SDK reads the record, verifies the signature, decrypts the payload, and evaluates entitlement at runtime.
Resolve access

The product receives a clear access state and can unlock, fall back to a cached grace decision, or show recovery and upgrade paths.

SDK responsibilities

Fetch the latest entitlement record over the configured transport.
Verify the vendor signature before trusting the payload.
Decrypt customer-scoped license content locally.
Cache a verified decision inside the vendor-defined offline grace policy.
Check issuance, activation, renewal, upgrade, downgrade, revoke, expire, seat, and key-rotation state before unlock.
Return an explicit access state such as allowed, expired, revoked, no seats, or grace.

Runtime targets

Simple entitlement check: A narrow SDK runtime-check target can be scoped around 2-6h when the existing product only needs one access decision.
Payment to access: Less than 60 seconds is a target after payment confirmation, not a universal service guarantee.

Comparison ledger

Dimension	Old model	Clavis
Deployment	Vendor daemon, license server, HA pair, VPN path, and firewall exceptions.	Signed entitlement record plus Client SDK. No customer-side internal license host.
Access	Runtime access depends on a reachable server and customer network setup.	The app verifies encrypted entitlement locally and uses a bounded offline grace policy when configured.
Lifecycle	Issuance, activation, renewal, upgrade, downgrade, refund, revoke, expire, and key rotation live in separate systems.	Lifecycle events update the same entitlement state the SDK reads.
Seats	A daemon owns concurrency and can become a hard runtime dependency.	Floating seats use acquire, heartbeat, release, timeout reclaim, and explicit no-seat states.
Usage	Usage reports are usually vendor-side logs or dashboard exports.	Signed usage receipts can support shared counters, dispute review, and customer right-sizing workflows.
Commercial flow	Payment, billing, and manual fulfilment are reconciled after the fact.	Confirmed payment events can issue, renew, mutate, or revoke access state.

Runtime access checks

The product asks for an entitlement, receives an explicit access state, and maps that state to product behavior. Start here before adding lifecycle automation, back-office wiring, or payment events.

Implementation path

Start with the smallest runtime boundary that can prove paid access. Keep lifecycle wiring separate until the product has a stable local entitlement check.

Install SDK

Add the Client SDK to the application build and configure the vendor, product, and environment identifiers.
Initialize

Load the vendor context and customer key material from the platform storage selected for the deployment.
Check entitlement

Call the SDK at startup or feature boundary and branch on the returned access state instead of a raw boolean only.
Handle fallback

Use cached entitlement only within the configured grace policy, and show recovery paths when access is expired, revoked, or unavailable.
Connect issuance

Use the Admin SDK or a confirmed payment event to issue, renew, update, or revoke the entitlement record.

Runtime check

The example below is illustrative pseudo-code, not a package contract.

Pseudo-code

const clavis =
  await createClavisClient({
    vendor: "acme-software",
    product: "desktop-pro",
  });

const access =
  await clavis.entitlements.check(
    "pro",
    { fallback: "cached-grace" },
  );

const okStates = ["allowed", "grace"];
const canUsePro =
  okStates.includes(access.state);

if (canUsePro) {
  enableProFeatures();
} else {
  showLicenseRecovery(access.state);
}

Call the SDK at startup or at the feature boundary where paid access matters.
Branch on explicit access states instead of reducing the result to a boolean too early.
Keep cached access inside the configured grace policy, then show recovery, renewal, or upgrade paths when access is not valid.

Implementation handoff

Names are illustrative. Exact package, key storage, fallback policy, and access-state handling depend on the SDK and deployment profile.

Package and storage: Exact package name, key storage, customer key material, and transport depend on the SDK target and deployment profile.
Issuance boundary: A product can start with the runtime check, then connect Admin SDK, back-office, or payment events when issuance is ready.
Access states: The application should map each returned state to product behavior: unlock, grace, recovery, renewal, no seats, or support escalation.

Key capabilities for licensing operations.

Clavis covers the controls a paid software vendor normally spreads across a license server, billing glue, support workflows, usage analytics, and reporting exports.

Entitlement checks: Feature gates, editions, add-ons, trials, named users, devices, and product tiers resolve through one access-state check.
Lifecycle operations: Issuance, activation, renewal, upgrade, downgrade, revoke, expire, rebind, and key rotation update the same access state.
Floating seats: Acquire, heartbeat, release, timeout reclaim, and overflow policy support concurrent-seat products without a customer-run daemon.
Offline grace: A verified entitlement can be cached within vendor-defined grace limits so short network interruptions do not immediately block work.
Usage analytics: Signed runtime receipts can roll into shared usage counters for metering, dispute review, right-sizing, and customer-facing analytics.
Payments and billing: Confirmed payment, refund, dispute, renewal, chargeback, or invoice events can update the same access state used by the SDK.
Signed event bus: License, seat, payment, billing, policy, key, and usage events can feed automations through signed, idempotent events.
Shared audit trail: Vendor, customer, and application can review the same signed lifecycle and usage evidence instead of reconciling vendor-held logs.

Supported licensing models

Clavis does not force every product into one subscription shape. Common license models become policy fields in signed entitlement state.

Identity and install: Per-user, per-seat, per-device, named-user, device-bound, and hybrid account-plus-local checks.
Floating and concurrent: Concurrent seats with acquire, heartbeat, release, timeout reclaim, explicit no-seat state, and overflow policy.
Packaging: Feature bundles, editions, add-ons, trials, product tiers, and customer-specific policy metadata.
Commercial terms: Subscriptions, perpetual plus maintenance, metered usage, renewals, upgrades, downgrades, and reseller delegation.

For vendors

Clavis fits teams that sell valuable software and need entitlement, seats, lifecycle, and commercial state to stay aligned across customer environments.

Desktop software: Commercial desktop products that need edition gates, offline tolerance, renewal, device binding, and clean migration away from license servers.
Hybrid desktop-SaaS: Products with cloud accounts plus local runtime checks, where paid access must survive outside a browser session.
Technical tools: CAD, EDA, scientific computing, media tooling, build, compute, or engineering products where blocked access can stop production work.
Embedded and hardware-linked: Software tied to devices, appliances, field equipment, or local controllers that need explicit entitlement state.
Enterprise licensing: Vendors serving enterprise, regulatory, and regional customers with procurement, renewals, seat pools, support escalation, and strict change history.
Channel and reseller flows: Partner-led sales where issuance, upgrades, settlement, and customer access need a shared operational record.

Architecture / audit layer

Clavis uses signed records as the operational control plane. Hosted, private, or air-gapped deployments can keep the same audit evidence for lifecycle, payment, seat, usage, policy, and key events while customer payloads stay encrypted.

Shared source of truth

The vendor, customer, and application resolve entitlement from the same signed event history instead of comparing license files, exports, and vendor-held logs.

Vendor control plane: Vendor portal, Admin SDK, back office workflow, or payment event issues and mutates the entitlement record under the vendor signing key.
Application verification plane: The Client SDK fetches, verifies, decrypts, caches, and resolves access locally at startup, feature boundary, or seat checkout.
Deployment profile: Hosted, private, or air-gapped profiles can preserve the same signed evidence without changing entitlement logic.
Privacy boundary: Observers can see that records exist, but customer-scoped payloads and commercial terms stay encrypted to the customer key.

How it works

Entitlement record

Issue

Verify

Resolve access