§25 License Terms Architecture

v2.0.0 · Locked · L1 · March 19, 2026

The four-layer licensing model (§24.1) defines what is licensed at each layer. This section specifies how license terms are structurally represented, how the Constraint primitive operates at license boundaries, how license scope binds to instances, how federation licensing extends the recursive pattern across legal entities, and how the ecosystem grows through three distinct paths into the ProtoLex platform.

License terms are not ancillary legal text attached to an engineering system. They are governance objects — Constraint primitive instances in the governance graph, enforceable through the same invariant system that governs every other aspect of the substrate. The licensing agreement between ProtoLex Inc and a licensee is a Constraint primitive instance. License compliance is queryable. License lifecycle events are Decision primitives with full governance lineage. This structural representation is the architectural foundation of §25.

Purpose

License terms must be represented as first-class governance objects within the substrate, not as external legal documents. The Constraint primitive (§4) provides the mechanism for structural representation. License scope must bind precisely to instances, profile types, and actor counts. License constraints must cascade predictably through federation boundaries following the tighten-only rule. The ecosystem must grow through multiple independent entry paths, each preserving governance data portability and architectural integrity.

Foundation

The structural representation of license terms as Constraint primitives rests on three foundations:

1. Constraint primitive composability. The Constraint primitive (§4.1) is orthogonal to all other primitives. It applies to any target set of primitives. License constraints are Constraint instances with the four-layer licensing model as their scope and the substrate instance(s) as their target.

2. Behavioral invariant universality. B6 (Constraint binds primitives, §5) applies to license constraints identically to all other constraints. License scope limits are not special-cased — they are Constraint primitive instances subject to the same enforcement architecture and the same invariant guarantees as all other governance constraints.

3. Conservation law backing. License constraints preserve rule universality (§9). A substrate license with a five-instance limit enforces identically for every licensee. The conservation law prevents license enforcement from being selectively applied or contextually modified.

Governance

ProtoLex Inc is the authority for license term instantiation. ProtoLex Inc:

• Defines license terms per layer (protocol, substrate, tooling, application)
• Instantiates license agreements as Constraint primitives in each licensee's governance graph
• Maintains the source authority for license constraint instances
• Administers license lifecycle transitions (Proposed → Active → Modified → Suspended → Revoked → Expired)

The licensing agreement creation, modification, and termination each produce Decision primitives with full governance lineage. The Account context for each decision records the license relationship state, the authority that authorized the transition, and the effective date.

Substance

§25.1 License Terms by Layer

Each of the four layers (§24.1) carries distinct license terms. The terms specify permitted actions, required obligations, and excluded claims. No cascading intellectual property tracking exists between layers — each layer's license is self-contained.

§25.1.1 Protocol License Terms

The DLP specification is open. The protocol license grants unrestricted access to the governance grammar.

Permitted:

• Read, study, and analyze the DLP specification
• Implement the protocol from the open specification
• Reference, cite, and teach the protocol
• Extend the specification through conformant additions
• Publish independent implementations

Required:

• Attribution to ProtoLex Inc when publishing implementations or specifications built on the DLP protocol
• Citation of the specification version referenced

Not required:

• License agreement with ProtoLex Inc
• Payment of any kind
• Notification to ProtoLex Inc

Scope: The protocol license covers the nineteen primitive definitions and five-tier hierarchy (§4), ten behavioral invariants (§5), truth type system and claims graduation model (§6), minimum viable record specification (§7), control-theoretic foundation (§8), state transformation model and conservation laws (§9), Dimensional Business Index structure (§10), governance activation model (§12), and orchestration grammar specification (§A1, §A2).

Exclusions: The protocol license does not cover the ProtoLex substrate source code, profile content packages, tooling, or operational infrastructure. These are implementation and tooling layer assets.

Duration: Perpetual and irrevocable. The open protocol cannot be retroactively closed.

SDK Constraints:

• MUST: Any DLP implementation built from the open specification MUST include attribution to ProtoLex Inc in its documentation and specification references.
• MUST NOT: An implementation built solely from the open specification MUST NOT represent itself as ProtoLex Verified (§24.5) without separately acquiring a substrate license and passing conformance testing.
• DESIGN SPACE: The specific format and placement of attribution is an implementation choice. The architecture requires attribution; the presentation is not prescribed.

§25.1.2 Substrate License Terms

The substrate license grants access to the ProtoLex reference runtime. It is a commercial license with defined scope dimensions.

Permitted:

• Deploy and operate the ProtoLex substrate runtime within the licensed scope
• Configure profiles (EAS, BAS, PAS) within the licensed profile scope (§21)
• Extend substrate behavior within documented extension points
• Generate governance records, decision lineage, and evidence artifacts
• Participate in the ProtoLex Verified program (§24.5)
• Export governance data through the interchange layer (§19)

Required:

