SCHEDULE B — TECHNICAL REQUIREMENTS

To the ENCY Extension Store Publishing Policy Version 1.0 — Effective 1 November 2026

B.1 Status

This Schedule forms part of the Publishing Policy and is incorporated into the Developer Agreement. Compliance with it is a condition of publication and of continued availability on the Store.

Where this Schedule imposes a requirement on a Gated Extension, that requirement is a contractual obligation and not a recommendation. Failure to meet it is a breach of clause 5.3 of the Developer Agreement.

B.2 Supported platform versions

An Extension must declare the minimum and maximum Platform versions it supports. An Extension that does not run on any currently supported Platform release may be removed under Policy Section 6 after notice.

B.3 Packaging and signing

B.3.1 Package format

Extensions are submitted as a single signed package containing:

B.3.2 Manifest

The manifest must declare, as a minimum:

{
  "id": "com.example.extension",
  "version": "2.3.0",
  "displayName": "...",
  "publisher": "...",
  "platformMin": "2026.1",
  "platformMax": "2027.2",
  "reservedDomain": "A-01c",
  "requiredEntitlement": "ENCY_5AXIS_MILL",
  "permissions": ["filesystem.read", "network.outbound"],
  "dataProcessing": { "personalData": false }
}

reservedDomain and requiredEntitlement must match the declaration made at submission (Policy Section 5). A mismatch between manifest and declaration is treated as inaccurate information for the purposes of Policy paragraph 4.6 and clause 6.3(e).

Where an Extension operates in no Reserved Functionality Domain, reservedDomain must be null and requiredEntitlement must be omitted.

B.3.3 Code signing

All packages are signed by ENCY at publication. The Developer must not distribute a package bearing an ENCY signature other than through the Store.

The Platform loads only components that are ENCY-signed and registered against a published Extension. Attempting to load, side-load or inject an unsigned or unregistered component into the Platform is a breach of clause 5.2 of the Developer Agreement and of Policy paragraph 4.9.

B.4 Entitlement verification — Gated Extensions

This section is the technical expression of Policy paragraphs 4.2 and 4.3. It applies to every Extension declared as operating within a Reserved Functionality Domain.

B.4.1 The obligation

A Gated Extension must verify, through the ENCY entitlement-verification API, that the end user holds a valid Entitlement to the Separately Licensed Module identified in Schedule A for its Domain, and must not perform, enable or produce the gated capability where that verification does not succeed.

B.4.2 Per-tier verification

Verification must be performed against the specific Entitlement identifier for the tier at which the capability is licensed, as set out in Schedule A.

An Extension must not:

(a) treat an Entitlement for a lower tier as satisfying the requirement for a higher tier;

(b) query a generic or family-level entitlement where a tier-specific identifier exists;

(c) infer entitlement from the presence of any other licence, module, file, registry value or configuration;

(d) provide any configuration option, licence key, command-line switch, build variant or documented procedure by which the verification can be bypassed, relaxed or redirected.

Worked example. An Extension in Domain A-01c queries ENCY_5AXIS_MILL. It must not query ENCY_MILL, must not accept ENCY_MILL_3PLUS2 as equivalent, and must not proceed on the basis that the user holds some milling licence.

B.4.3 When verification must occur

Verification at installation alone does not satisfy this Schedule.

B.4.4 Caching and validity

Caching beyond the permitted period is expressly named in clause 5.3 of the Developer Agreement as a breach.

B.4.5 Revocation and lapse

Where an Entitlement is revoked, lapses, expires or is not renewed, the Extension must cease to make the gated capability available no later than the expiry of the current cache period.

An Extension must not continue to operate on the basis of an Entitlement held at the time of installation.

B.4.6 Offline operation

The SDK provides entitlement claims within the signed local licence artefact, so that verification succeeds without network connectivity for the duration of the cache period.

The Extension must use that mechanism. It must not implement its own offline fallback, must not extend the validity of a claim, and must not proceed on the basis that connectivity is unavailable.

B.4.7 Integrity

The Extension must not attempt to read, modify, emulate, intercept, replay or substitute any part of the licensing, activation, entitlement or anti-tamper subsystems, whether directly or through a third-party component.

B.4.8 Failure handling

Where verification does not succeed, the Extension must:

(a) not perform the gated capability;

(b) present a clear message identifying the licence required;

(c) not present the failure as a defect in the Platform;

(d) continue to make available any non-gated functionality it provides.

B.5 Output integrity

B.5.1 Validation pipeline

An Extension that generates machine-control output must submit that output to the Platform's validation, simulation and collision-checking pipeline where the Platform provides validation for the operation concerned. It must not write, export or transmit machine-control output that has bypassed that pipeline.

B.5.2 No independent safety determination

An Extension must not present its own output as verified, safe to run, or collision-free, other than by reference to the result returned by the Platform's validation pipeline.

B.6 Security

Vulnerabilities must be reported to [email protected] within 72 hours of discovery (Developer Agreement clause 5.8).

B.7 Permissions

An Extension declares the permissions it requires in its manifest. Permissions are granted on the principle of least privilege; a declaration materially wider than the Extension's function is grounds for refusal.

B.8 Quality and performance

B.9 Localisation and accessibility

Extensions must supply, at minimum, English-language user-facing text. Additional languages are encouraged. Text must be externalised, not hard-coded, so that it can be localised.

B.10 Submission and review

The capability audit verifies what an Extension emits, not what its listing or manifest claims. An Extension declared in a lower tier that produces higher-tier output is refused under Policy paragraph 4.5 and, where the declaration was made knowingly, under clause 6.3(e).

B.11 Updates

Every update is a new submission and is reviewed accordingly, including a fresh declaration under Policy Section 5.

An update must not:

(a) alter the Reserved Functionality Domain or required Entitlement without a new declaration and review;

(b) introduce capability that would have required a different tier at first publication;

(c) remove or weaken entitlement verification.

Security updates may be expedited on request.

B.12 Amendment

This Schedule may be amended on not less than 15 days' notice. Where an amendment requires a change to a published Extension, a reasonable transition period of not less than 90 days is given before the requirement applies to Extensions already published.

Version history

ENCY SOFTWARE LTD 9 Aiolou and Panagioti Diomidous, Katholiki, 3020 Limassol, Cyprus Registration No. HE 460544 · VAT No. CY 60079628L [email protected] · +357 95 907793