§25 License Terms Architecture

The Decision Lineage Protocol establishes a three-layer licensing model (reference §24) that defines what is licensed at each architectural layer: the open protocol specification, the open reference implementation and assets, and commercially delivered substrates. This section specifies the architectural principles governing how license terms are structurally represented within the governance substrate, how license scope binds to instances, how license constraints cascade through federation boundaries, and how the ecosystem supports multiple independent paths for adoption.

License terms in DLP are not ancillary legal documents attached to an engineering system. They are first-class governance objects — Constraint primitive instances in the governance graph, subject to the same invariant enforcement and governance lineage guarantees that govern all other operational aspects of the substrate. A license agreement is a Constraint instance. License compliance is queryable through the dual-language query layer. License lifecycle transitions produce Decision primitives with full governance lineage. This structural integration is foundational.

License-as-Constraint Architecture

Structural Representation

The licensing agreement between the protocol implementer and a licensee is represented as a Constraint primitive with the following properties:

The Constraint primitive's enforcement modes apply directly to license terms:

• Blocking: Hard license limits that prevent operation beyond scope (e.g., instance count exceeded)
• Warning: Alerts for approaching license limits or expiration
• Logging: Usage tracking for compliance visibility
• Advisory: Optimization suggestions

License Lifecycle

Licenses transition through defined lifecycle states. Every transition produces a Decision primitive with full governance lineage:

Every state transition records the transition authority, rationale, and effective date through the governance record. License revocation or expiration ends the engagement's entitlements — custodial operation, update channels, support — but never degrades the substrate itself: the licensee's governance operations, data, and exports remain fully available (§24.3, no-DRM commitment). Enforcement is a commercial and legal matter, never technical degradation.

Queryability

Because license terms are Constraint primitive instances, they participate in the governance graph and are queryable through the dual-language query layer (reference §28):

Graph traversal (via Cypher): Traverse from a substrate instance to its governing license constraints, from constraints to their source authority, and from constraints to cascade targets across federation boundaries. Graph traversal answers structural questions: Which constraints govern this instance? What is the federation constraint chain? Which instances share constraint sources?

Relational aggregation (via SQL): Aggregate license scope utilization — active instance count versus licensed count, actor capacity versus licensed capacity, profile deployment patterns. Relational queries answer operational questions: What percentage of licensed capacity is consumed? When does the license term expire?

Cross-instance federation queries: In federated deployments, license constraints are visible at federation boundaries. A parent organization can traverse to federation licensing constraints governing a federated practitioner — the constraint structure is visible even when the practitioner's governance data is depth-gated (reference §23.4). This visibility distinction is precise: the parent sees the constraint terms, not the constrained practitioner data.

Constraint Layer Precedence

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

• Protocol constraints — the behavioral invariants (B1–B10, §5), universal and non-negotiable
• License constraints — the licensing agreement terms, varying by license type and scope
• Profile constraints — the profile configuration (§21), activating specific governance features
• Federation constraints — if federated, the federation licensing agreement terms
• Organizational constraints — the licensee's own governance policies

When constraints from different sources apply to the same primitive, enforcement mode hierarchy resolves conflicts: Blocking > Warning > Logging > Advisory. A license constraint cannot downgrade a protocol invariant. An organizational policy cannot downgrade a license constraint. This monotonically tightening composition prevents constraints from being circumvented through policy layering.

License Scope and Instance Binding

Per-Instance Licensing Model

Instance-level licensing applies to the commercial layer only: self-hosted deployments of the open reference stack consume no allocation of any kind. Where a Studio commercial engagement meters delivery by instance, every active commercially delivered instance consumes exactly one allocation. Instance binding is non-transferable. The allocation bound to 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.

Profiles and Commercial Scope

Profiles (PAS, BAS, EAS) are substrate configurations (§21), never license tiers (§24.6). Any profile runs on the open reference stack without commercial authorization. Where a Studio engagement exists, its scope describes what is delivered and operated — which instances, what content composition, what custodial services — and a delivered instance's children (e.g., PAS instances spawned under a delivered BAS) fall within the parent engagement rather than requiring separate authorization.

Tighten-Only Cascade

