Downstream application composition

A downstream application pins PlatformKit and supplies the modules, configuration and assets its product needs. Client configuration selects capabilities and branding; client-specific Go belongs in a module. The public architecture defines that boundary.

Keep dependencies explicit

The application owns composition. Follow the reference application’s ordered module constructors: each constructor takes typed dependencies and returns a manifest. The application connects the returned capabilities to consumers that need them. Modules depend on each other’s public contracts, and the foundation remains independent of downstream implementations.

Use the existing contracts/, internal/ and module.go structure for a new capability. The module guide explains those boundaries and links to the reference implementation. Configuration selects among the capabilities the application composes; it does not discover or load Go code.

Reuse the owning capabilities

Supply branding through design.Pair and the existing shared UI composition. The reference application passes its theme to admin.Deps; a product that owns another shell can use the same components and stylesheet composition. It does not need a second token system or component registry.

Each selected module supplies its own migration source. The foundation collects sources in composition order and retains each owner’s history. Follow the migration ownership contract when evolving a capability or changing a composition.

The downstream application owns its configuration format, provider choices and deployment inputs. Keep its setup instructions beside that implementation so they describe the loader and composition actually being run.

Verify the selected composition

Read the contribution guide before adding a module, then run the owning application’s checks against its pinned dependencies. Exercise the selected providers, migrations and user journeys; a module’s isolated checks do not establish that the application is wired correctly.

The reference binary supports --role web|worker|all. Those roles still need verification of shared storage, schema compatibility, migration ownership and provider behavior in the intended environment. See operations for the public runtime boundary and getting started to run the reference application.

Related architecture maps: client flow and module map.