Principles of the SHAPE Framework
These principles explain what makes an implementation of the SHAPE Framework recognizable. The details of particular tools, templates, and review checklists can vary, but these commitments should remain visible.
1. Start from business intent. Product development begins by understanding the problem, the people affected, and the expected outcome. Producing code is not itself evidence that a business need has been met.
2. Keep humans responsible. Coding agents may implement and propose solutions. Product Engineers and specialists remain responsible for requirements, consequential technical decisions, validation, and acceptance.
3. Specify intended behavior. Maintain version-controlled feature specifications. Review and update specifications when behavior changes. Do not treat unstructured prompts or chat histories as the sole enduring record of product requirements.
4. Use approved enterprise assets first. Reuse mandated libraries, components, services, security capabilities, and patterns. Introducing new shared technology or changing standards requires appropriate review and authorization.
5. Enforce agent boundaries technically. Written instructions alone do not restrict an agent's access. Approved environments, permissions, and tooling restrictions are necessary controls.
6. Prefer working feedback over exhaustive upfront prediction. Establish sufficient initial UX direction and technical constraints, then refine behavior through functioning software and stakeholder review.
7. Verify independently against specifications. Use a separate verification context to derive and execute checks from committed requirements. Record what was verified, what failed, and what remains uncertain.
8. Preserve specialist scrutiny. Architects and UX designers participate where their expertise is needed. Initial development includes architect reviews; later reviews follow applicable enterprise policy and risk.
9. Keep product ownership continuous and bounded. Product Engineers remain responsible for the applications they maintain, including future changes. Limit portfolios so that maintenance and new work remain manageable.
10. Improve the shared system. Learn from each project. Promote useful patterns into shared assets through appropriate architectural governance, instead of repeatedly solving the same problems in isolation.
11. Remain proportional to risk. The framework is not an excuse to bypass controls, nor an invitation to add ceremony for every minor decision. Use stronger assurances when application risk or policy requires them.
12. Respect the process boundary. The SHAPE development cycle runs from requirements intake through UAT. Post-UAT release and operations continue under the enterprise's established procedures.
Spec-driven intent, human-led outcomes
Spec-driven means agents preserve intended behavior for implementation and independent verification. It does not impose manual feature-document authoring, fixed identifiers or universal human specification sign-off. Agents can maintain context while building and must not redefine intent to excuse incorrect code.
Human-led means humans inspect working outcomes, decide consequential business rules and accept the product through their organization's process. Product feedback can begin before polished prose exists. Enterprise risk controls, two Cycle 1 implementation reviews, independent verification and UAT remain essential. A master specification remains under consideration, not an adopted mandate.
Reading these principles
A principle describes an enduring requirement or preference. A practitioner guide describes a way to carry it out. For example, independent verification is part of the framework; the exact testing harness or test-report format may vary by organization. Similarly, approved execution boundaries are mandatory, while the enterprise chooses their specific implementation.