License constraints cascade through instance topologies and federation boundaries. 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 across internal (parent spawning child) and external (federation) boundaries. The tighten-only rule is the architectural guarantee that license terms cannot be circumvented through instance topology — spawning a child instance does not create governance space outside the license constraint envelope.

Examples of constraint cascade:

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

Federation License Architecture

Federation as License Boundary

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

Federation licensing agreements specify:

• Methodology constraints: The federated practitioner follows the parent organization's licensed methodology. Constraints cascade from parent to practitioner and onward to practitioner's child instances.
• Quality constraints: The practitioner meets the parent organization's quality standards, verifiable through conformance testing machinery (reference §24.5).
• Reporting obligations: Aggregate metrics flow upward; depth-gating ensures individual engagement detail remains private to the practitioner.
• Depth-gating rules: Parent organization sees aggregate performance across practitioners, not individual engagement data. Enforced architecturally through depth-gated visibility (§23.4), not procedurally.

The federation agreement is a composed structure of primitives:

Federation(parent → practitioner) =
    Intent     (relationship purpose)
  + Authority  (delegated methodology authority, scoped)
  + Constraint (federation licensing constraints)
  + Commitment (mutual obligations)
  + Work       (operational scope)
  + Account    (relationship context and history)

Every lifecycle event in the federation relationship — creation, modification, termination — produces a Decision primitive with full governance lineage.

Federation Tiers

Federation licensing agreements specify constraint categories — methodology adherence, quality standards, infrastructure standards, reporting obligations — with deployment-specific enforcement modes. The constraint composition mechanics are protocol-level commitments; the specific category-to-mode mapping is licensee implementation.

Federation License Independence

Federation licensing does not create dependency between the parent organization's standing and the practitioner's standing. Each entity's substrate, data, and any commercial engagements stand independently.

• If the parent organization's engagement terminates: federation constraints lose authority; the agreement terminates. The practitioner is unaffected.
• If the practitioner's engagement terminates: the federation relationship terminates; cascaded constraints lift. The practitioner's own substrate and governance data are unaffected — no party ever loses access to their own substrate (§24.3, no-DRM commitment).

This independence model prevents cascading failures. Each entity's standing rests on its own relationships.

Recursive Federation

Federation mirrors the recursive viable system pattern. A parent organization can federate with a practitioner who federates with a sub-practitioner. Each federation boundary is a licensing agreement operating as a Constraint primitive:

Parent Org (EAS) ──license constraint──→ Practitioner (EAS) ──license constraint──→ Sub-Practitioner (EAS)

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

• Parent organization's federation constraints
• Practitioner's federation constraints
• Sub-practitioner's own constraints

No federation level can relax any constraint imposed at a higher level. Depth emerges from organizational viability, not from protocol limit.

Federation Verification

Each entity in the federation chain independently maintains its own conformance status (§24.4). The parent organization can verify that practitioners maintain conformance without accessing practitioner governance data.

Verification mechanisms at the federation boundary:

• Practitioners share conformance attestations with the parent organization
• The parent organization verifies attestations, not governance data
• The federation agreement determines the reporting obligation — from periodic attestation up to conformance-as-Blocking-constraint, per the agreement's enforcement modes

Ecosystem Growth Model

Three Entry Paths

Three paths lead into the DLP ecosystem. Each path has distinct requirements and value propositions:

Path Independence and Transitions

The three paths are independent. An organization building from the open specification can later acquire a substrate license without discarding existing work. An organization deploying the substrate can add tooling support independently. Each path can transition to others without architectural barriers:

• Build from spec → Adopt the reference stack: The open reference implementation may be adopted wholesale or in part; an existing specification-based implementation may be migrated or run alongside. Governance data remains portable through the interchange layer.
• Reference stack → Studio-delivered substrate: Content authored against the open stack loads into a Studio-delivered substrate at genesis; the open deployment may continue or archive with lineage.
• Any path → Federation: A federation agreement layers on top. Each party's independent standing is unchanged.

Interoperability Across Implementations

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

Interoperability does not require license alignment. Any conformant instance can exchange governance data with any other through the interchange layer. Conformance attestations provide provenance information counterparties can use for trust evaluation — but attestation is informational, not prerequisite for data exchange.

License Compliance Architecture

Compliance as Integrated Operation