• Executed license agreement with ProtoLex Inc
• Payment per license terms
• License verification participation — UUID watermarking (§24.4.2) and certificate chain maintenance (§24.4.1) as conditions of the license
• Compliance with behavioral invariants (B1–B10, §5) — the invariants are both protocol requirements and license obligations
• ProtoLex Verified eligibility maintenance

Not required:

• Separate license for applications built on the substrate — application IP belongs to the builder (§24.2)
• Revenue sharing on customer-built applications
• Notification to ProtoLex Inc of application-layer development

Scope dimensions: Instance scope (number of active instances), profile scope (which profiles may be deployed), user scope (active Actor Contexts per §22), and verification obligation (§24.3.2).

Instance binding: Each substrate license is bound per instance. A new instance — whether created at Genesis, through spawning (§23.3), or through graduation (§24.7) — requires its own license allocation. Archived instances release their allocation. The instance lifecycle provides the accounting events for license scope management.

Duration: Annual or multi-year term as specified in the license agreement. Term expiration does not destroy governance data — the substrate continues to hold the governance record but ceases active operation until the license is renewed or data is exported through the interchange layer (§19).

SDK Constraints:

• MUST: Every substrate instance MUST operate within its licensed scope dimensions — instance count, profile scope, user scope, and verification obligation.
• MUST: License scope validation MUST occur at instance initialization and at configurable intervals during operation.
• MUST: Instance lifecycle events (creation, archival, graduation) MUST update license allocation accounting.
• MUST NOT: A substrate instance MUST NOT create new instances beyond the licensed instance count without license scope expansion.
• DESIGN SPACE: Specific license enforcement behavior when scope limits are approached (warning thresholds, grace periods, degraded-mode operation) is a commercial and implementation choice.

§25.1.3 Tooling License Terms

The tooling license operates on a subscription model. Active access requires an active subscription.

Permitted:

• Use licensed tooling products (Studio, Campus, SDK) within subscription scope
• Build applications using the SDK within documented extension points
• Extend SDK capabilities through published APIs
• Use Campus for practitioner education and onboarding

Required:

• Active subscription with ProtoLex Inc
• Compliance with terms of service
• Substrate license for production governance operations (tooling without substrate provides development and learning capability only)

Not required:

• Separate license for applications built with the tooling — application IP belongs to the builder
• Revenue sharing on tools or applications built using the SDK

Tier structure: Developer (SDK, CLI, local development substrate), Professional (above plus Studio, verification utilities), Enterprise (above plus Campus, multi-instance management, federation support). Each tier defines the operational surface available to the subscriber (§24.3.4).

Duration: Subscription term. Access ceases when the subscription lapses. Tooling subscriptions are independent of substrate license terms — a licensee can hold a multi-year substrate license with an annual tooling subscription, or vice versa.

SDK Constraints:

• MUST: Tooling access MUST validate active subscription status at application launch and at configurable intervals during operation.
• MUST: Tooling tier MUST govern available features — a Developer subscription MUST NOT expose Professional or Enterprise features.
• DESIGN SPACE: Specific subscription validation mechanism (online check, cached token, grace period for connectivity loss) is an implementation choice.

§25.1.4 Application Layer Terms

There is no application license from ProtoLex Inc. Application builders own their intellectual property entirely.

Ownership: The application builder owns all application-level IP — domain tools, methodology implementations, workflow configurations, client-specific adaptations, and any other artifacts built on the ProtoLex platform.

ProtoLex Inc claim: None. ProtoLex Inc has no intellectual property claim on application-layer output. The licensing relationship is with the platform, not with the output.

Builder licensing rights: Application builders may license their own applications to others under their own terms. A tool builder who creates an application on the ProtoLex platform can sell, license, or distribute that application independently. The only downstream requirement is that end users who run the application on a ProtoLex substrate must have their own substrate license — the application license from the builder does not include substrate access.

SDK Constraints:

• MUST NOT: The substrate MUST NOT impose licensing constraints on application-layer artifacts beyond the substrate and tooling license terms that govern platform access.
• MUST NOT: The substrate MUST NOT transmit application-layer IP metadata to ProtoLex Inc as part of license verification or compliance reporting.

§25.2 License-as-Constraint Architecture

The licensing agreement between ProtoLex Inc and a licensee is represented as a Constraint primitive instance (§4.1) in the governance graph. This is not a metaphor. The license terms are structurally instantiated as governance constraints that operate through the same enforcement machinery as all other constraints in the substrate.

§25.2.1 Structural Representation

A license agreement maps to a Constraint primitive with the following properties:

Table 25.2.1: License-as-Constraint Mapping

The Constraint primitive's enforcement modes (§4.1) apply directly to license terms:

Table 25.2.2: License Term Enforcement Modes

§25.2.2 Queryability

Because license terms are Constraint primitive instances, they are queryable through the dual-language query layer (§28). License constraints participate in the governance graph like any other constraint.

