Adopting: path C (org / platform)

ICP path C: a single upstream corpus you submodule into many products and keep in sync.

Adopting Blueprints — Path C (organization / platform group)

What it is

ICP path C: a single upstream corpus you submodule into many products and keep in sync.

Parent page: Adopting Blueprints. Path A (and usually B) still apply at the repo level; path C adds governance across products.

When to use it

When the decision guide points you to path C.

Prerequisites

  • Documented upstream and bump process; teams comfortable with Blueprint policy and submodule workflows.

Steps

Job to be done: “We want a single upstream corpus we can submodule into many products and keep in sync.”

Step Action Verify
1 Treat the upstream Blueprints repository as upstream; fork only if you must diverge on policy. Documented upstream URL and bump process.
2 Maintain a consumer playbook: submodule bump cadence, Blueprint policy exceptions if any. Updating the submodule is part of ops.
3 For category positioning when briefing leadership, see framework positioning and MVP. Stakeholders have a one-pager link when needed.

Example scenario (path C)

Starting situation Platform team owns autowww/blueprints consumption across fifteen services; security wants a single approved SHA quarterly.
Action taken Publish a “golden” submodule bump schedule; teams follow Updating the submodule; exceptions go through documented policy.
Expected result Product repos move blueprints/ in lockstep or on an approved lag; no silent one-off forks of upstream text.
What to check CI or release notes show bump commits; Platform playbook for Blueprints matches how you coordinate.

How to verify success

Playbook exists; golden SHA or cadence is published; Platform playbook for Blueprints patterns apply when coordinating many repos.

What to do next