SDD solution catalog

Control validated processes from intent to evidence

SDD is persistent and interconnected structured memory for validated processes: business intent, requirements, specifications, procedures, risks, controlled execution, tests, releases, and evidence.

Software development is one process domain SDD can govern, but the core value is broader: every department works from the same traceable context, from demand to decision to proof.

Try it Now View solution stories

Intent

Requirement

Specification

Risk

Protocol

Test

Evidence

One chain for governance, controlled execution, QA, validation, and audit.

Demand capture

Capture the business or process intent

Start from the original reason for change before it is reduced to tickets, procedures, or test work.

Source

Conversation, uploaded document, issue, ticket, MCP Add Intent, or operational finding.

SDD control

SDD searches project memory, related items, vocabulary, duplicates, and previous decisions.

Output

Intent record with source, author, rationale, candidate links, and suggested requirement direction.

Proof line

The original context remains connected to every later requirement, change, and proof artifact.

Source noteIntentCandidate links

Controlled need

Turn intent into an approved requirement

Make the need precise enough to review, approve, implement, test, and audit.

Source

Approved intent, imported requirement, business rule, process constraint, or regulatory obligation.

SDD control

SDD applies category, hierarchy, lifecycle state, ownership, and review policy.

Output

Controlled requirement with status, parent/child links, rationale, and change history.

Proof line

Approval evidence explains why controlled execution may start and what scope it covers.

IntentRequirementApproval

Execution contract

Describe the controlled change

Translate the requirement into a process, product, or software contract with acceptance boundaries.

Source

Approved requirement, project knowledge, architecture context, procedures, and historical decisions.

SDD control

SolveRequirement and SolveSpecification create linked specifications and acceptance criteria.

Output

Specification, acceptance criteria, assumptions, and implementation boundary.

Proof line

Each specification remains traceable to the requirement and to the tests that will prove it.

RequirementSpecificationAcceptance criteria

Risk and control

Connect risks before execution

Bring risk analysis into the same memory as requirements and validation, instead of rebuilding it at the end.

Source

Requirement, process step, equipment, compliance context, hazard, failure mode, or tester remark.

SDD control

SDD links risks to controls, mitigations, verification rows, and impacted artifacts.

Output

Risk-control model with trace links to protocols, test cases, and evidence.

Proof line

Validation can show which control answers which risk and where it was verified.

RequirementRiskControl measure

Protocol and procedure

Bind procedures and protocols to the current process state

Prepare controlled execution with the right version, prerequisites, tools, data, suites, cases, and steps.

Source

Specifications, risk controls, prerequisites, required tools, required data, and release context.

SDD control

SDD versions test suites, test cases, protocols, TCF/TPO imports, and execution setup.

Output

Protocol content and execution session ready for controlled testing or process verification.

Proof line

The protocol is generated from source data instead of being manually reassembled.

SpecificationProtocolVersioned suite

Execution evidence

Execute while keeping design and result aligned

Record manual or automated execution without separating step design from results, comments, and evidence.

Source

Test case, versioned steps, expected result fields, execution session, tester comments, and evidence files.

SDD control

SDD keeps each step and result together, tracks comments, deviations, found issues, and status.

Output

Run results with pass/fail/N/A status, detailed answers, evidence, and issue links.

Proof line

Execution evidence stays aligned with the designed step and its requirement/risk origin.

Test caseRun sessionStep result

Audit package

Generate the proof from structured memory

Produce documents and matrices from the same linked records used to manage the validated process.

Source

Runs, approvals, releases, reference documents, risks, requirements, suites, cases, and history.

SDD control

SDD assembles controlled exports, traceability matrices, revision records, and approval metadata.

Output

DOCX, PDF, XLSX, traceability matrix, version history, and audit-ready evidence package.

Proof line

The final proof references the source history instead of describing itself or disconnected documents.

Run evidenceApprovalExport

Who benefits

WIIFM by role

Each group gets a different outcome, but the same source of truth.

Management and PMO

Govern validated processes from business demand to release and verification evidence.

They get status that is based on linked requirements, issues, tests, and approvals instead of slideware or manual reporting.

