§24 Entity & Licensing Structure

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

The ProtoLex ecosystem operates across four layers — protocol, implementation, tooling, and applications — each with distinct ownership, access rights, and licensing requirements. Three entities anchor the ecosystem: ProtoLex Inc (protocol and platform owner), Gryt Labs (education and adoption), and DC Smith Advisory (first application customer). A dual-dimension verification system — ProtoLex Verified — combines license validity with architectural conformance to establish ecosystem authenticity.

This section specifies the four-layer licensing model, entity structure, license types, verification architecture, the ProtoLex Verified designation, federation licensing, and profile graduation licensing. §21 defines substrate profiles. §22 defines actors and their governance identity. §23 defines portfolio patterns and federation mechanics. §24 defines how the ecosystem's intellectual property, licensing, and verification architecture govern access to the platform.

Purpose

The licensing architecture bridges the separation of protocol ownership from implementation ownership from application ownership. It establishes how three distinct legal entities — ProtoLex Inc (platform owner), Gryt Labs (education), and DC Smith Advisory (first customer) — coexist in the same ecosystem. It specifies the four layers of licensing, the scope dimensions that govern each layer, the verification mechanisms that attest to both license validity and architectural conformance, the federation licensing model that extends the architecture across legal entity boundaries, and the profile graduation model that permits instances to evolve within the licensing framework.

Foundation

The licensing architecture rests on three foundations:

1. Protocol-implementation separation. The protocol layer — the specification of the nineteen primitives, ten behavioral invariants, truth type system, and state transformation model — is open. The implementation layer — the engineered substrate runtime that makes the protocol operational — is licensed. This separation enables protocol adoption to drive ecosystem growth while funding continued development through implementation licensing.

2. Architectural conformance verification. The Constraint primitive (§4) operates not only within individual instances but across legal entity and instance boundaries. License terms are not legal text attached to engineering; they are Constraint primitive instances in the governance graph, enforceable through the same invariant system that governs all other substrate operations.

3. Recursive viable system pattern. Federation licensing (§24.6, §25.4) mirrors the recursive viable system pattern (§23.1). Just as internal recursion enables organizations to structure themselves at multiple scales, federation licensing enables organizations to partner and operate at multiple levels while preserving the same governance guarantees at every scale.

Governance

ProtoLex Inc is the governance authority for the licensing architecture. ProtoLex Inc:

• Owns the DLP specification (open)
• Maintains the substrate reference runtime (licensed)
• Operates the license verification infrastructure (§24.4)
• Maintains the root certificate authority for the license certificate chain
• Administers the ProtoLex Verified program (§24.5)

ProtoLex Inc's governance authority is constrained by the open protocol commitment: the DLP specification cannot be retroactively closed, and the four-layer model cannot be collapsed. The protocol layer remains open indefinitely.

Substance

§24.1 Four-Layer Licensing Model

The ProtoLex ecosystem is organized into four layers. Each layer has distinct ownership, access rights, and enforcement characteristics. The four-layer model replaces any prior framing that tracked intellectual property through cascading relationships between licensees.

Table 24.1.1: Four-Layer Model

Layer Independence

The four layers are architecturally independent. Each layer can exist without the layers above it, and each layer's licensing is self-contained.

Protocol layer is the specification. It is open. Anyone can read the DLP specification, understand the primitive model, study the behavioral invariants, and build their own implementation from the open specification. No license is required to read, study, or implement the protocol from scratch.

Implementation layer is the reference runtime. Using the ProtoLex substrate code requires a commercial license. The implementation embodies engineering decisions, optimizations, and operational machinery that go beyond the protocol specification. The protocol says what invariants must hold; the implementation is one way — the ProtoLex way — of making them hold.

Tooling layer is the development and operational environment. ProtoLex Studio (configuration and governance interface), ProtoLex Campus (education and onboarding), the SDK (developer integration surface), and supporting utilities are licensed separately from the substrate runtime. Tooling access operates on a subscription model — ongoing access requires an active subscription.

Application layer is what customers build. ProtoLex Inc does not claim intellectual property over applications built on the platform. A customer who builds a domain-specific tool, configures a governance workflow, or creates a methodology implementation on the ProtoLex substrate owns that work. The licensing relationship is with the platform, not with the output.

Enforcement Model

Enforcement is standard software licensing. The enforcement question is: "Are you using our code without paying?" There is no cascading IP tracking, no derivative-work chain analysis, and no multi-degree ownership claims.

The boundary between protocol (open) and implementation (licensed) is the boundary between specification and code. The specification defines the governance grammar — the primitives, their composition rules, the invariants, and the state transformation model. The implementation is the engineered system that makes the grammar operational. This boundary is testable: could someone implement the protocol knowing only the specification? If yes, the knowledge is protocol-level and open. If the knowledge requires access to ProtoLex source code, it is implementation-level and licensed.

Table 24.1.2: Protocol/Implementation Boundary Examples

This boundary serves both the ecosystem and the business model. Openness at the protocol layer encourages adoption, enables academic study, and invites alternative implementations that grow the DLP ecosystem. Licensing at the implementation layer funds continued development and ensures quality for production deployments.

§24.2 Entity Structure

Three entities constitute the ProtoLex ecosystem. Each entity serves a distinct function. The three-entity structure separates protocol ownership from education from application.

Table 24.2.1: Entity Roles

ProtoLex Inc

ProtoLex Inc is the protocol company. It owns the DLP specification, the substrate runtime, and the tooling suite. Its business model is protocol licensing: organizations that use the ProtoLex substrate or tooling pay ProtoLex Inc.

ProtoLex Inc maintains:

