Glossary

The SHAPE Framework. A Spec-driven, Human-led, Agentic Product Engineering operating model for enterprise software development. It combines organization, an enterprise technical framework, and a specification-driven development process through UAT.

Spec-driven. An approach in which intended product behavior is captured in maintained, version-controlled specifications that guide implementation and independent verification.

Human-led. Human roles remain accountable for business intent, architectural decisions, quality evaluation, and acceptance even when coding agents perform substantial implementation.

Agentic. A mode of work in which AI agents undertake multi-step development or verification tasks using authorized tools and context, under human direction and enterprise constraints.

Product Engineer (PE). The central human role connecting discovery, specifications, AI-assisted implementation, validation, and ongoing ownership of a bounded product portfolio.

Pod. A small product-centered working unit led by a Product Engineer and supported by shared architect and UX expertise.

Architect / Senior Engineer. The shared technical specialist who contributes to Stage 2 technical foundation work, defines and reviews architectural boundaries, supports significant decisions and exceptions throughout the lifecycle, and stewards enterprise assets across a bounded portfolio. The Product Engineer owns implementation and maintenance within those boundaries.

UX designer. The shared specialist who shapes interaction and experience direction and evaluates functioning software as it evolves.

Business stakeholder / client. A person representing the needs, business rules, or acceptance of the product. “Client” need not imply an external commercial customer.

Coding agent. An AI system authorized to produce or modify software and related artifacts within an approved working environment.

Verification agent / independent verification context. An AI-assisted checking process separated from implementation context and directed to derive tests from committed specifications rather than simply reproducing the implementer's assumptions.

Specification corpus. The current set of maintained feature specifications defining intended product behavior.

Feature specification. A bounded, durable description of expected behavior, actors, rules, exceptions, and verifiable acceptance conditions.

Acceptance condition. An observable statement that helps determine whether specified behavior has been delivered.

Standing instructions. Persistent rules and context telling an agent how to work and which project or enterprise constraints apply; distinct from individual feature requirements.

AGENTS.md. The discoverable root instruction entry point used in the SHAPE repository convention to direct agents to all Markdown files in agent_instructions/.

agent_instructions/. An extensible directory for self-describing, project-relevant Markdown instruction and context documents. The framework does not mandate particular filenames inside it.

specs/. A separate area containing product feature specifications rather than standing agent instructions.

Enterprise assets. Approved, reusable organizational capabilities such as platforms, libraries, architecture conventions, common components, security mechanisms, and documented guidance.

Approved execution environment. The technical setting in which an agent works with enforced access, tool, data, and permission boundaries established under enterprise policy.

Technical foundation work. Proportionate preparation within Cycle 1 Stage 2: approved stack and reuse choices, architectural boundaries, coherent instructions, and technically enforced permissions. It proceeds alongside UX direction and specification generation. SHAPE adds no separate mandatory readiness approval; the two planned implementation reviews occur at Stages 4 and 7.

Cycle 1. The eight-stage initial development process: discovery; parallel UX direction, technical foundation work, and specification generation; implementation; initial architect review; stakeholder iteration; independent verification; final architect review; UAT.

Cycle 2. The four-stage enhancement process: specification and implementation change; independent verification; policy/risk-driven architect review; UAT.

Spec-Based Testing. Independent verification that derives checks from the committed specification corpus, exercises the implementation where practical, and records the resulting evidence and unresolved limitations.

Architect sign-off. A technical review outcome under enterprise policy; not equivalent to stakeholder business acceptance.

UAT (User Acceptance Testing). The organization's authorized business process for determining whether a product or change meets intended needs.

Bounded product portfolio. The set of applications a Product Engineer can own sustainably while allowing time for ongoing changes, maintenance, and current projects.

Shared asset promotion. The reviewed process of adopting a useful local pattern or component into organization-wide reusable materials.

Terms are defined here for consistency. Their dedicated conceptual pages explain the rationale, and Practitioner Guides describe actions. Where appropriate, follow the linked role, process, or artifact page for more detail.