Business demand stays connected to process definition, implementation work, and verification.
Review gates, ownership, and change requests are visible.
Process risk is easier to explain before it becomes budget or compliance risk.

Product owners and business analysts

Turn intent, meetings, and domain knowledge into requirements that can be reviewed.

They stop losing business nuance between conversation, ticket, specification, implementation, and validation.

Intent becomes structured requirements with context.
Duplicate and inconsistent demands can be detected earlier.
Acceptance intent survives the move into engineering, QA, validation, and operations.

Architects and system owners

Keep architecture decisions and project conventions available to every agent and contributor.

They get fewer isolated AI changes because agents work from persistent project memory and best-practice prompts.

Reusable system and process context is searched before work starts.
Process and development contracts define responsibility boundaries.
Service impact analysis shows what a change may affect.

Engineering and implementation teams

Solve requirements, specifications, procedures, and issues with the business context already loaded.

They spend less time reconstructing why work exists and more time producing controlled, traceable changes.

SolveRequirement, SolveSpecification, and SolveIssue guide implementation.
Approval gates prevent premature process or code changes.
Commits, tests, and comments carry SDD references.

QA and validation

Prove process requirements and acceptance criteria coverage with executable tests, test runs, and evidence.

They get a living coverage model instead of a spreadsheet rebuilt at the end of the validation effort.

Acceptance criteria map to test cases and test runs.
Manual and automated tests share trace links.
TPO/TCF workflows preserve protocol identity and versions.

Quality, compliance, and auditors

Review traceability, risk controls, approvals, and evidence without chasing teams.

They get audit-ready proof that is continuously built as the validated process evolves.

Requirement lifecycle states are explicit.
Risk, verification, and compliance matrix entries are linked.
Exports and protocol documents are generated from source data.

Release and operations managers

Connect releases, process changes, pull requests, commits, test runs, and deployment evidence.

They get a cleaner answer to what changed, why it changed, and how it was validated.

GitHub/Jira/Azure DevOps links stay attached to SDD items.
Commit impact can be analyzed by service boundary.
Release evidence remains tied to test protocols.

Support and operations

Turn process findings, production findings, or user feedback into traceable issues and change requests.

They get problems linked back to the original demand and forward to the fix and validation evidence.

Issues can reference impacted requirements and specifications.
Found issues from test runs stay linked to evidence.
Follow-up changes keep history instead of overwriting intent.

Academy

Training programs

SDD courses are sold through Academy.roggemans.com and can be delivered as public classes, private workshops, or guided rollout sessions.

Foundation

SDD Basics

1 day

Understand the validated-process memory model.

A practical introduction for decision makers, analysts, QA, and project leads who need to understand how SDD connects intent, requirements, risks, tests, and evidence.

Audience: Management, PMO, product owners, business analysts, QA leads, validation leads
Delivery: Live remote or private workshop
Booking: On request

Next session

SDD Basics - September remote class

2026-09-10 - Remote

Explain the SDD validated-process chain from intent to evidence.Identify where requirements, risks, protocols, and tests are connected.

View on Academy

Practitioner

SDD Development

2 days

Implement controlled changes from requirements.

A developer and architect course focused on SolveRequirement, SolveSpecification, issue linkage, implementation traceability, and tests connected to requirements.

Audience: Developers, architects, technical leads, AI implementation agents
Delivery: Live remote, private workshop, or team coaching
Booking: On request

Next session

SDD Development - September practitioner class

2026-09-17 - Remote

Prepare implementation from approved requirement and specification context.Connect issues, commits, tests, and completion comments to SDD records.

View on Academy

Practitioner

SDD QA and Validation

2 days

Build evidence while validation work happens.

A QA and validation course covering acceptance coverage, manual and automated tests, Test Protocols, execution sessions, comments, risks, and exportable evidence.

Audience: QA engineers, validation engineers, quality managers, auditors
Delivery: Live remote or private validation workshop
Booking: On request

Next session

SDD QA and Validation - October class

2026-10-01 - Remote

Connect requirements and risks to test suites, cases, and execution sessions.Manage Test Protocol versions and execution evidence.

View on Academy

Advanced

