Offering

#How It Works

Every Offering references exactly one Offering Nature. Offering Nature is an organization-defined instance configured in CA-OFFNAT, and each nature selects exactly one business-equation archetype. That archetype is the behavioural driver: it decides which economic parameters are active, how Purchase-contract payments are generated, and how the Offering's P&L is read.

The price of an actual sale is not stored on the Offering. Unit price and the real SLA commitments are contract-level terms set at point of sale on a Purchase Contract. Gross margin, realized cost of goods, and LTV are derived metrics computed from financial facts — never stored as Offering source truth. Realized cost of goods, in particular, derives from Ledger Events.

#Statements

These statements fix the meaning of an Offering and the boundary between offering-level structure and contract-level commercial terms.

Identity and ownership

• An Offering is a cataloged capability made available by a Node.
• An Offering belongs to a Node.
• An Offering has an identity and a name.

Nature and behaviour

• An Offering has an Offering Nature.
• CA-OFFNAT configures Offering Natures.
• An Offering Nature selects a business-equation archetype.
• A business-equation archetype activates the economic parameters that govern offering behaviour.

Commercial terms and derived economics

• A Purchase Contract carries contract-specific unit price and SLA terms for an Offering.
• Offering realized cost of goods derives from Ledger Events.
• Offering gross margin derives from financial facts.

#Operations

Offering operations bring catalog items into existence and move them through their availability states. They keep an Offering anchored to a valid Offering Nature, and they preserve the business-equation archetype that nature selects — the behavioural driver that decides how the Offering earns and how its economics are read.

An Offering's economic behaviour is fixed by the business-equation archetype resolved through its Offering Nature. If creation or a status change could alter that archetype, every Purchase contract and P&L view downstream would lose its meaning. These operations keep the nature-to-behaviour link stable while letting an Offering's availability evolve.

Create Offering establishes a new catalog item against a valid Offering Nature and derives its business-equation archetype from that nature; the archetype then drives the Offering's economic behaviour. Update Offering Status moves the Offering's availability posture through its status lifecycle without disturbing the business-equation archetype the Offering was created with.

Create Offering

• Create Offering creates an Offering.
• Create Offering uses a valid Offering Nature.
• Create Offering derives the business-equation archetype from the Offering Nature.
• Create Offering uses the business-equation archetype as the economic behaviour driver.

Update Offering Status

• Update Offering Status changes the Offering's availability posture.
• Update Offering Status preserves the Offering's business-equation archetype.

#Lifecycle

Offering status answers a simple question: is this catalog item available to be bought right now, and where is it in its catalog life? An Offering moves through DRAFT, ACTIVE, DEPRECATED, and RETIRED. Whatever its status, it stays consistent with whether configuration is ready, whether its owning node is valid, and the business-equation behaviour it was configured with.

The catalog is what contracts reference, so an Offering's status has to be trustworthy: deprecating or retiring an item must not silently rewrite the contracts already built on it, and an item should only be sellable when its configuration basis and owning node actually support it. Status is the signal that keeps the catalog and the agreements that depend on it in agreement.

The standard defines the status values as DRAFT, ACTIVE, DEPRECATED, and RETIRED. A new Offering is created in DRAFT, only after the governing configuration basis exists and on a Node whose archetype permits offering ownership — a Container Node never owns an Offering. Activation moves DRAFT to ACTIVE, at which point new Purchase contracts may reference it. Deprecation moves it to DEPRECATED, and retirement to RETIRED; neither silently rewrites existing Purchase contracts, and historical contract, ledger, and wallet records are preserved. Because the all-or-nothing bundle model applies, any Bundle that includes a deprecated or retired Offering is deprecated as a consequence.

Status never changes what the Offering is: it continues to resolve its business-equation archetype through its Offering Nature, and the one-to-one offering wallet is created and removed with the offering lifecycle.

• Offering status represents availability posture.
• Offering status aligns with configuration readiness.
• Offering status aligns with owning-node validity.
• Offering status preserves the Offering's business-equation archetype.

#Financial View

For an Offering, expected cost of goods is what the configured unit cost says the period should have cost; realized cost of goods is what the ledger actually recorded. The standard keeps the two separate and reports the variance between them, so a difference is visible as a signal rather than averaged away.

Expected and realized answer two different questions — what was planned versus what happened — and conflating them would hide exactly the gap a P&L reader cares about. Keeping realized cost strictly derived from Ledger Events also means it can never be quietly overwritten by an expectation; the expectation is configuration, the realized value is ledger fact.

Expected offering cost of goods is the offering's configured unit cost of goods multiplied by the units sold in the period, where units sold is the count of Product Sale Ledger Events for that offering in the window. Realized offering cost of goods is the sum of that offering's cost-of-goods Ledger Event amounts in the same window. Variance is realized minus expected. A percentage variance is available when expected cost of goods is greater than zero; when expected is zero the absolute variance is still meaningful and is not hidden just because a percentage would be undefined.

• Expected offering cost of goods derives from offering unit cost of goods and units sold.
• Current units sold derives from Product Sale Ledger Event count.
• Realized offering cost of goods derives from offering cost-of-goods Ledger Events.
• Cost-of-goods variance equals realized cost of goods minus expected cost of goods.
• Percentage variance uses expected cost of goods greater than zero.
• Absolute variance works when expected cost of goods equals zero.

For the cross-cutting derivation rules see Source Truth, Ledger Classification, and Period Scope.

#Configuration

Offering behaviour is governed by one Configuration Artifact with one embedded component:

• CA-OFFNAT — defines the Offering Natures available to the organization and their unit-type and lifecycle restrictions.
• CA-BUSEQU — the business-equation component inside CA-OFFNAT that selects the archetype driving offering and Purchase-contract economics.

See each CA page for its prerequisites, statements, and dependency role.

#Why It Matters

The Offering is where the organization's catalog meets its economics, and the standard keeps the two layers apart. Offering-level structure says what the capability is and which economic parameters are active; contract-level terms say what a specific sale actually costs. Keeping that boundary clean lets one Offering be sold many times on different terms without rewriting the catalog, and it is why price, margin, and realized cost never live on the Offering.

#Related

• Node
• Container Node
• Bundle
• Contract
• Wallet
• Ledger Event
• Configuration Artifact