Commercial delivery is not a source-code zip sent to a customer. BitzOrcas separates product source, customer-owned code, and release evidence with packages, templates, licensing, and independent gates.

Three worlds

World	Contents	Allowed dependency style
Product repository	Full Framework, Platform, Profiles, Hosts, and Tooling source	Internal integration may use `ProjectReference`
Consumer Solution	Customer-owned Hosts, business modules, and tests	Uses `PackageReference` through a private feed
Release batch	Immutable nupkg files, signatures, provenance, SBOM, policy evidence	Read only by controlled release and GA workflows

The product repository’s integration conveniences must not leak into customer projects. Generated solutions cannot reference product-repository paths or copy Framework, Platform, or Licensing implementation source.

Delivery chain

Product source
  → build / test / Release publish
  → pack immutable NuGet packages
  → produce hashes / provenance / SBOM / policy evidence
  → sign and timestamp
  → upload to authenticated private feed
  → generate Consumer Solution
  → restore through PackageReference
  → activate Runtime License
  → Commercial GA

Each stage answers a different question:

Catalogs and Profiles define which packages a customer receives.
Templates define which source code the customer owns.
Feed entitlement defines which packages and versions the customer can download.
Runtime License defines which capabilities a deployment may run.
Commercial GA proves packages, evidence, and external consumption came from one trusted release.

Packages and Profiles

Machine-readable catalogs register every publishable project. A Profile is a reusable package closure, not a second copy of implementation code. A template combination projects Profiles, Host roles, Generators, Endpoint/Job assemblies, and License Features into the Consumer Solution.

Generators enter declared Hosts directly as PrivateAssets=all analyzer references. They do not rely on NuGet transitive analyzer propagation.

Release train and immutability

One commercial batch binds a full 40-character commit, package version, package set, every nupkg SHA-256, signers, provenance, SBOM, policy result, and external Consumer. A change to any identity-bearing input requires a new batch; a published version cannot be overwritten.

Change	Reuse the batch?	Correct action
Release-note text only	Depends whether evidence indexes it	Preserve audit and revalidate the index
nupkg content or dependency	No	Increment version, repack, and resign
Signer rotation	Never silently	Update trusted fingerprints and emit new evidence
SBOM/vulnerability result	Do not ignore	Re-run policy gates
Consumer template	No	Re-run external consumption in a new candidate

Uploading different bits under the same version breaks caches, signatures, hashes, and customer reproducibility; it is not a patch mechanism.

Responsibility by boundary

Role	Core responsibility	Deliverable
Framework maintainers	Dependencies, public API, generators, template boundary	Packable source and tests
Release workflow	Reproducible build, pack, sign, upload, evidence index	Immutable artifact
Package platform	Feed availability, authentication, version immutability	HTTPS restore endpoint
Security/OSS governance	Signers, vulnerability threshold, third-party licenses	Policy evidence
Commercial operations	Entitlement and Runtime License issuance	Customer/deployment authorization
Application delivery	Consumer configuration, migration, cutover, rollback	Target-environment acceptance

No single team can replace the complete evidence chain with “my job is green.”

Example: the real generation path of a multi-tenant authorized platform

Take public profile default-business-multi-authorization (with either RuntimeAdapter). Boundary note: all fifteen current profiles generate only an API Host — JobHost, Website, and similar hosts are later standalone adoptions, not reachable through parameters.

The template derives default-business-multi plus PlatformModule=authorization from ProfileChoice and copies the native asset tree for the chosen ORM;
It generates only customer-owned output: the BitzConsumer.Api host shell, a Business Starter module skeleton, and Unit/Architecture test projects;
AppHost orchestrates SQL Server, Schema Migrator, the API, and RabbitMQ; the authorization variant adds authorization bootstrap plus dedicated persistence identity parameters;
Endpoint / DI / ORM Fluent Config wiring arrives through analyzer-form Generators (PrivateAssets=all) attached to the declared Host — never through transitive flow;
Every BitzOrcas.* package restores from the private feed at one release-train version;
The Profile’s License feature closure is frozen into static requirements while local Consumer Contracts validate restore→build→test→publish behind four isolated caches.

If generated output contains src/Framework or a product-repository ProjectReference, delivery boundaries have failed.

Verify machine-readable manifests

The commercial catalog and Profile closure in the product repository are the delivery source of truth. The manual must not maintain a separate handwritten package list.

# Validate catalog, Profile closure, and packability.
dotnet test tests/BitzOrcas.Architecture.Tests \
  --configuration Release \
  --filter 'FullyQualifiedName~CommercialPackageCatalogTests'

# Prove an isolated Consumer can restore, build, test, and Release publish.
dotnet test tests/BitzOrcas.Framework.ConsumerContract.Tests \
  --configuration Release --blame-hang-timeout 12m

Catalog tests prove declaration consistency. Consumer Contracts prove current candidates are consumable outside the repository. Neither result proves the formal-feed artifact has passed GA.

Assign failures to the right layer

Failure	Boundary	Invalid workaround
Restore 403	Package Entitlement	One shared long-lived token for every customer
Host reports License Unavailable	Runtime License	Disable the License gate
One tenant cannot use a feature	Tenant Feature	Modify the global Runtime License
Consumer misses a package	Profile/package closure	Copy product source into customer code
Provenance hash mismatch	Release identity	Repack from the current branch
Readiness unhealthy	Runtime environment	Route traffic based only on `/health/live`

Current status

The repository implements commercial catalogs, Profile closures, the Consumer template matrix, local Consumer Contracts, Runtime License contracts, and Commercial GA verification. Formal GA still needs the release environment to supply the real private feed, short-lived credential, trusted signers, SBOM, policy evidence, and external Consumer artifact.

The accurate statement is: “GA gate capability exists and awaits a real release batch,” not “merging code automatically completes GA.”

Precise completion language

Commercial delivery is complete only when the target batch is immutable, the formal feed restores, signatures and policies pass, the external Consumer completes its flow, Runtime License matches deployment context, target readiness and migration pass, rollback conditions are executable, and the observation window triggers no stop condition.

When a real feed, short-lived credential, trusted signer, SBOM, or external Consumer artifact is missing, record “external prerequisite unavailable.” Never rename a green local contract test to GA.

Commercial Delivery Overview

Three worlds

Delivery chain

Packages and Profiles

Release train and immutability

Responsibility by boundary

Example: the real generation path of a multi-tenant authorized platform

Verify machine-readable manifests

Assign failures to the right layer

Current status

Precise completion language

In this section

Chapter Navigation

Consumer Contract Tests

Private NuGet Feed Setup and Operations

Runtime License

Online License Issuance and Distribution

Commercial GA Gate