License compliance is not a separate system layered on top of the substrate. It is a governance operation embedded in the substrate lifecycle:

• License constraints are Constraint primitives
• Compliance verification produces Evidence records
• Compliance decisions are Decision primitives with Account context
• Compliance integrates with instance initialization, operation, and lifecycle transitions

The compliance architecture has three components: conformance testing (architectural soundness), invariant compliance (behavioral correctness), and — where a commercial engagement exists — engagement scope verification (scope adherence).

Conformance Testing

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

All three levels must pass for conformant designation. Conformance testing is open and self-service (§24.4); federation or commercial agreements may additionally adopt it as a contractual obligation.

Scope Verification

Engagement scope verification is the operational compliance component for commercially delivered substrates; open self-hosted deployments have no scope dimensions to verify. Where an engagement exists, the substrate validates its deployment against the contracted scope dimensions through local verification:

Scope dimensions verified (per engagement terms):

• Instance count (active delivered instances versus contracted count)
• Delivery scope (what was contracted for generation and operation)
• Actor capacity (active actor contexts within contracted limits, where metered)

Verification occurs at instance creation, profile graduation, actor context creation, and at configurable intervals during operation. Violation responses follow constraint enforcement modes: Blocking prevents the operation, Warning alerts, Logging records silently.

Scope verification operates locally. The substrate tracks its scope dimensions against license Constraint primitives instantiated in the governance graph. No external call to any vendor is required — the license terms are self-contained within the governance graph.

Compliance Lifecycle Integration

License compliance integrates throughout the substrate's operational lifecycle:

• At instance creation (Genesis): Where an engagement exists, its license constraints are instantiated in the governance graph as part of genesis.
• During operation: Engagement scope dimensions, where present, are continuously validated. Constraint violations produce Evidence records. Warning violations generate alerts.
• At data export (interchange): Exports may carry conformance attestation as provenance metadata (informational, never gating).
• At profile graduation: Graduation is a governed topology event with full lineage (§24.6). Where a commercial engagement exists, scope verification is triggered and engagement terms may require updating.
• At renewal or expiration: Expiration ends engagement entitlements (custodial operation, update channel, support). The substrate itself and all governance data remain fully operational and exportable. The compliance record persists for audit regardless of engagement status.

Scope

The license terms architecture constrains the following:

1. Structural representation: All license terms must be represented as Constraint primitive instances in the governance graph, not external legal documents.

2. Non-transferable binding: Where commercial allocations exist, each active delivered instance consumes exactly one allocation. Allocations cannot be transferred between instances. Open deployments consume no allocation.

3. Tighten-only cascade: License constraints must cascade through federation boundaries and spawning relationships following the tighten-only rule. No child instance may relax any parent constraint.

4. Enforcement universality: The same license constraint enforces identically for all licensees holding that constraint. Conservation law prevents selective application.

5. Data sovereignty: License revocation or expiration must not destroy governance data and must not degrade the substrate. All records remain operational and exportable; enforcement is commercial and legal, never technical (§24.3).

6. Independent entry paths: The three ecosystem entry paths (open specification, open reference stack, Studio delivery) must remain independent and non-coercive. Organizations must be able to enter and transition freely.

7. Integrated compliance: License compliance is a governance operation embedded in the substrate lifecycle, not a separate audit system.

Locked Design Positions

The following design decisions are fixed:

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. Where commercial allocations exist, each active delivered instance consumes exactly one allocation; open deployments consume none.

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, the open reference stack, and Studio delivery must remain independent and non-coercive.

5. Compliance is integrated, not layered. License compliance operates through the governance machinery, not as a separate system.

Related Sections

• §24 Entity Licensing Structure: Three-layer licensing model, entity structure, license types, license attestation, conformance verification, profile graduation
• §4 Constraint Primitive: License terms operate through Constraint (§4.1)
• §5 Behavioral Invariants: B1–B10 apply to license constraints; shapes graph implementation
• §23 Portfolio Patterns: Spawning, graduation, federation relationships that trigger licensing events
• §28 Dual-Language Query Layer: License constraints queryable through Cypher and SQL
• §19 Interchange Layer: Data portability across implementations and license boundaries

End of §25 License Terms Architecture (L0 Public Specification)