Graph traversal (Cypher via Apache AGE): Traverse from a substrate instance to its governing license constraints, from license constraints to their source authority (ProtoLex Inc), and from license constraints to their federation cascade targets. Graph traversal answers structural questions about the license topology: Which constraints govern this instance? What is the federation constraint chain from sub-practitioner to parent firm? Which instances share a common license constraint source?

Relational aggregation (SQL): Aggregate license scope utilization — active instance count versus licensed count, Actor Context count versus licensed count, profile deployment versus licensed profile scope. Relational queries answer operational questions about license utilization: What percentage of licensed instance capacity is consumed? How many Actor Contexts remain available? When does the license term expire?

Cross-instance queries: In federated deployments, license constraints are visible at the federation boundary. A parent firm's query can traverse to the federation licensing constraint that governs a practitioner's instance — the constraint itself is visible even when the practitioner's governance data is depth-gated (§23.4). This visibility distinction is precise: the parent sees the constraint (the terms the practitioner agreed to), not the constrained data (the practitioner's governance records).

Table 25.2.3: License Query Patterns

§25.2.3 License Lifecycle

Licenses have lifecycle states that map to the Constraint primitive's lifecycle. Every license lifecycle transition is a Decision primitive with full governance lineage.

Table 25.2.4: License Lifecycle States

Every state transition produces a Decision primitive that records the transition rationale, the authority that authorized it (ProtoLex Inc for licensor-initiated transitions, mutual for modifications), and the effective date. The Decision links to an Account providing the full context of the license relationship at the time of transition.

Revocation consequences: License revocation triggers certificate chain revocation (§24.4.1). All attestations from the revoked license stop validating. The substrate instance transitions to a read-only state — governance data is preserved and exportable through the interchange layer (§19) but no new governance operations are permitted. This provides meaningful enforcement without data destruction.

Expiration consequences: License expiration follows the same pattern as revocation but without the certificate revocation. The license can be renewed, restoring Active status. Expired licenses do not carry the compliance violation implications of revoked licenses.

§25.2.4 License Constraint and Behavioral Invariants

License constraints interact with the behavioral invariants (B1–B10, §5) through two mechanisms:

B6 enforcement. B6 — Constraint binds primitives — applies to license constraints. A license constraint that targets a substrate instance binds all primitive instances within that instance. License scope limits are not suggestions — they are governance constraints subject to the same enforcement architecture as any other Constraint primitive.

Conservation law backing. License constraints preserve rule universality (§9) — the same license terms produce the same enforcement regardless of licensee. A substrate license with a five-instance limit enforces identically for every licensee holding that license tier. The conservation law prevents license enforcement from being selectively applied.

§25.2.5 License Constraint Composition

License constraints compose with other constraints in the governance graph. A substrate instance is simultaneously governed by:

• Protocol-level constraints — the behavioral invariants (B1–B10, §5), which are universal and non-negotiable
• License constraints — the licensing agreement terms, which vary by license type and scope
• Profile-level constraints — the profile configuration (§21), which activates specific governance features
• Organizational constraints — the licensee's own governance policies, layered on top of protocol and license constraints
• Federation constraints — if federated, the federation licensing agreement terms from the parent firm

These constraint layers compose through the standard constraint resolution architecture. When constraints from different sources apply to the same primitive instance, the enforcement mode hierarchy resolves conflicts: Blocking takes precedence over Warning, which takes precedence over Logging, which takes precedence over Advisory. A license constraint that specifies Blocking cannot be downgraded by an organizational constraint. A protocol invariant that specifies Blocking cannot be downgraded by a license constraint.

Table 25.2.5: Constraint Layer Precedence

The precedence order ensures that higher-layer constraints cannot be circumvented by lower-layer configuration. An organization cannot configure its way out of a license limit. A license cannot override a protocol invariant. The constraint composition is monotonically tightening from protocol through organizational layers.

§25.3 License Scope and Instance Binding

§25.3.1 Per-Instance Licensing

Every active substrate instance consumes one license allocation. Instance binding is the mechanism through which the substrate license's instance scope dimension governs the deployment topology.

Table 25.3.1: Instance Lifecycle and License Allocation

Instance binding is non-transferable. A license allocation consumed by Instance A cannot be transferred to Instance B — Instance A must be archived (releasing the allocation) and Instance B must consume a new allocation. This prevents license accounting ambiguity.

§25.3.2 Graduation Creates New License

Profile graduation — PAS→BAS or BAS→EAS (§24.7) — is a topology change that creates a new instance. The new instance requires its own license allocation. Graduation does not transfer the source instance's license to the new instance.

PAS→BAS graduation: The PAS instance archives with a graduation reference. The PAS allocation is released. The new BAS instance consumes a new allocation. Net license impact: zero if PAS archives, plus one if PAS continues alongside BAS.