SDD MCP and Automation

1 day

Operate SDD through structured agent tools.

A technical course for teams that want to use SDD MCP tools, APIs, automation hooks, and agent workflows without direct database access.

Audience: Automation engineers, platform owners, architects, technical leads
Delivery: Live remote or private technical workshop
Booking: On request

Next session

SDD MCP and Automation - October technical class

2026-10-08 - Remote

Use MCP tools to list, inspect, and operate SDD project artifacts.Design API-backed operations that avoid direct SQL access.

View on Academy

Leadership

SDD Enterprise Rollout

1 day

Deploy SDD as a validated-process operating model.

A strategy and governance course for organizations preparing SDD adoption across projects, products, quality, validation, and operations.

Audience: Executives, PMO, quality leadership, process owners, platform owners
Delivery: Private workshop
Booking: On request

Next session

SDD Enterprise Rollout - private workshop

2026-11-05 - Private

Define the SDD adoption roadmap and governance model.Identify integration points with existing project, validation, and quality tools.

View on Academy

Schema content

Solution stories

These are the detailed sales-page slides: who acts, what the SDD agent uses, what data is touched, and what proof comes out.

Requirements control

Requirements consistency and redundancy review

Agent-assisted

Actor

Requirements engineer or QA reviewer

The project already has requirements in Polarion, Jira, or SDD and the team needs to know whether they conflict, repeat each other, or miss context.

SDD agent action

Ask the SDD agent to review a document, module, requirement set, or project scope.

The agent uses SDD lookup, project context search, Polarion/Jira links, best practices, and LLM reasoning to detect contradictions, duplicates, gaps, and unclear acceptance intent.

Data and context

Project memory

Requirements, specifications, issues, project knowledge, Polarion references, and knowledge-base documents.

Outcome

A structured review with suggested corrections, affected items, rationale, and links back to the source requirements.

Linked requirement IDs, review comments, change-request rationale, and updated lifecycle status.

WIIFM

Reviewers move from manual reading to targeted decisions: accept the suggestion, update the source requirement, or open a controlled change request.

Sales proof line

REQ-CONSISTENCY: Linked requirement IDs, review comments, change-request rationale, and updated lifecycle status.

Discovery

Intent to clear requirement

Available

Actor

Product owner, SME, or business analyst

The business expresses a need as a conversation, note, or rough intent that is not yet precise enough for controlled execution.

SDD agent action

Capture the intent through dictation, text, or an MCP add_intent flow.

SDD retrieves project context, existing requirements, related specifications, terminology, and templates, then proposes a clear requirement with rationale and acceptance direction.

Data and context

Project memory

Dictation transcript, existing work items, knowledge-base files, project templates, and requirement analysis prompts.

Outcome

A reviewable requirement draft, duplicate warnings, parent/child suggestions, and candidate specifications or issues when useful.

Requirement draft, source transcript, duplicate references, lifecycle status, and related specifications.

WIIFM

Business people keep their intent, while engineering receives a requirement that is specific enough to approve and implement.

Sales proof line

INTENT-TO-REQ: Requirement draft, source transcript, duplicate references, lifecycle status, and related specifications.

Analysis and specification

Requirement to specification and acceptance criteria

Available

Actor

Business analyst, architect, developer lead, or QA lead

An approved business requirement needs technical clarity, acceptance criteria, and implementation boundaries.

SDD agent action

Run SolveRequirement or generate specification context from the selected requirement.

SDD analyzes the requirement, searches project memory, applies prompt templates, and creates specifications with acceptance criteria that remain linked to the requirement.

Data and context

Project memory

Requirement details, prior specifications, issues, best practices, architecture files, and acceptance criteria templates.

Outcome

Linked specifications, acceptance criteria, and issue creation prompts that can feed planning or agent execution.

Requirement -> specification -> acceptance criteria links, author, assignment, and review validation.

WIIFM

The team gets a shared contract for what must be built and how it will be accepted.

Sales proof line

REQ-TO-SPEC: Requirement -> specification -> acceptance criteria links, author, assignment, and review validation.

Planning

Specification to backlog and execution plan

Available

Actor