• The DLP specification (open protocol layer)
• The substrate runtime (licensed implementation layer)
• ProtoLex Studio, Campus, SDK, and supporting tools (licensed tooling layer)
• The ProtoLex Verified certification program (§24.5)
• The license verification infrastructure (§24.4)
• The root certificate authority for the license certificate chain

ProtoLex Inc operates its own substrate instance for internal governance. This is not a special instance — it runs on the same platform it licenses to others, demonstrating the recursive viable system pattern at the platform level. ProtoLex Inc's own instance is ProtoLex Verified through the same verification workflow as any licensee — the platform owner is subject to the same conformance and verification standards it requires of others.

ProtoLex Inc also operates the root certificate authority for the license certificate chain (§24.4.1). The root CA is the trust anchor for the entire ecosystem — all certificate chain validations terminate at this root. Root CA key management is ProtoLex Inc's most sensitive operational responsibility.

Gryt Labs

Gryt Labs is a subsidiary of ProtoLex Inc that separates education and community functions from core protocol development. Gryt Labs handles:

• Practitioner onboarding and training
• Certification programs for DLP proficiency
• Community enablement and ecosystem development
• Educational content creation and curriculum

Gryt Labs operates with different economics than the licensing business. Education and training may follow subscription, per-seat, or cohort models independent of substrate licensing terms. The separation ensures that education pricing does not distort licensing economics, and that licensing pricing does not create barriers to learning.

DC Smith Advisory LLC

DC Smith Advisory is an advisory firm that operates GrantsProQR — a callable tool within its EAS substrate instance. DC Smith Advisory is the first customer, not a privileged entity. It is an application built on the ProtoLex platform. Its relationship to ProtoLex Inc is the same as any future licensee: it holds a substrate license, uses the tooling, and owns its application IP.

DC Smith Advisory's position as the first licensee provides:

• Proof of model. Demonstrates that the licensing model works in practice.
• Customer zero. Operates on the substrate it helps validate, providing continuous feedback.
• Go-to-market vehicle. Existing SBA certifications (EDWOSB, WOSB), SAM.gov registration, and client relationships provide market access independent of ProtoLex Inc's licensing channel.
• Application IP ownership. GrantsProQR, its consulting methodologies, and its client-specific configurations are DC Smith Advisory's intellectual property — not ProtoLex Inc's.

GrantsProQR is not a standalone product. It is a callable tool within DC Smith Advisory's EAS substrate instance, exposed via MCP to AI agents, with every use tracked by the substrate's governance machinery. GrantsProQR could be licensed to other practitioners as a substrate add-on — but that licensing flows from DC Smith Advisory (the tool owner), not from ProtoLex Inc (the platform owner).

Entity Relationship Structure

