The Specy PRD metamodel defines the vocabulary you use to describe why a product exists and what it should deliver — the layer upstream of system requirements and the domain model. It is organized in six layers: a Product & Problem layer that roots the document and states the pain it answers, a Demand layer that models who the users are and what they are trying to accomplish, an Intent layer that makes the business bet measurable, a Solution layer that describes what actually ships, an Uncertainty & Boundaries layer that names what the team does not know and cannot choose, and a Roadmap & Traceability layer that sequences delivery and links product decisions forward into .sysreq requirements.

Each layer below gives a one-sentence definition of every concept and a link to its detailed page. The PRD is the top of the provenance chain — Product → System Requirement → Domain → Code — so every concept here is eventually answerable by a testable EARS statement downstream.

The full, authoritative specification is the PRD metamodel, served verbatim from PRODUCT-REQ-METAMODEL.md in the specy-ai/skills repository. The diagram below maps every concept and its relations in one place; each node jumps to its definition in the specification.

Specy Product Requirement Metamodel Product Requirement Metamodel 1 0..n 1..n 0..n 1..n 0..n 0..n 0..n 0..n 0..n 1..n 1..n 0..n 0..n 0..1 0..1 1 0..n 1..n 1..n 0..n Problem Statement Situation, Complication, Question Supporting Evidence Type, Summary, Source, Date, Confidence Product Vision, Scope, Non-goals Persona Role, Goals, Frustrations, Context, Weight Job Statement, Type, Importance, Satisfaction Desired Outcome Statement, Importance, Current satisfaction Assumption Statement, Impact if wrong, Validation plan, Status Risk Likelihood, Impact, Mitigation, Owner Constraint Statement, Source, Impact Open Question Question, Context, Owner, Deadline, Status Feature FEAT-NNN · Summary, Value proposition, Priority (MoSCoW), Status, Non-goals User Story US-NNN · As a <persona>, I want <action>, so that <outcome> User Journey Persona, Trigger, Outcome Goal Statement, Horizon, Owner Hypothesis Intervention, Expected outcome, Mechanism, Validation method, Status Release Target date, Theme, Status, Entry & Exit criteria Acceptance Criterion AC-NNN-NN · a testable condition Journey Step Action, System response, Channel, Emotional tone, Order Success Metric Indicator, Target, Baseline, Measurement method System Requirement EARS statement whose source references the FEAT / US / AC identifier specy.ai
Click any node to jump to its definition in the PRD Metamodel. Download the diagram (SVG)

Product & Problem

This layer roots the document and grounds it in a real pain: the strategic container, the problem it exists to solve, the evidence that the problem is real, and the boundaries that keep it from sprawling.

Product — the top-level container that groups everything the PRD describes: its vision, its scope, and every persona, goal, feature, and release beneath it. See Product & Problem.

Problem Statement (SCQ) — the pain the product exists to solve, framed as Situation → Complication → Question without prescribing a solution; the why behind every feature. See Product & Problem.

Supporting Evidence — data, research, or analysis that grounds the problem and product decisions in fact rather than opinion, each item carrying a type, source, date, and confidence level. See Product & Problem.

Non-Goals — explicit declarations of what the product deliberately does not aim to do, by design rather than deferral — permanent strategic boundaries that prevent scope creep. See Product & Problem.

Demand

This layer models the demand side — the people the product serves and what they are trying to get done — independently of any solution.

Persona — a research-grounded behavioral archetype of a target user: their goals, frustrations, context, and weight (primary, secondary, or excluded). See Personas & Jobs.

Job — a situation-triggered task a persona is trying to accomplish, stated solution-independently in the form When [situation], I want to [motivation], so I can [outcome]; stable across product and technology pivots. See Personas & Jobs.

Desired Outcome — a measurable criterion from the persona’s perspective for how well a job is getting done; the customer’s yardstick, distinct from business success metrics. High importance plus low satisfaction marks an underserved outcome. See Personas & Jobs.

Intent

This layer makes the business bet explicit: the outcomes the product pursues, the numbers that decide whether it works, and the causal claims that connect features to those numbers.

Goal — a measurable business objective the product pursues, stated as an outcome rather than a feature, with a horizon and an accountable owner. See Goals & Hypotheses.

Success Metric — a quantitative decision criterion that determines whether a goal is met, with an indicator, a target, a baseline, and a measurement method. See Goals & Hypotheses.

Hypothesis — a testable causal claim linking a feature to a goal — if intervention, then outcome, because mechanism — with a validation method and a status (proposed … validated/invalidated). See Goals & Hypotheses.

Solution

This layer describes what the product actually offers: the capabilities, the persona-specific narratives that justify them, and the end-to-end flows that span them.

Feature — the primary unit of product planning: a named capability described in user terms, prioritized with MoSCoW, carrying a status, value proposition, feature-level non-goals, and design references. See Features, Stories & Journeys.

User Story — a persona-specific narrative of one way a feature delivers value, in the form As a [persona], I want [action], so that [outcome], whose acceptance criteria are the primary candidates for EARS formalization. See Features, Stories & Journeys.

User Journey — a sequence of steps a persona takes to accomplish a goal across one or more features, broader than a story and including moments the product does not control. See Features, Stories & Journeys.

Journey Step — a single interaction within a journey, capturing the persona’s action, the system response, the channel, an optional emotional tone, and its order. See Features, Stories & Journeys.

Uncertainty & Boundaries

This layer makes the unknown and the non-negotiable explicit — the four distinct ways a PRD acknowledges what it does not know, what could go wrong, and what it cannot choose.

Assumption — something believed true but not yet validated, carrying its impact-if-wrong, a validation plan, and a status; the hidden load-bearing walls of product decisions. See Risks, Assumptions & Constraints.

Risk — something that could go wrong and damage the product, users, or business, scored by likelihood and impact with a mitigation strategy and an owner. See Risks, Assumptions & Constraints.

Constraint — a non-negotiable boundary that limits product decisions — a fact, not a choice — sourced from regulation, contract, technology, or organization, and often generating system requirements directly. See Risks, Assumptions & Constraints.

Open Question — an acknowledged unknown the team must resolve before a decision can be made, naming the gap rather than hiding it, with an owner, a deadline, and a status. See Risks, Assumptions & Constraints.

Roadmap & Traceability

This layer sequences delivery and connects product decisions forward into the rest of the Specy chain.

Release — a planned delivery milestone that groups features into a shippable unit, with a theme, a target date, entry and exit criteria, and dependencies on other releases. See Releases & Traceability.

Traceability to System Requirements — the forward bridge from PRD to .sysreq: each EARS requirement’s source field references the feature, story, acceptance criterion, constraint, or goal it came from, enabling feature-to-requirement coverage and change-impact analysis along the full Product → Requirement → Domain → Code chain. See Releases & Traceability.