Project manager, product owner, tech lead, or scrum master

A specification is understood, but the work is not yet split into executable issues or aligned with toolchain items.

SDD agent action

Generate or link issues from the specification and sync external issue references.

SDD creates issue candidates, links them to the specification, preserves Jira/GitHub metadata, and keeps board state visible.

Data and context

Project memory

Specifications, acceptance criteria, Jira items, GitHub issues, feature links, and project review policy.

Outcome

A Kanban-ready issue set with traceability back to the specification and requirement.

Specification -> issue links, status history, external keys, and review validations.

WIIFM

Planning becomes a controlled decomposition exercise instead of a disconnected ticket-writing session.

Sales proof line

SPEC-TO-BACKLOG: Specification -> issue links, status history, external keys, and review validations.

Implementation

Controlled implementation and change execution

Available

Actor

Engineer, implementer, AI agent, or technical lead

A team member or AI agent needs to change code, configuration, procedure content, or validation artifacts without losing business context, approval state, or test obligations.

SDD agent action

Invoke the appropriate Solve* command from SDD-aware tooling.

SDD resolves the item, checks approval and assignment rules, searches context, pulls best practices, guides implementation, requires linked tests, and records traceable comments or commits.

Data and context

Project memory

Requirements, specifications, issues, approval status, project commit options, search context, best practices, linked tests, and Git metadata.

Outcome

A controlled change that ends in review with SDD references, linked tests, and a summary tied to the business demand.

Commits, pull request links, issue comments, test cases, test runs, and SDD reference IDs.

WIIFM

Implementation teams get the why, agents get guardrails, and reviewers get proof that the change maps to the approved intent.

Sales proof line

SOLVE-WORK: Commits, pull request links, issue comments, test cases, test runs, and SDD reference IDs.

QA and validation

Acceptance criteria coverage and test execution

Available

Actor

QA engineer, tester, validation lead, or automation engineer

The team must prove that each acceptance criterion is covered by manual or automated tests and execution evidence.

SDD agent action

Create test cases from requirements/specifications, import scanned automated tests, or execute test runs.

SDD maintains test suites, cases, steps, trace links, xUnit scan results, test runs, evidence, deviations, and found-issue links.

Data and context

Project memory

Acceptance criteria, requirements, risks, specifications, xUnit source metadata, test protocols, and run evidence.

Outcome

A coverage model showing what is tested, what is missing, what passed, and which issues were found.

Test trace links, test case versions, run results, step evidence, and issue links.

WIIFM

QA works from live traceability instead of rebuilding a matrix after implementation.

Sales proof line

QA-COVERAGE: Test trace links, test case versions, run results, step evidence, and issue links.

Regulated validation

TPO/TCF, risk, and compliance package generation

Available

Actor

Validation engineer, quality manager, compliance owner, or auditor

A regulated project needs test protocols, risk controls, versioned validation documents, and auditable exports.

SDD agent action

Import or derive TCF/TPO content, link protocol parts, execute sessions, and export documents.

SDD normalizes source document identity, preserves TPO versions, links suites and cases, captures execution sessions, and connects risk/control/compliance rows to process artifacts.

Data and context

Project memory

TCF workbooks, TPO metadata, releases, test suites, test cases, risk rows, compliance matrix entries, and evidence.

Outcome

Versioned protocols, execution records, exclusions, risk-control links, and export-ready evidence.

TPO/TCF versions, generated RTF/DOCX/PDF, execution sessions, approval participants, and compliance matrix rows.

WIIFM

Validation and quality teams keep regulated proof synchronized with the actual project state.

Sales proof line

TPO-COMPLIANCE: TPO/TCF versions, generated RTF/DOCX/PDF, execution sessions, approval participants, and compliance matrix rows.

Portfolio control

Governance, change control, and audit readiness

Available

Actor

Management, PMO, quality, security, and auditors

As the validated process evolves, leadership needs proof of who approved what, why it changed, what was affected, and whether execution remains controlled.

SDD agent action

Use review policy, role assignments, change requests, external reviewer flows, audit events, baselines, and traceability exports.