ProtoLex Inc (IP holder, platform owner)
    ├── Owns: DLP specification, substrate runtime, tooling suite
    ├── Licenses to: Substrate licensees
    ├── Subsidiary: Gryt Labs (education, onboarding, certification)
    │
    │   licenses substrate to
    │           │
    │           ▼
    ├── DC Smith Advisory LLC (Licensee #1)
    │       ├── Operates: EAS substrate instance
    │       ├── Products: GrantsProQR (MCP-callable tool, DC Smith Advisory IP)
    │       ├── Services: AI-native grant consulting (substrate-powered)
    │       └── Assets: SBA certifications, SAM.gov registration, client relationships
    │
    └── Future Licensees
            ├── Practitioners (own EAS/BAS instances)
            ├── Enterprises (internal governance substrates)
            └── Tool builders (applications on the platform, their own IP)

Tool IP Ownership

Tool builders own their tool IP. ProtoLex Inc provides the platform; customers provide the domain knowledge, methodology, and application logic. The platform-application boundary is clear: ProtoLex Inc's IP is the substrate runtime and tooling; the customer's IP is everything they build on top.

This applies uniformly across all licensees. DC Smith Advisory owns GrantsProQR. A future licensee who builds a compliance monitoring tool owns that tool. An enterprise that configures internal governance workflows owns those configurations. ProtoLex Inc's licensing revenue comes from platform access, not from claims on customer output.

Revenue Architecture

The three-entity structure produces five revenue streams across distinct channels.

Table 24.2.2: Revenue Stream Architecture

Revenue streams are non-competing. ProtoLex Inc earns from platform access. Tool builders earn from their application IP. Gryt Labs earns from education. Each entity operates in a distinct economic lane — the entity structure prevents internal competition and aligns incentives across the ecosystem.

Multi-Tenant Architecture Implications

The three-entity structure and the broader licensee ecosystem produce multi-tenant requirements at the substrate level. The substrate tracks not only "who made this decision" but "which licensee instance" — enabling per-licensee audit trails and cross-instance queries (with authorization per §23.4 depth-gating). The substrate's existing governance machinery — Actor Context counts, instance registrations, primitive operation records — provides the data foundation for usage-based licensing models without requiring separate metering infrastructure.

Each licensee operates their own substrate instance(s). Instances are isolated by default (§24.4.3). Cross-instance coordination — whether between a licensee's own instances or across federation boundaries — requires explicit authorization and follows the depth-gated visibility model (§23.4). The multi-tenant architecture does not share governance data between licensees; it shares the platform infrastructure that each licensee's governance data operates within.

§24.3 License Types and Terms

Four license types correspond to the four layers. Each license type has distinct terms, obligations, and scope.

Table 24.3.1: License Type Summary

Protocol License

The DLP specification is open. The protocol license grants unrestricted access to read, study, teach, and implement the protocol specification. Attribution to ProtoLex Inc is required when publishing implementations or derivative specifications.

The protocol license covers:

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

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

The open protocol license enables three ecosystem activities that a closed specification would prevent:

1. Academic study. Researchers can analyze the DLP governance grammar, critique the primitive model, and propose extensions — without requiring a commercial relationship with ProtoLex Inc.
2. Independent implementation. Engineers can build their own DLP-conformant systems from the open specification. An independent implementation that passes conformance tests (§24.5.2) demonstrates the specification's completeness and grows the DLP ecosystem.
3. Interoperability research. The open specification enables interchange format development, cross-implementation compatibility testing, and governance data portability research — all of which strengthen the ecosystem without requiring ProtoLex involvement.

Substrate License

The substrate license grants access to the ProtoLex reference runtime — the engineered system that instantiates the DLP protocol. The substrate license is a commercial license with annual or multi-year terms.

The substrate license includes:

• ProtoLex substrate runtime (deployment binary or container)
• Profile content packages (EAS, BAS, PAS) with pre-built governance structures (§21)
• Behavioral invariant enforcement engine
• State transformation and lineage tracking machinery
• UUID watermarking integration (§24.4)
• Certificate chain credentials (§24.4)
• Access to the ProtoLex Verified verification program (§24.5)

Substrate license terms specify four scope dimensions:

Table 24.3.2: Substrate License Scope Dimensions

Instance scope governs active deployments. An archived instance (e.g., a completed PAS) releases its allocation. A development or staging instance may or may not count against the active limit depending on license terms. The specific counting methodology is a commercial decision (§24-C18) — the architecture provides the instance lifecycle events that enable accurate counting.

Profile scope recognizes the structural difference between profile types. An EAS instance activates full RACIVG (§22), all nineteen primitives across five tiers, and the complete governance stack. A PAS instance activates a minimal subset with delegated authority. The governance depth difference may be reflected in license terms.

Tooling License

The tooling license operates on a subscription model — active access requires an active subscription. Tooling access is additive to the substrate license. A tooling subscription without a substrate license provides development and learning capability but no production governance substrate.

Table 24.3.4: Tooling License Tiers

The tooling tier determines the operational surface available to the licensee. The Developer tier provides the integration surface for building applications. The Professional tier adds the governance interface for day-to-day operation. The Enterprise tier adds the organizational capabilities for multi-instance and federated deployments.

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. The decoupling ensures that tooling access can scale independently of substrate deployment scope.

Application License

There is no application license from ProtoLex Inc. Customers own their applications. The licensing relationship is between the customer and the platform — not between the customer and their own output. A customer who builds a tool, configures a workflow, or creates a methodology implementation on the ProtoLex substrate owns that work without encumbrance from ProtoLex Inc.

Customers may license their own applications to others. Tool builders who create applications on the ProtoLex platform can sell, license, or distribute those applications under their own terms. The only requirement for downstream use is that end users who run the application on a ProtoLex substrate must have their own substrate license — the application license from the tool builder does not include substrate access.

Table 24.3.3: License Layer Interaction Matrix

The interaction matrix demonstrates the license independence principle: each layer's license is independently required. A tool builder's application license does not grant substrate access to their customers. A substrate license does not include tooling access. The protocol license is always implicitly present — it is open.

§24.4 License Verification Architecture

License verification operates through a two-layer model: a cryptographic certificate chain for formal attestation and legal enforceability, and a behavioral fingerprinting system for ecosystem monitoring and provenance detection. The two layers are complementary — each addresses limitations the other cannot.

Table 24.4.1: Two-Layer Verification Model

Neither layer is sufficient alone. Certificate-only verification requires active cooperation from the licensee and cannot detect unlicensed implementations. Fingerprint-only verification is novel and harder to explain to auditors or legal reviewers. The combined model provides formal legal foundation through the certificate chain and cost-effective passive monitoring through behavioral fingerprinting.

§24.4.1 Certificate Chain Architecture

The certificate chain provides the formal attestation layer. It follows standard PKI patterns adapted for the substrate licensing model.

Chain of trust:

ProtoLex Root Certificate (ProtoLex Inc controls)
    ↓ signs
Substrate License Certificate (issued per licensee)
    ↓ signs
Instance Attestation Certificate (per deployment)
    ↓ signs
Primitive Record Signatures (individual governance records carry chain)

Issuance flow:

1. License agreement is executed between ProtoLex Inc and the licensee.
2. ProtoLex Inc generates a licensee_id and license_secret for the licensee.
3. A Substrate License Certificate is issued, signed by the ProtoLex root certificate.
4. The licensee receives the certificate and secret through a secure channel.
5. The ProtoLex registry stores the certificate hash — not the secret.
6. On instance deployment, the licensee generates an Instance Attestation Certificate, signed by the Substrate License Certificate.
7. Governance records produced by the instance carry signatures traceable through the chain.

Attestation surfaces. The certificate chain is verifiable at three points:

• Decision records. Every primitive record carries a signature field that traces to the instance attestation certificate, which traces to the substrate license certificate, which traces to the ProtoLex root.
• Substrate exports. Interchange layer exports (§19) include attestation metadata — the full certificate chain for provenance verification.
• Health endpoints. Substrate instances expose a verification-queryable status endpoint that presents the certificate chain for real-time validation.

Revocation capability. If a licensee violates license terms, ProtoLex Inc revokes the Substrate License Certificate. All attestations from that certificate stop validating. Instance attestation certificates derived from the revoked license certificate become invalid. This provides meaningful enforcement without litigation — a revoked certificate immediately degrades the licensee's ability to participate in the verified ecosystem.

Integration with substrate components. The certificate chain integrates with four substrate components:

Table 24.4.1a: Certificate Chain Integration Points

§24.4.2 Behavioral Fingerprinting

The behavioral fingerprint is embedded in UUID generation across all primitives. Licensed implementations use a keyed pseudo-random number generator (PRNG) that produces statistically valid UUIDv4 output with a correlation pattern detectable only by ProtoLex verification infrastructure.

Key derivation:

license_secret   = HMAC-SHA256(protolex_master_key, licensee_id || issue_date)
instance_seed    = HMAC-SHA256(license_secret, instance_id || initialization_time)
prng             = ChaCha20(instance_seed)

UUID generation. The IDENTIFY atomic operation — the substrate operation that assigns identifiers to all primitive instances (§7) — uses the keyed PRNG to generate UUID output. The output is valid UUIDv4 per RFC 4122. The keyed derivation produces output that is statistically indistinguishable from random when examining a single UUID but reveals a detectable correlation pattern across a corpus.

Every primitive instance created by the substrate — every Intent, Commitment, Capacity, Work, Evidence, Decision, Authority, Account, Constraint, and all Tier 2–5 primitives — receives its identifier through this mechanism. The watermark is not applied to a subset of records. It is architectural — embedded in the IDENTIFY operation that all primitive instantiation flows through. This means the watermark corpus grows with every governance action the substrate performs. A substrate instance that has processed a thousand governance decisions has generated thousands of watermarked UUIDs across the primitive graph — more than sufficient for high-confidence attribution.

Why ChaCha20. ChaCha20 is fast, deterministic given a seed, statistically indistinguishable from random, and widely audited. It produces output that passes standard randomness tests while maintaining the keyed correlation property needed for forensic verification. The performance characteristics matter: UUID generation occurs on the critical path of every primitive instantiation. The watermarking mechanism adds negligible latency to governance operations.

Detection properties:

§24.4.3 Instance Correlation Model

Instance correlation controls whether multiple instances from the same licensee are linkable to each other through their UUID patterns.

Table 24.4.2: Instance Correlation Modes

Isolated mode is the default. Each instance derives its seed from unique instance-specific inputs. Two instances from the same licensee produce uncorrelated UUID patterns. This respects licensee privacy and operational independence — ProtoLex can verify that each instance is licensed, but cannot correlate instances to each other without the licensee's cooperation.

Linkable mode is opt-in. The licensee requests linkable mode for multi-instance deployments that require cross-instance provenance (§23). Instances within a deployment group share a seed derivation that enables correlation within the group. Linkable mode is the substrate-level mechanism that supports federated substrates and enterprise multi-instance portfolios where cross-instance lineage is an operational requirement.

Deployment group scoping. Linkable mode operates at the deployment group level, not the licensee level. A licensee with three deployment groups — production, staging, and a separate business unit — can configure linkable mode within each group while maintaining isolation between groups. This enables cross-instance correlation where needed (within a federated portfolio) without exposing the licensee's entire instance topology.

Table 24.4.2a: Correlation Mode Decision Matrix

§24.4.4 Self-Service Verification

Verification is self-service by design. Licensees verify their own compliance without transmitting governance data to ProtoLex Inc.

Verification flow:

1. Licensee runs the protolex-verify tool locally in their environment.
2. The tool extracts UUIDs from the local substrate instance.
3. The tool runs statistical correlation against the licensee's license_secret.
4. The tool validates the certificate chain from instance attestation to ProtoLex root.
5. The tool generates a compliance certificate — a signed attestation of the verification result.

Data sovereignty. ProtoLex Inc receives nothing automatically. The verification tool runs locally. The UUID corpus, governance data, and verification results remain in the licensee's environment. The licensee may optionally submit the compliance certificate to the ProtoLex registry for public attestation, but this is not required.

Auditor access. Licensees provide compliance certificates to auditors. Auditors verify the certificate signature against the ProtoLex public key. The auditor does not need access to the licensee's substrate data, the UUID corpus, or the verification tool internals — the signed certificate is the attestation artifact.

Self-service rationale:

• Removes friction — no data transmission required for verification
• Respects licensee data sovereignty — governance data stays in the licensee's environment
• Scales without ProtoLex operational burden — verification does not require ProtoLex infrastructure
• Generates portable attestation artifacts — compliance certificates are usable for the licensee's own compliance needs

§24.4.5 Verification Access Tiers

Three access tiers govern who can perform what verification activities.

Table 24.4.3: Verification Access Tiers

Ecosystem scanning. ProtoLex Inc may scan publicly accessible exports — published decision records, public substrate endpoints, interchange layer artifacts — for watermark detection. This is passive monitoring. ProtoLex does not access licensee infrastructure, request credentials, or require cooperation. If a public export contains UUID patterns that correlate to a known license, the license is verified. If UUID patterns do not correlate to any known license, the implementation may be unlicensed.

Ecosystem scanning operates only on public data. The scanning infrastructure:

• Examines publicly published governance artifacts (e.g., shared compliance reports, open governance dashboards)
• Extracts UUID corpora from public exports
• Runs statistical correlation against the license registry
• Flags potential unlicensed use for investigation

Ecosystem scanning does not constitute surveillance. It is the license-verification equivalent of checking a published book's ISBN against the publisher's registry. The data examined is data the implementation holder chose to make public.

§24.4.6 Security Properties

Table 24.4.4: Verification Security Properties

§24.5 ProtoLex Verified Designation

ProtoLex Verified is a dual-dimension designation that certifies both licensing status and architectural conformance. It is the ecosystem's authenticity marker — the signal that an implementation is both legally authorized and technically sound.

§24.5.1 Dual-Dimension Model

Table 24.5.1: ProtoLex Verified Dimensions

Both dimensions are required for the ProtoLex Verified designation. Neither alone is sufficient.

Table 24.5.2: Designation Matrix

Licensed but not conformant. An implementation that holds a valid license but fails conformance tests is licensed but not ProtoLex Verified. This can occur when an implementation is in development, when a version upgrade introduces conformance regressions, or when customizations break architectural invariants. The license is valid; the conformance is not. The implementation cannot represent itself as ProtoLex Verified until conformance is restored.

Conformant but not licensed. An implementation built from the open protocol specification that passes all conformance tests is conformant but not ProtoLex Verified. The implementer has demonstrated technical competence — their implementation correctly realizes DLP architecture — but has not entered a licensing relationship with ProtoLex Inc. The implementation cannot represent itself as ProtoLex Verified because it lacks the license dimension.

§24.5.2 Architectural Conformance Testing

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

Table 24.5.3: Conformance Test Levels

Structural conformance is necessary but not sufficient. An implementation can have all nineteen primitives correctly typed yet fail to enforce behavioral invariants. Behavioral conformance is necessary but not sufficient. An implementation can enforce each invariant individually yet fail compositional integrity when primitives interact across complex governance scenarios.

All three levels must pass for the Conformant dimension of ProtoLex Verified.

Table 24.5.3a: Structural Conformance — Primitive Completeness Checklist

Table 24.5.3b: Behavioral Conformance — Invariant Test Categories

§24.5.3 Verification Workflow

The ProtoLex Verified verification workflow combines certificate chain validation with conformance testing.

Initial verification:

1. Licensee deploys a substrate instance with valid license credentials.
2. Certificate chain validates — Substrate License Certificate traces to ProtoLex root.
3. Licensee runs conformance test suite against the deployed instance.
4. Structural conformance (SHACL validation) passes.
5. Behavioral conformance (invariant testing) passes.
6. Compositional conformance (integration testing) passes.
7. Licensee generates a ProtoLex Verified attestation — a compliance certificate that includes both license validation and conformance test results.
8. Attestation is optionally published to the ProtoLex registry for public verification.

Ongoing verification:

ProtoLex Verified is not a one-time certification. Verification status is maintained through continuous monitoring across both dimensions.

• License validity is checked against the certificate chain. Certificate revocation invalidates the Licensed dimension immediately. The substrate validates its certificate chain at initialization, at configurable intervals during operation, and before generating interchange exports. A failed certificate validation immediately transitions the instance from ProtoLex Verified to Conformant Only (or Not Verified if conformance has also lapsed).
• Conformance status is re-verified at defined intervals and after significant configuration changes. The conformance test suite runs as part of the substrate's operational cycle. Re-verification triggers include: scheduled interval (configurable per §24-C15), substrate version upgrade, profile configuration change, constraint set modification, and Tier activation change (enabling Tier 3, 4, or 5 primitives). Any conformance failure transitions the instance from ProtoLex Verified to Licensed Only.
• Watermark integrity is passively monitored through the behavioral fingerprinting layer. The watermark does not require active re-verification — it is a continuous property of UUID generation. However, if the watermark mechanism is disrupted (e.g., PRNG reseeding due to credential rotation), the new watermark pattern must correlate to the current license credentials.

§24.5.4 Designation Lifecycle

Table 24.5.4: ProtoLex Verified State Transitions

ProtoLex Verified status is earned through verification, maintained through compliance, and lost through violation. Restoration follows the same verification workflow as initial certification — there is no expedited path for reinstatement.

§24.5.5 Operational Implications of Each Designation State

Each cell in the designation matrix (Table 24.5.2) has distinct operational implications for the implementation holder.

ProtoLex Verified (Licensed + Conformant). Full ecosystem participation. The instance may:

• Represent itself as ProtoLex Verified in interchange layer exports (§19)
• Participate in federated deployments with ProtoLex Verified practitioners
• Generate compliance certificates that attest to both dimensions
• Operate at the full trust level within the ecosystem

Licensed but not Conformant. The implementation holder has a valid business relationship with ProtoLex Inc but the implementation has technical deficiencies. The instance may:

• Continue operating under its substrate license
• Generate governance records with valid certificate chain signatures
• Participate in interchange, but exports carry license attestation only — not conformance attestation
• Not represent itself as ProtoLex Verified

This state typically indicates an implementation in active development, a post-upgrade regression, or a configuration drift that broke invariant enforcement. The remediation path is technical: run the conformance test suite, identify failures, fix the implementation, re-verify.

Conformant but not Licensed. The implementation correctly realizes DLP architecture — technically sound — but the holder has not entered a licensing relationship with ProtoLex Inc. The instance may:

• Operate the DLP governance grammar correctly
• Not generate watermarked UUIDs (no license credentials for seed derivation)
• Not participate in the certificate chain (no Substrate License Certificate)
• Not represent itself as ProtoLex Verified

This state applies to independent DLP implementations built from the open protocol specification. The implementation demonstrates technical competence. The remediation path is commercial: acquire a substrate license.

Neither Licensed nor Conformant. No ecosystem standing. The implementation has no license relationship and does not correctly realize DLP architecture. No attestation of any kind is available. This state offers no ecosystem participation — no certificate chain, no watermark, no conformance evidence, and no ProtoLex Verified claim.

§24.5.6 ProtoLex Verified and the Interchange Layer

ProtoLex Verified status has specific implications for the interchange layer (§19). When a ProtoLex Verified instance generates an interchange export, the export carries dual attestation: certificate chain signatures (proving license validity) and conformance metadata (proving architectural soundness). Recipients of ProtoLex Verified exports can verify both dimensions against the ProtoLex public key and the conformance test results embedded in the compliance certificate.

When a non-verified instance generates an interchange export, the attestation is partial or absent. A Licensed-only export carries certificate signatures but no conformance attestation. A Conformant-only export carries no certificate signatures. Recipients can assess the trust level of imported governance data based on the attestation completeness — ProtoLex Verified exports carry the highest trust level because both dimensions are attested.

This creates a natural incentive structure: organizations that want their governance exports to carry full attestation — and thus be accepted at the highest trust level by recipients — must maintain ProtoLex Verified status.

§24.6 Federation Licensing

Federation is a recursive pattern — a federated entity operates its own substrate instance with the same internal structure as any other instance (§23.4). Federation licensing specifies how the licensing model extends across legal entity boundaries.

§24.6.1 Federation Licensing Tiers

Three federation licensing tiers provide progressively deeper integration between licensor and licensee.

Table 24.6.1: Federation Licensing Tiers

Each tier represents a deeper constraint integration. At the Methodology Only tier, the licensing constraint specifies methodology adherence — the practitioner follows licensed work programs but operates their own infrastructure. At Full Federation, the licensing constraint extends to infrastructure standards, AI orchestration parameters, shared quality frameworks, and deal flow coordination. The constraint mechanics are identical to the internal tighten-only cascade (§23.2) — only the legal vehicle differs.

Table 24.6.1a: Federation Tier Constraint Detail

The tier structure enables practitioners to select the integration depth appropriate to their practice. A solo practitioner may need only the methodology. A growing firm may add the corpus for knowledge acceleration. A franchise operation adopts full federation for complete platform integration.

§24.6.2 The Licensing Agreement as Constraint Primitive

The federation licensing agreement is the Constraint primitive (§4) instantiated at the organizational boundary between legal entities. This is not a metaphor — the licensing agreement specifies constraints that operate through the same constraint machinery as internal governance constraints.

The licensing agreement specifies:

• Methodology constraints. The practitioner must follow the licensed methodology. Methodology constraints cascade 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 must meet the parent firm's quality standards. Quality constraints are verifiable through the conformance testing machinery (§24.5.2).
• 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.
• 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.

§24.6.3 Federation and Recursive Licensing

Federation licensing mirrors the recursive viable system pattern (§23.1). Just as each recursion level in the internal structure operates the same governance grammar with different threshold calibration, each federation tier operates the same licensing mechanics with different constraint depth.

The recursive property has a licensing consequence: a federated practitioner who operates an EAS instance with child instances (BAS clients, PAS projects) is itself a recursive structure. The licensing constraints from the federation agreement cascade through the practitioner's internal recursion — the practitioner's client BAS inherits constraints from both the practitioner's own EAS and, transitively, from the parent firm's EAS. This is B6 (Constraint binds primitives, §5) operating across both legal entity boundaries and instance boundaries simultaneously.

No recursion depth limit for federation. The protocol does not impose a hard limit on federation depth. 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. The optional depth-awareness signal (§23.1) applies — the substrate can track federation depth and surface advisories, but the protocol does not enforce a maximum.

§24.6.4 Federation Verification

Federation verification extends the ProtoLex Verified model to federated entities.

Parent firm verification. The parent firm holds a substrate license and ProtoLex Verified status for its own instance. The parent firm's ProtoLex Verified status does not transfer to practitioners — each practitioner must independently achieve verification.

Practitioner verification. Each practitioner holds their own substrate license (at the federation licensing tier appropriate to their agreement) and independently achieves ProtoLex Verified status for their own instance. The practitioner's verification is independent of the parent firm's status.

Federation-level verification. The parent firm can verify that its practitioners maintain their ProtoLex Verified status by querying the ProtoLex registry (if practitioners have opted to publish their attestations) or by requesting practitioners to share compliance certificates. The depth-gating constraint applies — the parent firm verifies practitioner verification status, not practitioner governance data.

Table 24.6.3: Federation Verification Independence

The independence model prevents cascading failures. A parent firm's license issue does not invalidate practitioner licenses. A practitioner's conformance failure does not degrade the parent firm's ProtoLex Verified status. Each entity's verification stands on its own credentials.

§24.6.5 Federation Party Responsibilities

Table 24.6.2: Federation Party Responsibilities

§24.7 Profile Graduation Licensing

Profile graduation (PAS→BAS, BAS→EAS) is a topology change in the instance portfolio (§23). Graduation creates a new instance with the target profile. The licensing implication is direct: a new instance requires its own license allocation.

§24.7.1 Graduation and License Requirements

Graduation does not transfer the source instance's license to the new instance. It requires a new license grant — a new instance allocation under the licensee's substrate license.

Table 24.7.1: Graduation Licensing Requirements

§24.7.2 Evidence Carry-Forward

Graduation carries evidence forward from the source instance to the new instance with full lineage preserved. The carry-forward is governed by four rules:

1. Evidence integrity. All evidence artifacts from the source instance carry forward with their original truth types (§6), timestamps, and provenance records intact. No evidence is modified during carry-forward. Authoritative evidence remains Authoritative. Declared evidence remains Declared. Derived evidence remains Derived. The graduation event does not alter epistemic status.

2. Lineage continuity. The graduation decision links the source instance to the new instance through a GRADUATES_TO relationship (§23.3). All carried evidence retains its lineage chain to the source instance. The graduation does not break lineage — it extends it. The carry-forward manifest records every evidence artifact carried, its source instance identifier, and its position in the source instance's governance graph.

3. Watermark continuity. The new instance generates its own UUID watermark from its own instance seed (§24.4.2). Evidence carried from the source instance retains the source instance's watermark — the UUIDs are not regenerated. The new instance's governance records carry the new watermark. A ProtoLex Verified verification of the new instance will detect both watermark sets — the carried evidence's source watermark and the new instance's own watermark — as expected graduation artifacts.

4. Authority chain preservation. Authority delegations active in the source instance do not automatically transfer to the new instance. The new instance establishes its own authority structure at genesis (§18.2). Carried evidence references the source instance's authority chains — these references are preserved for lineage and audit but do not constitute active authority in the new instance. Active authority in the new instance derives from its own genesis authority, not from the source instance's delegation history.

§24.7.3 BAS → EAS Graduation Licensing Detail

BAS → EAS graduation has specific licensing implications beyond PAS → BAS because of the governance feature depth difference.

When a BAS instance graduates to EAS:

1. Profile scope change. The new instance operates at EAS profile tier. If the licensee's substrate license does not include EAS profile scope, the graduation requires a license upgrade before the new EAS instance can deploy.
2. Content package expansion. The new EAS instance gains the governance layer: eight governance domain intents, ~80 governance-specific evidence types, governance accounts, governance commitments, and oversight and advisory authority types (§21.2). This content is part of the EAS content package — licensed under the substrate license at EAS tier.
3. RACIVG activation. The new EAS instance activates V (Verifies) and G (Governs) roles (§22.3). These roles require human actors (§22-C6, §22-C7) — the license scope may need to accommodate additional Actor Contexts for governance role holders.
4. Verification re-certification. The new EAS instance must independently achieve ProtoLex Verified status. The source BAS instance's verification does not transfer. Conformance testing runs against the new instance with its full EAS governance stack.

§24.7.4 Graduation in Federated Contexts

When a federated practitioner's instance graduates (e.g., a practitioner's client BAS graduates to client EAS), the licensing implications follow both the graduation rules and the federation constraint cascade:

• The graduated instance requires a new license allocation under the practitioner's substrate license.
• Federation constraints from the parent firm cascade to the new instance through the practitioner's constraint envelope — the tighten-only rule applies at every level.
• The parent firm's visibility into the graduated instance follows federation depth-gating — the parent firm sees the graduation event in aggregate metrics but does not see the new instance's governance data.
• The practitioner's ProtoLex Verified status is unaffected by the graduation — the new client instance is within the practitioner's instance portfolio, not a new federation relationship.

§24.7.5 Source Instance Disposition

The source instance may be archived or may continue operating, depending on the organizational context.

Archival. When graduation replaces the source (e.g., a project becomes a business — the project is complete), the source PAS instance completes its lifecycle and archives. The archived instance remains queryable for lineage and audit purposes. The archived instance's license allocation is released — it no longer counts against the licensee's active instance limit.

Continuation. When graduation creates a parallel structure (e.g., a business adds enterprise governance while the operational business continues), both instances may operate simultaneously. Both count against the licensee's active instance allocations.

Table 24.7.2: Source Instance Disposition Summary

Boundaries

The licensing architecture constrains the following:

• Protocol openness. The protocol layer cannot be closed. The DLP specification must remain perpetually open.
• Entity independence. ProtoLex Inc, Gryt Labs, and DC Smith Advisory maintain independent roles. No entity can subsume another's function.
• Layer independence. Each of the four layers — protocol, implementation, tooling, application — has independent licensing. License requirements at one layer do not cascade to other layers except where explicitly stated.
• Verification obligation. Every substrate instance must participate in the verification program. Verification is not optional for licensed deployments.
• Application IP protection. ProtoLex Inc cannot claim intellectual property on customer-built applications. The boundary between platform IP and application IP is absolute.

