Introduction

Scenario: Your mission command app on the supply-chain Ontology runs on your development enrollment, and a partner unit on a separate Foundry stack now needs the same app — so you must package it as a Marketplace product that installs reproducibly and rebinds itself to the destination's Ontology, OAuth client, and hosting.

Unit 8 is the shipping unit: you take the OSDK React application you scoped in Developer Console, generated an SDK against, wired to the Ontology REST API v2, and hosted on Foundry, and you turn it into a portable Marketplace product that another enrollment can install without hand-rebuilding it. This is a coding cohort, so you are comfortable with the TypeScript/React app and its OAuth2 client; what changes here is the unit of delivery. Instead of a running site on one stack, the deliverable is a packaged product plus a successful cross-stack install. The Developer Console-to-Marketplace integration packages the application together with its metadata, its OAuth client specification, its website assets, and its content security policies, and on install it automatically maps environment-specific values — the Foundry URL, the OAuth client ID, the OAuth redirect URL, the Ontology RID, and the Ontology API name — to the destination enrollment. For a deployed website you ship a Production / Singleton product, which is the recommended product shape for this case.

The honesty discipline from earlier units gets sharpest here, because almost nothing you package is something a Foundry READ API can confirm. The Marketplace product itself, the OAuth client spec, the bundled website assets and CSP, the resource-access restrictions, and the install-time parameter mapping are all Marketplace and Developer Console authoring artifacts — they are not introspectable through the Ontology REST API v2. The app is still client-side code packaged with deployment configuration; a documented READ endpoint cannot tell you that you packaged it correctly or that the install rebound every parameter. So the first two steps are honestly self-attested: you assert that you packaged the product and that the install auto-mapped the environment values, and a reviewer attests against your screenshots and the live installed app, not against an API response. Apply Action remains the canonical example of this distinction from Unit 5 — it is a write requiring read and write scopes, and only its resulting object state is read-confirmable, never the call itself.

What you can confirm is the destination's Ontology backbone. After install, the installed app is bound to an Ontology on the destination enrollment, and that Ontology is read-confirmable: a List Object Types call (api:ontologies-read) on the destination should return the five expected supply-chain object types — Supplier, PurchaseOrder, Shipment, InventoryItem, and DisruptionEvent — by their apiNames. That check proves the destination data backbone the app will consume is present and well-formed; it does not prove the install transaction, the packaging, or the parameter mapping, which is exactly why it is the only instance-confirmed step in the unit. Hold that line in your handoff notes so a reader knows precisely which claims are attested and which are machine-verified. (Note: the hosted-application resourceType enum used by the read-confirmation tooling is unconfirmed and should be verified at build time; it is not load-bearing for this unit's checks.)

Capability focus: Marketplace products (Production/Singleton); packaging (OAuth client spec, website assets + CSP, resource restrictions); cross-stack install + parameter mapping. · Artifact: A Marketplace product packaging the app, installed on a destination enrollment.

Key concepts

Companion video

1. 1

   Package the application as a Marketplace product

   Package the application as a Production / Singleton Marketplace product through the Developer Console-to-Marketplace integration. The package bundles the app's metadata, its OAuth client specification, its website assets, its content security policies, and its resource-access restrictions into one versioned, installable artifact — the Production / Singleton shape is the recommended choice for shipping a deployed website. This step is honestly self-attested: the packaged product and everything in it (the OAuth client spec, the bundled assets and CSP, the resource restrictions) are Marketplace and Developer Console authoring artifacts and are not introspectable through the Ontology REST API v2, so no documented READ API can confirm that you packaged the app or that the package contents are correct. Capture the product name, version, and product type so the reviewer can attest against your Developer Console / Marketplace evidence rather than an API response.

   not startedself-attested

   Mark complete

   Self-attested: the app is packaged as a Production/Singleton Marketplace product (metadata, OAuth client spec, assets + CSP).

2. 2

   Install on a destination stack and verify parameter mapping

   Install the product on a separate destination enrollment and verify that Marketplace auto-mapped the environment-specific values to that stack: the Foundry URL, the OAuth client ID, the OAuth redirect URL, the Ontology RID, and the Ontology API name. A successful cross-stack install is the whole reason you packaged the app — the same artifact rebinds itself to the destination without a manual rebuild. This step is also self-attested by design: install-time parameter mapping is a Marketplace workflow artifact, not a data READ API, so no documented Foundry endpoint returns 'the install succeeded' or 'the parameters were mapped.' Record the destination enrollment, the resolved Foundry URL and OAuth client ID/redirect URL, and the bound Ontology RID/apiName from the install summary so a reviewer can confirm the mapping from your evidence; the machine-verifiable consequence of that binding is checked in the next step.

   not startedself-attested

   Mark complete

   Self-attested: installed on another enrollment with auto-mapped Foundry URL, OAuth client, resources.

3. 3

   Confirm the installed app's Ontology backbone on the destination

   Confirm the installed app's Ontology backbone on the destination enrollment by calling List Object Types (api:ontologies-read) there and verifying that the five expected supply-chain object types resolve by their apiNames — Supplier, PurchaseOrder, Shipment, InventoryItem, and DisruptionEvent — each with a primary key. This is the one instance-confirmed step in the unit, and it deliberately confirms only the destination data backbone the app will consume, not the install transaction, the packaging, or the parameter mapping, none of which any documented READ API exposes. A passing check tells you the installed app is bound to a valid, complete Ontology on the destination stack; pair it with your attested packaging and install evidence so the handoff cleanly separates what was machine-verified (the Ontology object types) from what was attested (the product and its cross-stack install).

   not startedinstance check

   Run check

   Confirms the installed app's five object types exist on the destination enrollment.