SDD records lifecycle states, validations, role assignment audits, subscription/workspace events, change-request reasons, and linked artifacts across the validated process chain.

Data and context

Project memory

Roles, review validations, requirement history, change requests, audit events, Git links, tests, releases, and compliance data.

Outcome

A defensible history of decisions and evidence from initial demand through release and verification.

Audit events, review validations, lifecycle history, change requests, release evidence, and traceability exports.

WIIFM

Management gets governance without asking every department to maintain a separate status spreadsheet.

Sales proof line

GOVERNANCE-AUDIT: Audit events, review validations, lifecycle history, change requests, release evidence, and traceability exports.

Field examples

Schematic use cases

Three practical ways SDD connects enterprise sources, requirement cycles, and controlled execution actions.

Polarion

SDD Mirror

Specs and Tests

Evidence

Enterprise mirror

Polarion Mirror Integration

Mirror Polarion requirements into SDD so regulated teams can keep the enterprise source while creating controlled specifications, tests, and proof in the validation workspace.

Import and reconcile Polarion work items with SDD requirements.
Preserve external references while adding SDD traceability.
Use mirrored context for specification, acceptance criteria, and protocol generation.

View Enterprise Mirror

Intent

Requirement Review

Criteria and Tests

Feedback Loop

Lifecycle control

Requirement Cycle Improvement

Improve the requirement cycle by connecting intent, review, specification, acceptance criteria, tests, and execution evidence instead of managing each step as a separate document activity.

Detect gaps, ambiguity, and missing acceptance coverage earlier.
Create specifications and acceptance criteria from approved requirements.
Feed findings back into controlled change and review loops.

Console Action

SDD Context

Controlled Change

Traceable Output

Agent execution

Actions in Console

Run controlled SDD actions from the console so AI-assisted implementation, traceability updates, and validation work stay attached to the project model.

Execute SDD-aware commands from the same operational context.
Keep agent work linked to requirements, specifications, issues, and tests.
Capture action output as traceable project evidence.

SRP use cases

Full use-case catalog by validated-process phase

Each card is intentionally narrow: one phase, one problem, one SDD fix, one proof chain.

1. Strategy and governance

Create the control model before execution accelerates.

Project memory bootstrap

Available

Management, architects, implementation teams

Problem: New AI sessions start without context.
SDD fix: SDD ingests repository and project knowledge through InitSDD/BootstrapSDD patterns.
WIIFM: Every contributor and agent starts from the same project memory.

AGENTS.mdArchitecture docsProject context

Process contracts and sub-project governance

Available

PMO, architects, process owners

Problem: Large validated projects lose ownership boundaries.
SDD fix: SDD models sub-projects and process/development contracts with scope, risks, obligations, and audit entries.
WIIFM: Managers can assign accountability without hiding technical detail.

Sub-projectsContractsAudit entries

Role and review policy enforcement

Available

Quality, PMO, auditors

Problem: Review gates are informal or inconsistent.
SDD fix: SDD applies project review requirements for requirements, specifications, and issues.
WIIFM: Approvals become explicit and measurable.

Review policyValidationsWorkspace roles

Audit-ready decision history

Available

Auditors, quality, management

Problem: Decision proof is scattered across tools.
SDD fix: SDD records lifecycle states, role changes, audit events, comments, and linked artifacts.
WIIFM: Audits become evidence review, not archaeology.

Audit eventsStatus historyComments

2. Discovery and intent

Convert informal demand into structured, reviewable requirements.

Intent capture from conversation

Available

Product owners, SMEs, analysts

Problem: Business intent is trapped in meetings and notes.
SDD fix: SDD uses dictation/transcription and intent analysis to extract work items.
WIIFM: Business input becomes structured project data.

TranscriptRequirement draftAnalysis result

Duplicate and redundancy detection

Agent-assisted

Business analysts, QA

Problem: Multiple teams describe the same need differently.
SDD fix: SDD compares new intent against existing requirements/specifications/issues and project knowledge.
WIIFM: Teams avoid parallel requirements that later conflict.

Context searchRelated itemsSuggestion list

Requirement clarification with project context

Available

Analysts, architects