Positions

The following positions are locked decisions:

1. Four-layer model is permanent. The separation of protocol (open), implementation (licensed), tooling (licensed), and application (customer-owned) is structural. It cannot be collapsed or revised.

2. Behavioral fingerprinting is dual-dimension. Verification combines certificate chain (formal) with behavioral watermarking (forensic). Neither dimension alone is sufficient; both are required for full ecosystem participation.

3. Self-service verification is architectural. Licensees verify compliance locally. ProtoLex Inc does not receive governance data automatically. Compliance is verifiable without data transmission.

4. Federation licensing follows recursive viable system pattern. Federation constraints operate as Constraint primitives. Tighten-only cascade applies at every federation level. No federation depth limit is imposed by the protocol.

5. ProtoLex Verified requires both dimensions. Licensed-only and Conformant-only are distinct states. ProtoLex Verified designation requires passing both license and conformance verification. Neither alone is sufficient.

Lineage

§24 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 §24:

• §24-C1: MUST implement certificate chain validation at instance initialization and at defined intervals.
• §24-C2: MUST implement UUID watermarking via keyed PRNG (ChaCha20) for all primitive instantiation.
• §24-C3: MUST support self-service verification without external data transmission.
• §24-C4: MUST embed attestation metadata in all interchange layer exports.
• §24-C5: MUST enforce instance isolation by default; linkable mode requires explicit opt-in.
• §24-C6: MUST implement all three conformance test levels (structural, behavioral, compositional).
• §24-C7: MUST record graduation licensing events as Decision primitives.
• §24-C8: MUST maintain watermark integrity through graduation; mixed watermarks are valid artifacts.
• §24-C9: MUST enforce federation depth-gating constraints architecturally.
• §24-C10: MUST NOT grant ProtoLex Verified to implementations satisfying only one dimension.
• §24-C11: MUST NOT allow production deployments without valid license credentials.
• §24-C12: MUST NOT transmit licensee governance data during verification.
• §24-C13: MUST NOT enable cross-instance correlation in Isolated mode.

