Runtime-enforced licensing

If your licensing lives in a configuration file, the customer can edit it. If it lives in a license server, the customer can disable network access. If it lives in the runtime binary itself, the customer has to patch the binary — and you've built an adversarial relationship.

Opscotch's runtime makes the third option the default. Your commercial envelope is part of the package, enforced by the runtime, and verifiable by the customer.

How enforcement works

When the runtime loads a workflow artifact, it checks the embedded commercial envelope against the entitlement token the deployment is configured with. If the envelope requires an entitlement the token doesn't have, the workflow doesn't run.

Three levels of enforcement

• Plan tier — only customers on the right plan can run the workflow. Useful for free / pro / enterprise separation.
• Quota — limits on executions, time, calls, or whatever unit you care about. Enforced in the runtime, not in your dashboard.
• Per-feature — individual features of a workflow can require specific entitlements, useful for add-ons and a la carte pricing.

What customers see

Customers see their entitlement token — typically a signed JSON file in their deployment config. They can verify what the token grants using our CLI. The runtime's verification happens transparently: workflows run if they're entitled, refuse to run if they're not, with a clear error message in either case.

What you control

You control which features are gated, what quotas apply, and what plan tiers exist. The runtime enforces whatever you configure. There's no way for a customer to add a feature by editing config — they need a new signed package from you.

Audit trail

Every entitlement check is logged in the runtime's structured event stream. Customers can audit their own usage. You can audit your own enforcement. Support tickets get faster because both sides have the same data.

The result

your commercial model holds even in adversarial environments.