BAS→EAS graduation: The BAS instance may archive or continue (§24.7.5). The new EAS instance consumes a new allocation. If the licensee's substrate license does not include EAS profile scope, the graduation requires a license scope expansion before the EAS instance can deploy. The EAS content package (§21.2) — with its governance layer additions — is available only under EAS-scoped licenses.

§25.3.3 Profile Scope Licensing

The profile scope dimension of the substrate license governs which profile types (EAS, BAS, PAS) the licensee may deploy. Profile scope recognizes the structural difference between profiles — the governance feature depth, content package size, and accountability model complexity differ significantly between EAS, BAS, and PAS (§21).

Table 25.3.2: Profile Scope and License Implications

PAS instances are licensed as children of their parent instance. A PAS spawned by a licensed BAS or EAS does not require a separate profile scope authorization — the PAS profile is included in the parent's license scope. PAS instances do consume instance count allocations but do not require separate profile scope licensing.

EAS profile scope is an explicit license dimension because the governance layer content — eight governance domain intents, ~80 governance-specific evidence types, governance accounts, oversight and advisory authority types (§21.2) — represents significant ProtoLex intellectual property beyond the operational base. A licensee holding BAS-only profile scope cannot deploy EAS instances without a license scope expansion.

§25.3.4 Tighten-Only Cascade for License Constraints

License constraints participate in the tighten-only cascade (§23.2). When a licensed instance spawns child instances, the parent's license constraints cascade to children. Children may add constraints but cannot relax any constraint imposed by the parent's license.

This cascade operates identically whether the boundary is internal (parent EAS spawning child BAS) or external (federation boundary). The tighten-only rule is the architectural guarantee that license terms cannot be circumvented through instance topology — spawning a child instance does not create a governance space outside the license's constraint envelope.

Table 25.3.3: License Constraint Cascade Examples

The cascade is computable. Given any instance's position in the topology, its effective license constraint set is deterministically derived from the ancestor chain — the intersection of all ancestor license constraints plus its own.

§25.4 Federation License Architecture

§25.4.1 Federation as License Boundary

Federation is the recursive viable system pattern (§23.1) operating across legal entity boundaries. The licensing agreement is the Constraint primitive that spans the federation boundary, structurally identical to any other constraint in the governance graph but carrying the additional semantics of a legal relationship between separate entities.

The federation licensing agreement specifies:

Methodology constraints. The practitioner follows the licensed methodology. Methodology constraints cascade from the parent firm's EAS to the practitioner's EAS and onward to the practitioner's child instances. A practitioner's client engagement (BAS) inherits the methodology constraints the practitioner accepted from the parent firm.

Quality constraints. The practitioner meets the parent firm's quality standards. Quality constraints are verifiable through the conformance testing machinery (§24.5.2) — the same structural, behavioral, and compositional tests that verify ProtoLex Verified status also verify quality constraint compliance.

Reporting obligations. Aggregate metrics flow upward from practitioner to parent firm. Reporting constraints specify what metrics, at what frequency, and in what form. Depth-gating (§23.4) ensures that individual client engagement detail does not flow to the parent firm. Reporting obligations are Logging-mode constraints — they record without blocking.

Depth-gating rules. The parent firm sees aggregate performance across practitioners. The parent firm does not see individual engagement data from any practitioner. This constraint is enforced architecturally through the depth-gated visibility model (§23.4), not procedurally through access controls alone.

The federation licensing agreement is itself a composition of primitives, following the same delegation-as-composition pattern that governs internal spawning (§23.3):

Federation(parent firm → practitioner) =
    Intent     (purpose of the federation relationship)
  + Authority  (parent firm delegates methodology authority, scoped)
  + Constraint (federation licensing constraints — methodology, quality, reporting)
  + Commitment (mutual obligations — licensing fees, support, delivery)
  + Work       (scope of federated operations)
  + Account    (federation relationship context — terms, history, status)

This composition is a governed structure. The federation agreement's creation is a Decision with Account. The agreement's modification is a Decision with Account. The agreement's termination is a Decision with Account. Every lifecycle event in the federation relationship produces full governance lineage.

§25.4.2 Three Federation Tiers

The three federation licensing tiers (§24.6.1) represent progressively deeper constraint integration. Each tier adds constraint categories to the federation licensing agreement.

Table 25.4.1: Federation Tier Constraint Architecture

The enforcement mode column specifies how each constraint category operates at each tier. At the Methodology Only tier, the licensing constraint specifies methodology adherence as Blocking (the practitioner cannot deviate from the licensed methodology) while other categories are either not applicable or advisory. At Full Federation, most categories operate as Blocking — the deepest constraint integration reflects the deepest operational coupling.

§25.4.3 Federation License Independence

Federation licensing does not create a dependency between the parent firm's license and the practitioner's license. Each entity holds an independent license relationship with ProtoLex Inc.

Table 25.4.2: Federation License Independence