Coverage

§24 completeness assessment:

• Four-layer model: Complete specification of protocol, implementation, tooling, and application layers with independence rules.
• Entity structure: Three-entity model fully specified with roles, responsibilities, and revenue architecture.
• License types: All four license types (protocol, substrate, tooling, application) completely defined with scope dimensions.
• Verification architecture: Two-layer model (certificate chain + behavioral fingerprinting) fully specified with security properties.
• ProtoLex Verified: Dual-dimension designation with lifecycle, conformance testing, and operational implications completely specified.
• Federation licensing: Three-tier model with constraint integration, independence properties, and recursive structure fully specified.
• Profile graduation: Graduation licensing with evidence carry-forward, watermark integrity, and source disposition fully specified.

All 19 organizational domain primitives are addressed through the licensing architecture:

• Intent (Purpose): Why the licensing structure exists
• Evidence (Foundation): Research grounding and architectural foundations
• Authority (Governance): ProtoLex Inc governance authority
• Work (Substance): The complete four-layer model, entity structure, license types, verification, federation, and graduation
• Constraint (Boundaries): Licensing constraints and scope limits
• Decision (Positions): Locked design decisions
• Account (Lineage): Version history and lifecycle
• Commitment (Commitments): SDK MUSTs for implementation
• Capacity (Coverage): Completeness assessment

