Skip to main content

SBOM Design

This document describes the design and role of the Software Bill of Materials (SBOM) used by the Open Package Protocol (OPP).

The SBOM is the connective tissue between ownership, composition, and optional value coordination.
It is intentionally declarative, machine-readable, and non-executing.

Purpose of the SBOM​

The SBOM exists to answer one question precisely:

What is included in this package, who owns it, and how value is intended to flow if monetization occurs?

The SBOM does not:

  • Move money
  • Enforce payments
  • Gate access
  • Override platform behavior

It provides clarity, not control.

Design Principles​

The SBOM is designed around five core principles:

  1. Declarative, Not Imperative
    The SBOM declares facts and intent. It does not execute logic.

  2. Auditable by Default
    Any platform, tool, or market can independently verify it.

  3. Composable
    SBOMs can reference assets that appear in other SBOMs without conflict.

  4. Non-Custodial
    Ownership always resolves back to OGAL.

  5. Future-Safe
    New monetization models can be added without invalidating existing packages.

SBOM Scope​

An SBOM describes a single OPP package.

It includes:

  • Asset composition
  • Ownership references
  • Usage semantics
  • Value intent (if applicable)

It does not describe:

  • UI behavior
  • Pricing enforcement
  • Platform-specific logic

Core SBOM Structure​

At a high level, an SBOM contains four sections:

  1. Package Metadata
  2. Asset Manifest
  3. Usage Semantics
  4. Value Intent

Each section is optional except the asset manifest.

1. Package Metadata​

This section identifies the package itself.

Typical fields:

  • Package ID
  • Version
  • Creator / Curator
  • Creation timestamp
  • Hash of canonical contents
  • Optional description

This metadata is informational and non-authoritative.

2. Asset Manifest (Required)​

The asset manifest is the heart of the SBOM.

For each included asset, it declares:

  • OGAL Asset ID
  • Asset type (e.g. level, model, dataset)
  • Owner public key
  • Mutability flag
  • Inclusion role (core, optional, dependency)

The manifest:

  • Does not duplicate ownership state
  • References OGAL as the source of truth
  • Can be verified independently

If an asset is removed or transferred, verification will fail cleanly.

3. Usage Semantics​

Usage semantics describe how the package is intended to be consumed, not how it must be consumed.

Examples:

  • One-time use
  • Recurring use
  • Subscription-based access
  • Metered usage
  • Unlimited internal reuse

These semantics are descriptive:

  • Platforms may honor them
  • Platforms may ignore them
  • Platforms must make deviations visible

The SBOM documents intent, not enforcement.

4. Value Intent (Optional)​

If monetization is intended, the SBOM may declare value intent.

This includes:

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

Important constraints:

  • Value intent is explicit
  • Value intent is optional
  • Base assets remain free outside the package

If no value intent is declared, the package is treated as non-monetized.

What the SBOM Does Not Do​

To avoid ambiguity, the SBOM explicitly does not:

  • Hold balances
  • Trigger transfers
  • Escrow funds
  • Execute splits
  • Enforce pricing

Those responsibilities live at the platform and application layer.

Verification Model​

Any party can verify an SBOM by:

  1. Reading the SBOM document
  2. Resolving asset IDs against OGAL
  3. Confirming ownership and mutability
  4. Validating hashes and references

Verification is:

  • Deterministic
  • Stateless
  • Non-interactive

No coordination with the package creator is required.

Failure Modes and Safety​

If verification fails:

  • The package can be rejected
  • The platform can warn users
  • Execution can halt safely

Failure does not:

  • Corrupt OGAL state
  • Affect other packages
  • Cascade across the ecosystem

The SBOM is fail-closed by design.

Evolution and Versioning​

SBOMs are versioned documents.

This allows:

  • Schema evolution
  • New monetization models
  • New asset types
  • Backward compatibility

Old SBOMs remain valid artifacts. New platforms can choose how much they support.

Why This Design Works​

This SBOM design:

  • Preserves creator ownership
  • Enables trustless coordination
  • Avoids protocol rent-seeking
  • Keeps platforms sovereign
  • Scales across industries

It creates alignment without centralization.

One-Sentence Summary​

The SBOM is a machine-readable declaration of composition, ownership, and value intent that enables coordination without custody, enforcement without trust, and evolution without lock-in.

Where to Go Next​