Problem: A requirement is too vague to implement.
SDD fix: SDD pulls relevant project context and templates before proposing clearer wording.
WIIFM: The requirement becomes specific without losing domain context.

Prompt templateKnowledge searchRequirement update

Requirement hierarchy modeling

Available

Product owners, PMO

Problem: High-level needs and detailed requirements are not connected.
SDD fix: SDD supports parent/child requirement links with lifecycle-aware change reasons.
WIIFM: Scope can be reviewed at both business and implementation levels.

Parent linkChild requirementsChange reason

3. Requirements and specification

Make requirements implementable and testable.

Requirement lifecycle control

Available

Quality, analysts, implementation teams

Problem: Work starts before approval is clear.
SDD fix: SDD tracks Draft, Approved, Implemented, and Verified states and solve flows enforce approval policies.
WIIFM: Teams stop executing against unapproved demand.

Lifecycle stateApproval metadataSolve gate

Polarion and Jira import alignment

Available

Requirements engineers, PMO

Problem: External systems contain authoritative items but engineering work happens elsewhere.
SDD fix: SDD stores external keys, Polarion references, Jira metadata, and import configuration.
WIIFM: Source systems remain connected to controlled execution.

External keysPolarion refsJira metadata

Specification generation from requirements

Available

Architects, implementation teams

Problem: Approved requirements still need technical detail.
SDD fix: SDD generates or stores specifications linked to the requirement and project context.
WIIFM: Implementation teams receive a clear design contract.

SpecificationRequirement linkAssignment

Acceptance criteria coverage model

Available

QA, product owners

Problem: Acceptance criteria are written but not proven.
SDD fix: SDD links criteria to issues, test cases, and execution evidence.
WIIFM: Acceptance stops being a paragraph and becomes a verifiable chain.

Acceptance criteriaTest linksCoverage view

4. Planning and controlled execution

Turn specifications into controlled work, process updates, and traceable implementation changes.

Backlog decomposition

Available

PMs, scrum masters, tech leads

Problem: Specifications are not split into executable work.
SDD fix: SDD creates and links issues under specifications and requirements.
WIIFM: Backlog items have a reason, owner, and source.

IssuesSpec linksKanban board

Toolchain issue linking

Available

Implementation teams, PMO, DevOps

Problem: Jira/GitHub/Azure DevOps work items drift from SDD context.
SDD fix: SDD preserves external system IDs, keys, status, priority, and issue links.
WIIFM: Teams can use existing tools without losing traceability.

Jira itemGitHub issueExternal status

AI-guided Solve* execution

Available

Implementation teams, AI agents

Problem: AI-assisted changes can ignore project policy or context.
SDD fix: SolveRequirement, SolveSpecification, SolveIssue, and SolveExecution load context and enforce solve rules.
WIIFM: AI implementation becomes reviewable controlled work.

Solve commandBest practicesCompletion comment

Commit and service impact traceability

Available

Developers, release managers

Problem: Software changes are hard to map back to demand and impacted services.
SDD fix: SDD stores Git repositories, commits, issue links, and service impact analysis.
WIIFM: Release review can answer what changed and why.

Commit linkIssue referenceImpact report

5. QA, testing, and validation

Build proof continuously while the process is executed.

Test case creation from acceptance intent

Available

QA, analysts

Problem: Tests are created late and miss acceptance intent.
SDD fix: SDD creates test suites and cases linked to requirements, specifications, issues, and risks.
WIIFM: QA starts from business intent instead of reverse-engineering the implementation.

Test suiteTest caseTrace link

Automated test discovery

Available

QA automation, implementation teams

Problem: Automated tests exist but are not traceable.
SDD fix: SDD scans/imports tests, patches SDD test IDs, and fingerprints methods.
WIIFM: Automated coverage becomes visible in the same matrix as manual tests.

xUnit metadataSDDTestIdMethod hash

Evidence-based test runs

Available

Testers, validation leads

Problem: Execution proof is separated from test design.
SDD fix: SDD captures step results, evidence, deviations, approvals, and found issues.
WIIFM: Validation evidence is collected as work happens.

Run resultStep evidenceFound issue

TPO/TCF protocol control