Addressing

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

Key references:

• §24.1: Four-layer licensing model
• §24.2: Entity structure
• §24.3: License types and terms
• §24.4: License verification architecture
• §24.5: ProtoLex Verified designation
• §24.6: Federation licensing
• §24.7: Profile graduation licensing

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

§24 operates within the ProtoLex ecosystem licensing context. It defines how the four layers of the ecosystem (protocol, implementation, tooling, applications) are separately licensed to enable protocol adoption without restricting application creativity. It establishes how three distinct entities (ProtoLex Inc, Gryt Labs, DC Smith Advisory) coexist and partition responsibility. It specifies how licensing terms operate as Constraint primitives in the governance graph, subject to the same behavioral invariants and enforcement architecture as all other governance operations.

Scope Governance

The scope of §24 is: licensing architecture, entity structure, and verification mechanisms for the ProtoLex ecosystem.

The scope excludes: detailed commercial terms (those are in license agreements), specific pricing models, operational procedures for customer support, tax and regulatory compliance, and detailed SDK implementation patterns (those are §24-C1 through §24-C19).

Framing

§24 frames the licensing architecture as integral to the ecosystem, not as ancillary legal structure. Licenses are governance objects — Constraint primitives instantiated in the governance graph. License compliance is verifiable through the same mechanisms that verify all other governance operations. License lifecycle events are Decision primitives with full lineage.

