1. Purpose and scope
Derivatives are where the platform pays back. Each derivative is a new product, usually a new SoC, but with a much shorter specification and integration phase because most of it comes from the platform. The derivative team's job is to choose the platform configuration that fits its market, reuse as much as it can unchanged, add only the content that makes its product different, and show that the result still conforms to the platform, so that it keeps receiving the platform's maintenance and security releases for its whole life.
Every derivative request is sorted into one of three paths. Covered by the platform's options: configure and go. Not covered, but useful to other products: raise a platform change request so the platform grows the option. Not covered and useful only to this product: record a deviation, which the platform board must approve, and which the derivative will own and maintain itself. The conformance test suite is the evidence that the derivative is still on the platform.
In scope: the derivative request, the derivative product plan, the derivative IP licence check, the derivative configuration, configured IP, the derivative virtual platform and build configuration, the derivative reference board changes, the derivative security assessment, the derivative architecture review, the deviation list, platform change requests, the derivative conformance report, the derivative release audit, the derivative release record and the support handover. Out of scope: the derivative's own tape-out, qualification and production, which run in its SoC and Product lifecycles.
12 more sections for registered members.