It is not.

The project is intentionally split into three runtime responsibilities.

Foundry​

Foundry runs on the admin workstation and builds the deployment media.

That includes:

• WinPE customization
• expert configuration authoring
• staging configuration for the two WinPE applications

Foundry.Connect​

Foundry.Connect runs first in WinPE and acts as a network gate.

It exists so the deployment workflow does not start before the environment is actually ready.

Foundry.Deploy​

Foundry.Deploy is the deployment experience itself.

It loads the catalogs, exposes the deployment wizard, and runs the deployment steps in order.

Why the handoff matters​

This split keeps each product focused:

• authoring stays on the workstation
• connectivity validation stays at bootstrap time
• deployment execution stays in the deployment app

That is the mental model used throughout the documentation site, and it is the right way to think about the platform when you are debugging or extending it.

The goal is simple:

• keep the product split clear
• make onboarding easier
• give contributors a stable place for architecture notes and workflow guidance

The documentation is organized around the actual runtime flow:

1. Foundry builds the media.
2. Foundry.Connect validates network readiness in WinPE.
3. Foundry.Deploy loads catalogs and runs the deployment workflow.

That separation matters because each product has a different runtime, a different responsibility, and different configuration concerns.

This first version of the site focuses on:

• getting started
• architecture and product boundaries
• configuration guidance
• developer workflows

Expect future posts to cover release notes, catalog changes, and deeper implementation details.