This framing enables:

• Composability: License constraints compose with protocol constraints, federation constraints, and organizational constraints.
• Queryability: License scope and compliance status are queryable through the dual-language query layer.
• Auditability: Every license lifecycle event produces a Decision primitive with full governance context.

Adaptation

Potential extension points:

• Certificate format could evolve from X.509 to alternative PKI mechanisms (§24-C14).
• Verification interval frequency is a design space choice (§24-C15).
• Federation tier definitions could expand to accommodate new patterns as practitioner ecosystems mature (§24.6.1).
• Watermarking mechanism could incorporate additional entropy sources as deployment scale increases (§24.4.2).

Known constraints on adaptation:

• Protocol openness cannot be reversed.
• Four-layer independence is architectural and non-negotiable.
• Behavioral invariants (B1–B10) apply to license constraints identically to all other constraints.

Readiness

Operational status: Specification ready for implementation.

Implementation requirements for production:

1. Root Certificate Authority operational and secured (§24.4.1)
2. Keyed PRNG implementation (ChaCha20) with license secret derivation (§24.4.2)
3. Conformance test suite implementation covering all three levels (§24.5.2)
4. Self-service verification tool with local operation capability (§24.4.4)
5. License-as-Constraint instantiation in governance graph (§25.2)

Meaning Resolution

Key term definitions:

• ProtoLex Verified: Dual-dimension designation (Licensed + Conformant) certifying both legal authorization and architectural soundness.
• Behavioral fingerprint: Statistical pattern in UUID generation detectable across 50+ UUIDs, attributable to a specific license_secret.
• Tighten-only cascade: Constraint propagation rule: children inherit parent constraints and may only tighten, never relax.
• Instance binding: Non-transferable assignment of license allocation to a specific substrate instance; each active instance consumes one allocation.
• Federation licensing: Licensing agreement operating as Constraint primitive across legal entity boundary, subject to same enforcement as internal governance constraints.

Perception Surface

External interfaces for §24 operations:

1. Certificate chain presentation (§24.4.1): Instance health endpoints expose certificate chain for external verification.
2. Interchange layer attestation (§24-C4): Exported governance records carry attestation metadata for recipient verification.
3. Compliance certificate (§24.4.4): Signed attestation artifact provided to auditors, regulators, and federation partners.
4. ProtoLex registry (§24.4.5): Optional public attestation registry where licensees may publish compliance certificates.
5. Ecosystem scanning (§24.4.5): ProtoLex Inc may scan publicly accessible exports for watermark detection.

Temporal Governance

License lifecycle states (§25.2.3):

Verification cycle (§24.5.3):

• Initial verification occurs at instance deployment.
• Ongoing verification: certificate chain validated at initialization, at configurable intervals, and before interchange exports.
• Conformance re-verification at scheduled intervals (per §24-C15) and after configuration changes.
• Watermark integrity monitored passively through UUID generation.

Cross-References

See §25 for structural representation of license terms as Constraint primitives. See §24-C1 through §24-C19 for complete SDK constraints governing §24 implementation.

Related sections:

• §4: Constraint primitive definition (license terms operate through Constraint §4.1)
• §5: Behavioral invariants (all nine invariants apply to license constraint enforcement)
• §21: Substrate profiles (profile types determine license scope)
• §22: Actor layer (Actor Context count determines user scope)
• §23: Portfolio patterns (federation licensing extends recursive viable system pattern)

Terminology

See §24.8 in source for complete terminology definitions.

SDK Constraints

See §24.9 in source for complete SDK constraints (§24-C1 through §24-C19).

End of §24 Entity & Licensing Structure (fspec format v2.0.0)