Node Types

Your product model in Specor is a directed graph of typed nodes connected by typed relationships. Understanding what each node type represents helps you build a clear, consistent model.

How the graph is organized

The graph follows a natural product hierarchy:

Domain
└── Capability
    └── Feature
        ├── Flow
        │   └── Step
        ├── Rule
        ├── AcceptanceCriteria
        ├── Metric
        └── Need (can also be stand-alone)

Actor        (stand-alone, links to Flows)
Decision     (stand-alone, links to any node)

Nodes at the top of the hierarchy (Domain, Capability, Feature) provide structure. Nodes attached to Features (Rules, Metrics, Flows, etc.) capture the detail of what a feature actually does and means.

Domain

A Domain is the top-level grouping for a product area or business domain. Think of it as the highest-level slice of your product.

Good domain names: Checkout, User Management, Notifications, Payments, Onboarding, Search

When to use: When you need to separate a major area of the product with its own business logic, team ownership, or compliance boundary.

A domain contains one or more Capabilities.

Capability

A Capability is a bounded area of functionality within a domain. It groups related features that work together to deliver a larger outcome.

Example: Inside the Checkout domain:

Payment Processing
Cart Management
Address Validation

When to use: When a domain is large enough to have distinct sub-areas, each of which could be independently owned or built.

A capability has:

A maturity field (e.g. experimental, stable, deprecated) to signal how production-ready it is
One or more Features

Feature

A Feature is a specific thing your product does — a discrete piece of functionality that a user or system can interact with.

Example: Inside Payment Processing:

One-click Purchase
Split Payment
Saved Card Management

When to use: Whenever you have a named piece of behaviour that can be built, shipped, tested, or measured independently.

A feature has:

A status field: planned, in_progress, shipped, deprecated
Attached Rules, Acceptance Criteria, Metrics, Flows, and Needs

Flow

A Flow is a user journey or process that implements a Feature. It describes the sequence of steps a user or system takes.

Example: Inside One-click Purchase:

Express Checkout
Error Recovery (Declined Card)

When to use: When a feature has a meaningful step-by-step interaction — an onboarding flow, a checkout sequence, an error-handling path.

A flow contains ordered Steps and can involve one or more Actors.

Step

A Step is a single action within a Flow. Steps are ordered and can have transitions between them (next step, branching).

Example: Inside Express Checkout:

Select saved address
Confirm payment method
Place order

Each step has:

order_index — position within the flow
expected_duration_s — optional estimated time in seconds

Steps connect to each other via next_step edges to define the path through the flow.

Actor

An Actor is a person or external system that participates in your product. Actors are linked to Flows to indicate who performs actions.

Examples:

Registered User — someone with an account
Guest — unauthenticated visitor
Payment Gateway — external service (e.g. Stripe)
Support Agent — internal team member

When to use: When you need to track who or what drives a flow — especially useful for multi-actor workflows and for surfacing missing ownership.

Actors are stand-alone — they exist at the workspace level and can be linked to any number of Flows.

Need

A Need is a user or business need that one or more features are meant to address. Needs capture the why behind features.

Examples:

Reduce checkout friction
Increase payment conversion rate
Support enterprise SSO requirements

When to use: When you want to ensure your features actually map to real user or business goals. The AI agents will flag features with no linked Need and Needs that no feature addresses.

Needs can be stand-alone or directly linked to a Feature via the addresses relationship.

Rule

A Rule is a business rule or constraint that governs a Feature. Rules define what must be true for the feature to function correctly.

Examples:

Order total must not exceed the user's credit limit
Discounts cannot be stacked with promotional codes
Refunds must be processed within 7 business days

Each rule has:

statement — the rule in plain language
enforcement — how it’s enforced (e.g. hard, soft, manual)

Rules belong to a Feature and are checked by the conflict detection agent for contradictions.

Acceptance Criteria

An Acceptance Criteria is a pass/fail condition that defines when a Feature is complete. It’s the testable definition of done.

Examples:

User completes checkout in ≤ 3 taps
Payment failure shows a user-readable error within 2 seconds
Guest users cannot access saved payment methods

Each criterion has:

statement — the condition in plain language
automated — whether it is covered by an automated test

Acceptance Criteria belong to a Feature and are used by the AI agents to flag features without testable definitions.

Metric

A Metric is a measurable outcome linked to a Feature. Metrics define how you know if a feature is working.

Examples:

Checkout completion rate (target ≥ 80%, direction: up)
Average time to complete checkout (target ≤ 45s, direction: down)
Payment failure rate (target ≤ 2%, direction: down)

Each metric has:

unit — what you’re measuring (e.g. %, seconds, count)
target_value — the number you’re aiming for
direction — whether higher (up) or lower (down) is better

The AI agents will flag features with no linked Metric and Metrics with no target_value set.

Decision

A Decision is a recorded product or architectural decision. It captures what was decided, why, and when.

Examples:

Use Stripe as the payment processor (chosen over Adyen for developer experience)
Limit one-click purchase to orders under $500 (regulatory risk above this threshold)

When to use: When your team makes a call that will affect how the product is built and you want a durable record of the reasoning. Decisions can be linked to any node.

Relationships at a glance

Relationship	From → To	Meaning
`has_capability`	Domain → Capability	A domain contains this capability
`has_feature`	Capability → Feature	A capability exposes this feature
`has_flow`	Feature → Flow	A feature is implemented by this flow
`has_step`	Flow → Step	A flow contains this step
`next_step`	Step → Step	Ordering / transitions between steps
`addresses`	Feature → Need	A feature addresses this user need
`governed_by`	Feature → Rule	A feature is governed by this rule
`measured_by`	Feature → Metric	A feature is measured by this metric
`validated_by`	Feature → AcceptanceCriteria	A feature is validated by this criterion
`involves`	Flow → Actor	An actor participates in this flow

A complete example

Domain: Checkout
└── Capability: Payment Processing  (maturity: stable)
    └── Feature: One-click Purchase  (status: in_progress)
        ├── Need: Reduce checkout friction
        ├── Rule: Order total must not exceed credit limit
        ├── Metric: Checkout completion rate (target ≥ 80%)
        ├── AcceptanceCriteria: User completes checkout in ≤ 3 taps
        └── Flow: Express Checkout
            ├── Step 1: Select saved address
            ├── Step 2: Confirm payment method
            └── Step 3: Place order  ← involves → Actor: Registered User