SCHEDULE B — TECHNICAL REQUIREMENTS

To the ENCY Extension Store Publishing Policy Version 1.1 — 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",
  "reservedDomains": [
    {
      "domain": "A-03",
      "entitlement": "ENCY_TURN",
      "capabilities": ["turning.strategies"]
    },
    {
      "domain": "A-01c",
      "entitlement": "ENCY_5AXIS_MILL",
      "capabilities": ["milling.5axis.strategies"]
    }
  ],
  "permissions": ["filesystem.read", "network.outbound"],
  "dataProcessing": { "personalData": false }
}

reservedDomains lists every Reserved Functionality Domain in which the Extension operates. For each entry:

• domain must be a Domain declared at submission (Policy paragraph 5.1A);
• entitlement must be the Entitlement identifier that Schedule A assigns to that Domain;
• capabilities lists the identifiers of the capabilities of the Extension that fall within that Domain, each of which is gated on that entitlement (B.4). Every capability within a Reserved Functionality Domain must appear in exactly one entry.

A mismatch between the manifest, the declaration and Schedule A is treated as inaccurate information for the purposes of Policy paragraphs 4.6 and 6.3(e). Where the Extension operates in no Reserved Functionality Domain, reservedDomains must be an empty list.

The entitlement identifiers shown above are illustrative; the identifiers in force are published in the Developer Portal.

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.

An Extension must not download, install, load or execute code, components or other Extensions from any source other than its own signed package, and must not update itself other than through the Store update mechanism. An Extension may download data (such as tool libraries, material data or configuration) where that data is not executed as code; the endpoints concerned must be declared in the manifest (B.6).

Providing any means of installing unsigned or unregistered components into the Platform, or of disabling signature verification, is a breach of Policy paragraphs 3(j) and 4.10 and ground for immediate action under Policy paragraph 6.3(f).

Development mode. The SDK provides a development mode for loading the Developer's own unpublished components during development and testing. Development mode is available only to registered Developers, is limited to the Developer's own machines as set out in the SDK documentation, and must not be used, enabled or documented as a means of distributing components to end users.

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 the Domain of each gated capability, and must not perform, enable or produce a gated capability where the verification for its Domain does not succeed.

Verification is per capability. Where an Extension operates in more than one Domain, a successful verification for one Domain does not make available any capability within another. The Extension must not combine verifications, or treat the Entitlement for any Domain as satisfying the requirement for another.

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.

Where an amendment to Schedule A brings a capability of a published Extension within a Reserved Functionality Domain (Policy paragraph 4.7, Affected Extensions), ENCY applies the Entitlement condition to new installations in the Store from the effective date. Installations made before that date are recorded as such and continue to operate without the Entitlement, in the version installed and its corrective updates.

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.4.9 Changes to Entitlement identifiers

ENCY's licensing changes over time. The following apply so that a change does not break published Extensions:

A previous identifier is accepted for not less than 12 months after the change and, in any event, until the end of the support period for the SDK version in which it was current (B.2). ENCY publishes each change, with the identifiers concerned, in the Developer Portal and notifies affected Developers.

An Extension must use the identifier that Schedule A assigns to its Domain in each new version it publishes after the change.

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) add, remove or change a Reserved Functionality Domain, or move a capability between Domains, 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