OPP Schema Reference (SBOM)

OPP packages describe composition, ownership references, and optional monetization intent via a Software Bill of Materials (SBOM). This page summarizes the SBOM structure and packaging metadata that OGAL-aware tools expect.

SBOM structure overview

An SBOM describes a single package and is divided into four sections:

1. Package metadata (identity and provenance)
2. Asset manifest (required)
3. Usage semantics
4. Value intent (optional)

Package metadata

Typical metadata fields include:

• Package ID — stable identifier for the package.
• Version — semantic version or revision marker.
• Creator / curator — public key or identity reference.
• Creation timestamp — when the package was assembled.
• Canonical content hash — integrity hash for the packaged content.
• Description — human-readable description of the package.

Package metadata is informational; it does not enforce behavior or ownership.

Asset manifest (required)

Each entry in the asset manifest declares:

• OGAL Asset ID (ObjectManifest PDA address)
• Asset type (level, model, dataset, etc.)
• Owner public key (for verification)
• Mutability flag (whether updates are allowed)
• Inclusion role (core, optional, dependency)

The manifest is verified against OGAL state. If an asset is transferred or removed, verification fails cleanly without altering OGAL state.

Usage semantics

Usage semantics describe how the package is intended to be consumed (not enforced by the protocol). Common signals include:

• One-time vs. recurring use
• Subscription or metered access
• Unlimited internal reuse

Platforms may honor or ignore these signals, but deviations should remain visible to users.

Value intent (optional)

Value intent is the optional monetization declaration. When present, it defines:

• Whether monetization applies
• Which assets participate in value sharing
• Relative weight or share per asset
• Explicit opt-in/opt-out flags

If the value intent section is omitted, the package is treated as non-monetized by default.