Available

Validation, quality

Problem: Protocol documents and project test cases diverge.
SDD fix: SDD imports, generates, versions, links, executes, and exports TPO/TCF content.
WIIFM: Protocol evidence remains synchronized with the source project.

TPOTCFExecution session

6. Compliance, risk, and release

Connect controls, releases, and audit evidence.

Risk and control matrix

Available

Quality, safety, validation

Problem: Risks and mitigations are not connected to implementation proof.
SDD fix: SDD models risks, risk-control measures, VMX rows, and trace links.
WIIFM: Risk review can follow the chain into tests and evidence.

RiskControl measureVMX row

Compliance pack traceability

Available

Compliance owners, auditors

Problem: Standards evidence is rebuilt manually.
SDD fix: SDD links clauses to requirements, specifications, issues, design, tests, hazard analysis, and verification.
WIIFM: Compliance artifacts become live project views.

ClauseMatrix entryVerification record

External reviewer workflow

Available

Auditors, customers, quality

Problem: External review requires unsafe data sharing or screenshots.
SDD fix: SDD supports scoped reviewer invitations and events.
WIIFM: External parties can review the right evidence with a controlled boundary.

InvitationScopeReviewer events

Release evidence and exports

Available

Release managers, quality

Problem: Release readiness depends on scattered proof.
SDD fix: SDD connects releases, test runs, generated protocols, traceability exports, and issue links.
WIIFM: Release decisions are based on linked evidence.

ReleaseExportTraceability

7. Continuous improvement and operations

Keep learning loops connected to the original business demand.

Issue triage from test or production findings

Available

Support, QA, implementation teams

Problem: Defects are reported without requirement context.
SDD fix: SDD links found issues to test runs and affected requirements/specifications.
WIIFM: Fixes remain connected to the business expectation they violated.

Found issueRun linkAffected spec

Change request workflow

Available

Product owners, quality, PMO

Problem: Late changes overwrite history.
SDD fix: SDD records change requests and lifecycle-aware reasons for controlled edits.
WIIFM: Teams can evolve scope without destroying the audit trail.

Change requestReasonStatus

Best-practice memory and prompt versioning

Available

Architects, tech leads

Problem: Lessons learned stay in individual heads.
SDD fix: SDD stores searchable best practices and can publish improved prompt versions with lineage.
WIIFM: Agents and teams reuse the best known way to solve similar work.

Best practiceVersionLineage

Sandbox and enterprise rollout controls

Available

IT, security, platform teams

Problem: Testing automation can affect production data or ignore enterprise boundaries.
SDD fix: SDD supports sandbox isolation, plan entitlements, API access, and corporate deployment options.
WIIFM: The platform can scale from trial to controlled enterprise adoption.

Sandbox scopeEntitlementsIsolated VM

SDD pricing

Pricing & plans

Trial starts at signup for 7 days. Choose self-serve Starter, Professional, or Premium. Corporate uses quote workflow.

Capability	Trial (7 days) Included	Starter 15 EUR/mo	Professional 59 EUR/mo	Premium 149 EUR/mo	Corporate Custom
Max users	1	2	10	25	10000
Max projects	1	2	Unlimited	Unlimited	Unlimited
AI credits / month	10	50	300	1500	5000
Jira import	Yes	Yes	Yes	Yes	Yes
xUnit scan	No	No	Yes	Yes	Yes
Compliance packs (standards & norms)	Yes / Yes / Yes	No / No / No	Yes / No / No	Yes / Yes / Yes	Yes / Yes / Yes
API + Webhooks	No	No	No	Yes	Yes
Corporate isolated VM	No	No	No	No	Yes

Trial

7 days, 1 user, 1 project, baseline requirements/specifications and basic traceability.

Starter

15 EUR/month, 2 users, 2 projects, PDF export, and limited monthly AI credits.

Corporate

Isolated VM, dedicated DB options, SSO/Entra and procurement-ready rollout.

FAQ

When does trial lock? After day 7, write actions are locked until upgrade.

How fast does access update after purchase? Webhook updates apply subscription changes within minutes.

Need isolated hosting? Use the corporate quote flow.