Skip to main content

Packaging Lifecycle

This document explains the lifecycle of an OPP package, from creation through evolution, usage, and eventual deprecation.

Where the asset lifecycle focuses on individual ownership and reuse, the packaging lifecycle focuses on composition, coordination, and optional value creation.

Packages are designed to be ephemeral and replaceable.
Assets are designed to be durable and persistent.

That distinction is intentional.


Packaging Principles

OPP packages follow a different set of rules than assets:

  • Packages do not own assets
  • Packages do not redefine ownership
  • Packages do not persist forever
  • Packages create value through composition
  • Packages can be replaced without loss

Packages are a convenience layer, not a truth layer.


Stage 1: Package Intent (Off-Chain)

What Happens

A developer, curator, or organization decides to compose assets into a package.

This decision may be motivated by:

  • Distribution
  • Monetization
  • Curation
  • Convenience
  • Execution requirements

At this stage:

  • Assets are selected
  • Non-asset files are prepared
  • Usage semantics are defined
  • Monetization intent is considered

Nothing is yet authoritative.


Stage 2: Package Assembly

What Happens

The package is assembled off-chain into a deterministic structure.

This may include:

  • References to OGAL assets
  • Code and logic
  • Metadata and configuration
  • Media files
  • Runtime instructions

A canonical archive is produced with:

  • Stable paths
  • Deterministic ordering
  • Content hashing

This ensures the package can be verified later.


Stage 3: SBOM Generation

What Happens

A Software Bill of Materials (SBOM) is generated for the package.

The SBOM declares:

  • Which OGAL assets are included
  • Ownership references for each asset
  • Usage semantics
  • Optional value intent

The SBOM becomes the authoritative declaration of package composition.

Important:

  • SBOMs describe intent
  • SBOMs do not execute logic
  • SBOMs do not enforce monetization

Stage 4: Package Registration (OPP)

What Happens

The assembled package and its SBOM are registered via OPP.

OPP assigns:

  • Package identifier
  • Version reference
  • Content hash

Key properties:

  • Registration is explicit
  • Registration is non-custodial
  • Assets remain governed by OGAL

OPP does not validate business logic. It validates structure and references.


Stage 5: Distribution & Discovery (Optional)

What Happens

Packages may be:

  • Indexed
  • Listed
  • Shared
  • Distributed
  • Integrated into applications

This can occur via:

  • First-party tools
  • Third-party marketplaces
  • Direct distribution

Key properties:

  • Distribution is optional
  • Discovery is competitive
  • No single index is privileged

Packages can exist without markets.


Stage 6: Consumption & Execution

What Happens

An application consumes a package.

The application:

  • Resolves asset references via OGAL
  • Interprets usage semantics
  • Applies monetization logic if desired
  • Executes code and runtime instructions

Important:

  • Platforms decide enforcement
  • SBOM guides, not commands
  • Deviations must be visible

Execution is local. Truth remains global.


Stage 7: Versioning & Replacement

What Happens

Packages are versioned, not mutated.

Common actions:

  • Publish a new version
  • Deprecate an old version
  • Replace a package entirely

Key properties:

  • Old packages remain verifiable
  • New packages do not overwrite old ones
  • Assets are unaffected

Versioning prevents silent behavior changes.


Stage 8: Deprecation & Obsolescence

What Happens

Packages may become obsolete due to:

  • Better alternatives
  • Asset updates
  • Platform changes
  • Market shifts

Deprecation:

  • Is non-destructive
  • Does not affect asset ownership
  • Does not break other packages

Packages can disappear without collateral damage.


Failure Modes & Containment

FailureImpactContainment
Invalid SBOMPackage rejectedAssets unaffected
Broken logicLocal execution failureOGAL unchanged
Market delistingDiscovery lossPackage still usable
Creator exitNo updatesAssets persist

Packages fail safely by design.


Why This Lifecycle Matters

This lifecycle ensures:

  • Assets are never trapped by packaging
  • Monetization never becomes mandatory
  • Coordination can evolve without lock-in
  • Innovation does not threaten stability

Packages create value. They do not own it.


One-Sentence Summary

OPP packages are created deliberately, versioned explicitly, consumed locally, and replaced freely, while underlying assets remain durable, portable, and independently governed.


Where to Go Next