Handbook
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
- Updating the Blueprints submodule
- Team rollout patterns
- Adopting Blueprints — recap paths A / B