The independence model prevents cascading license failures. A parent firm's license issue does not invalidate practitioner licenses. Each entity's license stands on its own credentials. The federation agreement is a separate Constraint primitive that terminates independently of either party's license relationship with ProtoLex Inc.

§25.4.4 Recursive Federation

Federation licensing mirrors the recursive viable system pattern (§23.1). A parent firm can federate with a practitioner who federates with a sub-practitioner. Each federation boundary is a licensing agreement operating as a Constraint primitive. Each boundary follows the tighten-only rule.

Parent Firm (EAS) ──license constraint──→ Practitioner A (EAS) ──license constraint──→ Sub-Practitioner (EAS)

The sub-practitioner's effective license constraint set is the intersection of:

• ProtoLex Inc's substrate license terms (base)
• Parent firm's federation licensing constraints (tightened)
• Practitioner A's federation licensing constraints (tightened further)
• Sub-practitioner's own constraints (tightest)

No federation level can relax any constraint imposed at a higher level. The protocol does not impose a maximum federation depth — depth emerges from organizational viability, following the same principle as internal recursion (§23.1).

§25.4.5 Federation Verification at License Boundary

Federation verification extends the ProtoLex Verified model (§24.5) to federated entities. Each entity in the federation chain independently maintains its own ProtoLex Verified status. The federation boundary adds a verification layer: the parent firm can verify that its practitioners maintain their verification status without accessing practitioner governance data.

Parent firm verification. The parent firm holds a substrate license and ProtoLex Verified status for its own instance. The parent firm's verification does not transfer to practitioners — each practitioner achieves verification independently through the same conformance testing workflow (§24.5.3).

Practitioner verification. Each practitioner holds their own substrate license and independently achieves ProtoLex Verified status. The practitioner's verification is independent of the parent firm's status — if the parent firm loses verification, the practitioner's verification stands.

Federation-level attestation. The parent firm can verify practitioner verification status through two mechanisms: querying the ProtoLex registry (if practitioners have opted to publish their attestations) or requesting practitioners to share compliance certificates. The depth-gating constraint applies — the parent firm verifies practitioner verification status, not practitioner governance data. The federation licensing tier determines the reporting obligation: at Methodology Only, compliance attestation is sufficient; at Full Federation, practitioners must maintain ProtoLex Verified status as a Blocking constraint (Table 25.4.1).

Table 25.4.3: Federation Verification Boundaries

§25.5 Ecosystem Growth Model

§25.5.1 Three Entry Paths

Three paths lead into the ProtoLex ecosystem. Each path has distinct license requirements, distinct ProtoLex Verified eligibility, and distinct value propositions.

Table 25.5.1: Ecosystem Entry Paths

§25.5.2 Path Independence

The three paths are independent. An organization that builds from the open specification can later acquire a substrate license without discarding their existing implementation — the substrate license unlocks ProtoLex Verified status by providing the license dimension. An organization that deploys the reference runtime without tooling can add a tooling subscription independently. Each path can lead to the others without architectural barriers.

Table 25.5.2: Path Transition Matrix

§25.5.3 Ecosystem Incentive Structure

The ecosystem growth model creates natural incentives at each path:

Open specification path. The open protocol encourages academic study, independent implementation, and interoperability research (§24.3). Independent implementations that pass conformance tests demonstrate the specification's completeness and grow the DLP ecosystem. ProtoLex Inc benefits from ecosystem growth even without a licensing relationship — more implementations means broader adoption of the governance grammar.

Reference runtime path. The substrate license provides the reference implementation with pre-built governance content, operational machinery, and the ProtoLex Verified designation. Organizations that need production governance capability — not just protocol understanding — acquire the substrate license. The value proposition is the engineering investment embodied in the runtime, not the protocol specification.

Tooling path. The tooling subscription provides the operational surface for day-to-day governance. Studio provides the governance interface. Campus provides education. The SDK provides the development surface. Organizations that operate at scale need the tooling layer — it is the efficiency multiplier that makes governance operations practical rather than merely possible.

The incentive structure is not coercive. Each path is independently valuable. The open specification is complete enough to build from. The reference runtime is usable without tooling. The tooling is useful at any scale. The three paths create a natural progression — organizations enter at the path appropriate to their needs and add layers as their governance requirements grow.

§25.5.4 Cross-Implementation Interoperability

The open protocol specification enables interoperability between ProtoLex substrate instances and independent DLP implementations. The interchange layer (§19) provides the data portability surface. Governance data produced by any conformant implementation — whether ProtoLex-licensed or independently built — is structurally compatible at the protocol level because all conformant implementations share the same nineteen primitives, the same ten behavioral invariants (B1–B10), and the same state transformation model.

Table 25.5.3: Interoperability by Implementation Type

Interoperability does not require license alignment. A ProtoLex Verified instance can exchange governance data with an independent implementation through the interchange layer. The attestation metadata (§24-C4) embedded in ProtoLex Verified exports provides provenance information that independent implementations can use for trust evaluation — but the attestation is informational, not a prerequisite for data exchange.

