operating-model / loops/platform-loop/build.md
id: platform-loop.buildtype: domainstatus: activeversion: 2.0loop: platform-loop

Domain · Build and ship

What it covers

Turning designed specs into production code, validating them, deploying them, and confirming with the requesting loop that the blocker is resolved.

Activities

  • Building features, integrations, and infrastructure.
  • Testing and validation.
  • Deployment and release management.
  • Post-ship validation with the requesting loop — did the change actually unblock what it was meant to.

Operations

Build operation

Designed spec → implementation → code review → ready for testing. Build work stays scoped to the spec; scope creep is rejected rather than quietly accepted.

Test and validate operation

Implementation complete → automated tests run → manual validation where required → regression check → ready for deploy.

Deploy and release operation

Validated change → deployment to production → release note published → consuming loop owners notified.

Ship validation operation

Post-ship check-in with the loop that specced the change → "is your blocker resolved?" → outcome logged in queue → spec marked closed or re-opened with notes.

Notes

The ship validation operation is what closes the platform loop cycle. A queue item marked "shipped" but not validated with the requesting loop is a lie to the queue — eventually loop owners stop trusting the queue and start routing around it.

Consuming loops need to adopt shipped capabilities — the Platform Loop ships the capability, but the primary loop owner is responsible for folding it into their automation. Release communication should make adoption steps explicit.

Comment on GitHub →