§25.5.5 Ecosystem Growth Dynamics

The three-path model creates a flywheel effect. Open specification adoption drives awareness. Awareness drives substrate licensing for organizations that need production capability. Substrate licensing drives tooling subscriptions for organizations that need operational efficiency. Each layer of adoption reinforces the others.

The ecosystem also grows through federation. When a parent firm federates with practitioners, each practitioner acquires their own substrate license — expanding the licensing base without ProtoLex Inc direct sales. Federation is a distribution channel built into the license architecture.

Independent implementations grow the ecosystem by demonstrating the specification's completeness. An independent implementation that passes conformance tests is evidence that the DLP specification is implementable from the open documentation alone — a claim that strengthens the protocol's credibility and encourages further adoption.

§25.6 License Compliance Architecture

§25.6.1 Compliance as Governance Operation

License compliance is not a separate system layered on top of the substrate. It is a governance operation within the substrate — license constraints are Constraint primitives, compliance verification produces Evidence, compliance decisions are Decision primitives with Account context.

The compliance architecture has three components: conformance testing (architectural soundness), invariant compliance (behavioral correctness), and license scope verification (commercial terms).

§25.6.2 Conformance Testing

Conformance testing verifies that an implementation correctly realizes the DLP architecture. The conformance test suite operates across three levels (§24.5.2):

Table 25.6.1: Conformance Test Levels and License Relevance

All three levels must pass for the Conformant dimension of ProtoLex Verified (§24.5). Conformance testing is both a verification mechanism and a license obligation — the substrate license requires participation in the verification program.

§25.6.3 Self-Service Verification

Verification is self-service by design (§24.4.4). Licensees verify their own compliance without transmitting governance data to ProtoLex Inc. The verification tool operates locally. The UUID corpus, governance data, and verification results remain in the licensee's environment.

Table 25.6.2: Verification Access Tiers

Self-service verification produces a compliance certificate — a signed attestation containing both license validation and conformance test results. The compliance certificate is the attestation artifact. Licensees provide compliance certificates to auditors, regulators, and federation partners. The certificate carries its own provenance — verifiable against the ProtoLex public key without access to the licensee's substrate data.

§25.6.4 SHACL Shape Validation for License Constraints

License constraints, like all constraints in the substrate, are implemented as SHACL shapes in the dedicated shapes graph (§5.3). The shapes graph separation — class ontology under Open World Assumption, shapes graph under Closed World Assumption — applies to license constraint shapes.

License constraint shapes validate:

• Instance count within licensed scope
• Actor Context count within licensed scope
• Profile deployment within licensed profile scope
• Certificate chain validity
• Verification program participation

License constraint shapes produce SHACL Validation Reports when violations occur. These reports are persisted as Evidence records with truth type Authoritative — the validation engine is a trusted system component. The same violation handling architecture (§5.5) applies: Blocking violations prevent the operation, Warning violations alert, Logging violations record silently.

§25.6.5 License Scope Verification

License scope verification is the commercial compliance component — it verifies that a licensee's deployment operates within the contracted scope dimensions (instance count, profile scope, user scope, verification obligation).

Table 25.6.3: License Scope Verification Points

License scope verification operates locally. The substrate tracks its own scope dimensions against the license terms instantiated as Constraint primitives. No external call to ProtoLex Inc is required for scope verification — the license terms are self-contained within the governance graph.

§25.6.6 Compliance Lifecycle Integration

License compliance integrates with the substrate's operational lifecycle. Compliance is not a separate audit activity — it is embedded in the governance machinery.

At Genesis (§18.2). License credentials are validated. Certificate chain is established. UUID watermarking is activated. License constraints are instantiated as Constraint primitives in the governance graph. The instance begins its operational life within a fully verified license context.

During operation. License scope dimensions are continuously validated. Instance count, Actor Context count, and profile scope are checked at configurable intervals. Constraint violations produce Evidence records. Warning-mode violations generate alerts. The substrate's operational governance and its license governance share the same enforcement pipeline.

At interchange (§19). Every export through the interchange layer includes attestation metadata from the certificate chain (§24-C4). The export is the moment when license provenance becomes externally visible — the attestation embedded in the export allows recipients to verify the source's license status.

At graduation (§24.7). Graduation triggers license scope verification — the new instance requires allocation, the target profile must be within licensed scope, and the graduation decision itself is a governed event with full lineage. Evidence carry-forward preserves watermark integrity (§24-C8).

At renewal or expiration. License term expiration triggers a license lifecycle transition (§25.2.3). The substrate transitions to read-only state if not renewed. Governance data is preserved. The compliance record — all verification Evidence, all license lifecycle Decisions — persists for audit purposes regardless of license status.

Boundaries

The license terms architecture constrains the following:

• Constraint representation. All license terms must be represented as Constraint primitive instances in the governance graph. No license terms may exist as external legal text outside the governance model.
• Scope binding. Instance binding is non-transferable. Each active instance must consume exactly one license allocation. Allocations cannot be transferred between instances.
• Cascade rule. License constraints must cascade through federation boundaries and spawning relationships following the tighten-only rule. No child instance may relax any parent constraint.
• Enforcement universality. The same license constraint must enforce identically for all licensees holding that constraint. Conservation law forbids selective application.
• Data preservation. License revocation or expiration must not destroy governance data. The substrate transitions to read-only state but preserves all records for export and audit.

Positions

The following positions are locked decisions:

1. License-as-Constraint is structural, not metaphorical. License terms are Constraint primitive instances in the governance graph, enforceable through the same mechanisms as all other governance constraints.

2. Instance binding is non-transferable. Each active instance consumes exactly one license allocation. Allocations cannot be reallocated between instances.

3. Tighten-only cascade is mandatory. License constraints cascade to all descendant instances following the tighten-only rule. No exception for federation boundaries.

4. Three ecosystem paths are permanent. The open specification path, reference runtime path, and tooling path must remain independent and non-coercive. Organizations must be able to enter and transition freely.

5. Compliance is integrated, not layered. License compliance is a governance operation embedded in the substrate lifecycle, not a separate audit system.

Lineage

§25 History:

• v2.0.0 (2026-03-19). Initial fspec conversion. All substance preserved with full fidelity. Locked status — no pending modifications.

Commitments

SDK MUST commitments for §25:

• §25-C1: MUST represent licensing agreement as Constraint primitive instance in governance graph.
• §25-C2: MUST enforce license scope dimensions through Constraint enforcement modes.
• §25-C3: MUST record every license lifecycle transition as Decision primitive with full lineage.
• §25-C4: MUST enforce tighten-only cascade for license constraints across instance boundaries.
• §25-C5: MUST require new license allocation for every new instance.
• §25-C6: MUST enforce application-layer IP independence.
• §25-C7: MUST represent federation licensing agreements as Constraint primitives.
• §25-C8: MUST maintain federation license independence.
• §25-C9: MUST support all three ecosystem entry paths without architectural barriers.
• §25-C10: MUST NOT allow license constraints to be circumvented through instance topology.
• §25-C11: MUST NOT impose cascading IP tracking between license layers.
• §25-C12: MUST NOT destroy governance data on license revocation or expiration.

Coverage

§25 completeness assessment:

• License terms by layer: All four layers (protocol, substrate, tooling, application) completely specified with permitted actions, required obligations, and exclusions.
• License-as-Constraint architecture: Structural representation, queryability, and lifecycle completely specified.
• Scope binding: Per-instance licensing, graduation requirements, profile scope, and tighten-only cascade completely specified.
• Federation architecture: All three federation tiers, tier constraint detail, license independence, recursive federation, and verification boundaries completely specified.
• Ecosystem growth: Three entry paths, path independence, path transitions, incentive structure, interoperability, and growth dynamics completely specified.
• Compliance architecture: Conformance testing, self-service verification, SHACL validation, license scope verification, and lifecycle integration completely specified.

All 19 organizational domain primitives are addressed:

• Intent (Purpose): Why structural license representation is necessary
• Evidence (Foundation): Constraint composability and invariant universality backing
• Authority (Governance): ProtoLex Inc as licensing authority
• Work (Substance): Complete license terms, constraint representation, scope binding, federation, ecosystem growth, and compliance
• Constraint (Boundaries): Scope limits and representation requirements
• Decision (Positions): Locked design decisions on license structure
• Account (Lineage): Version history
• Commitment (Commitments): SDK MUSTs for license implementation
• Capacity (Coverage): Completeness assessment

Addressing

Reference scheme: §25[subsection].[topic]

Key references:

• §25.1: License terms by layer
• §25.2: License-as-Constraint architecture
• §25.3: License scope and instance binding
• §25.4: Federation license architecture
• §25.5: Ecosystem growth model
• §25.6: License compliance architecture

Attribution

Authority: cam (ProtoLex Inc Governance Authority) Domain: organizational Specification Status: v2.0.0, Locked, March 19, 2026 Patent Reference: Provisional #63/963,072

Situational Frame

§25 operates within the license architecture context established by §24. It specifies how license terms transform from legal contracts into first-class governance objects represented as Constraint primitive instances. It establishes how scope binding operates at the instance level, how constraints cascade through federation boundaries, how the ecosystem grows through multiple independent entry paths, and how license compliance integrates with the substrate's operational lifecycle.

Scope Governance

The scope of §25 is: structural representation of license terms, instance binding and scope dimensions, federation licensing architecture, ecosystem entry and growth patterns, and compliance verification mechanisms.

The scope excludes: commercial terms specific to individual licenses, pricing models and revenue optimization, detailed legal contract language, operational procedures for license administration, and detailed implementation patterns for specific license types (those are SDK constraints).

Framing

§25 frames license terms as integral governance structures, not ancillary legal documents. The Constraint primitive provides the representation mechanism. Scope binding operates at the instance level with non-transferable allocations. Federation licensing extends the recursive viable system pattern across legal entity boundaries. Ecosystem growth follows a three-path model that remains non-coercive and path-independent.

This framing enables:

• Composability: License constraints layer with protocol constraints, profile constraints, organizational constraints, and federation constraints.
• Auditability: Every license decision produces a governance record with full lineage.
• Portability: Governance data remains portable across license transitions and implementation changes.

Adaptation

Potential extension points:

• Federation tier definitions could expand as practitioner ecosystems mature and new operational patterns emerge.
• License constraint categories could add new dimensions (e.g., data residency, regulatory compliance) without breaking tighten-only semantics.
• Ecosystem paths could develop intermediate steps between the three primary paths.
• Compliance reporting obligations could become more granular as federated operations scale.

Known constraints on adaptation:

• Instance binding non-transferability is permanent.
• Tighten-only cascade cannot be relaxed at any boundary.
• Application-layer IP protection cannot be compromised.
• All three ecosystem paths must remain independently viable.

Readiness

Operational status: Specification ready for implementation.

Implementation requirements for production:

1. License-as-Constraint instantiation in governance graph with full Constraint primitive support
2. SHACL shape definitions for license scope dimensions (instance count, profile scope, user scope, verification)
3. License lifecycle state machine with Decision primitive recording
4. Tighten-only cascade computation for effective constraint derivation at any instance
5. Federation constraint instantiation and reporting obligation tracking
6. Compliance verification integration with conformance testing and scope validation

Meaning Resolution

Key term definitions:

• License-as-Constraint: Architectural principle that licensing agreements are represented as Constraint primitive instances in the governance graph, enforceable through the same mechanisms as all other constraints.
• Instance binding: Non-transferable assignment of a license allocation to a specific substrate instance; each active instance consumes exactly one allocation.
• Tighten-only cascade: Rule that license constraints propagate from parent to child instances, with children able only to add or tighten constraints, never to relax them.
• Ecosystem entry path: One of three independent routes into ProtoLex: build from open specification, deploy reference runtime, or build with tooling.
• Federation license boundary: Legal entity boundary where a federation licensing agreement (represented as Constraint primitive) governs the relationship between parent firm and practitioner.
• Profile scope: License dimension governing which profile types (EAS, BAS, PAS) the licensee may deploy; EAS profile scope requires explicit licensing due to governance layer content.

Perception Surface

External interfaces for §25 operations:

1. License constraint queries (§25.2.2): Licensees can traverse from instances to their governing license constraints through Cypher graph queries.
2. Scope utilization reporting (§25.2.2): Licensees can aggregate license scope consumption through SQL queries.
3. Federation constraint visibility (§25.2.2): Parent firms can traverse federation constraint chains without accessing practitioner governance data.
4. License lifecycle evidence (§25.2.3): Every license state transition produces an Evidence record queryable through the dual-language layer.
5. Compliance reporting (§25.6): License compliance status projects through Domain 3 (Evidence, Record & Truth) of the Policy Projection Surfaces (§13).

Temporal Governance

License lifecycle timing (§25.2.3):

• Proposed state: License terms under negotiation, constraint not yet active
• Active state: License in force, all enforcement modes operational, per license term (annual or multi-year)
• Modified state: Terms changed, constraint updated with lineage preserved
• Suspended state: Temporary non-operational (payment lapse, compliance investigation)
• Revoked state: Terminated for cause, substrate transitions to read-only
• Expired state: Term completed, substrate read-only unless renewed

Scope verification timing (§25.6.5):

• Instance count verified at instance creation and at configurable intervals
• Profile scope verified at Genesis and at profile graduation
• User scope (Actor Context count) verified at context creation and at configurable intervals
• Verification obligation checked at initialization, at configurable intervals, before interchange exports

Cross-References

See §24 for four-layer licensing model, entity structure, license types, verification architecture, ProtoLex Verified designation, federation licensing, and profile graduation. See §25-C1 through §25-C17 for complete SDK constraints governing §25 implementation.

Related sections:

• §4: Constraint primitive definition (license terms operate through Constraint §4.1)
• §5: Behavioral invariants and SHACL shapes (all nine invariants apply; license constraints use shapes graph)
• §23: Portfolio patterns (spawning, graduation, federation relationships that trigger licensing events)
• §28: Dual-language query layer (license constraints queryable through Cypher and SQL)

Terminology

See §25.7 in source for complete terminology definitions.

SDK Constraints

See §25.8 in source for complete SDK constraints (§25-C1 through §25-C17).

End of §25 License Terms Architecture (fspec format v2.0.0)