Feature LogicSystem ArchitectureGovernance & RulesDDM

  •  

    Definitive

  • Definitive

    Specification

  • Specification

    Data Model

  • Data Model

     

DefinitiveSpec provides a comprehensive set of artifacts to model every aspect of your system. This toolkit is the foundation of our AI-native methodology, transforming precise specifications into high-quality, verified software.

↓ Scroll to explore the system

The Core

Part 1

Implementing a Feature

At the heart of any system is the feature. Definitive Development Methodology provides a tight loop of artifacts to define, implement, and verify this core logic with absolute clarity.

requirement: Defines the Goal

The "Why"

To capture the business need and acceptance criteria, providing a clear goal and a direct link from intent to implementation.

dspec
requirement UserRegistration {
title: "New User Account Registration";
rationale: "Acquiring new customers is essential...";
}
model: Shapes the Data

The Data

To define the precise shape and rules of your data, from API payloads to database entities, ensuring type-safety and validation across the system.

dspec
model UserRegistrationPayload {
email: String { format: "email", required: true };
password: String { minLength: 10 };
}
code: Details the Logic

The Logic

To detail the step-by-step business logic in an abstract, readable way. This is the single source of truth for implementation.

dspec
code HandleUserRegistration {
implements_api: apis.RegisterUser;
detailed_behavior: `
DECLARE user = CALL GetUserByEmail...
IF user IS_PRESENT THEN
RETURN_ERROR EmailAlreadyInUse;
END_IF
PERSIST new_user...
`;
}
test: Provides the Proof

The Proof

To guarantee correctness by explicitly linking test cases to the requirements, APIs, or code they verify, enabling automated test generation and gap analysis.

dspec
test UserRegistration_DuplicateEmail {
verifies_code: [code.HandleUserRegistration];
expected_result: "System returns a 409 Conflict error.";
}

The Structure

Part 2

Architecting the System

Features don't live in isolation. You need to define how they fit into the bigger picture. These artifacts build the architectural blueprint and model how components interact.

design: The Components

Defines the high-level responsibilities of services

The Blueprint

To define the high-level components of your system, their responsibilities, and how they relate to one another, creating a clear architectural overview.

dspec
design AuthenticationService {
responsibilities: [
"Validate user credentials",
"Issue and verify JWTs"
];
dependencies: [ design.UserDataStore ];
}
api: The Contracts

Specifies how components talk to each other

The Contract

To define an unambiguous, technology-agnostic contract for how your system's services communicate.

dspec
api RegisterUser {
path: "/v1/users/register";
method: "POST";
request_model: models.UserRegistrationPayload;
}
interaction: The Choreography

Models the sequence of communication between components

Choreographing Components

To model how multiple components (design artifacts) collaborate in a sequence to fulfill a larger use case, like a sequence diagram in code. Perfect for simulating and debugging complex flows.

dspec
interaction UserLoginFlow {
components: [ design.ApiGateway, design.AuthService ];
step LoginRequest {
component: design.ApiGateway;
action: "Receives POST /login";
next_step: ValidateCredentials;
}
...
}
behavior: The Lifecycle

The internal state and transitions of complex components

Defining State & Transitions

To model a component's lifecycle using a formal state machine (fsm). Essential for objects with complex states, like an Order (e.g., PENDING -> PAID -> SHIPPED).

dspec
behavior OrderLifecycle {
fsm OrderFSM {
initial: PENDING;
state PENDING { ... }
state PAID { ... }
transition { from: PENDING, to: PAID, event: "PaymentSuccess" }
}
}
event: The Announcements

Decouples components through asynchronous messages

Announcing What Happened

To define significant occurrences in your system. It's the foundation of event-driven architectures, decoupling components and enabling reactive workflows.

dspec
event UserRegistered {
description: "Fired after a new user successfully registers.";
payload_model: models.NewUserInfo;
}

The Governance

Part 3

Enforcing the Rules

A robust system needs rules that apply everywhere. These artifacts allow you to define system-wide policies, terminology, and most importantly how the AI agent should behave. This is how you achieve consistency at scale.

policy: Enforcing System-Wide Rules

Centralizes rules for errors

Enforcing System-Wide Rules

To centralize cross-cutting concerns. Instead of every developer re-inventing error handling, you define it once in a policy for the agent to enforce everywhere.

dspec
policy GlobalErrorPolicy {
error_catalog DefaultErrors {
define ValidationFailed { http_status: 400; ... }
}
}
nfr: Defining Quality

Non-Functional Requirements as a formal part

Defining Quality

To make Non-Functional Requirements (like performance or security) a formal, verifiable part of your spec.

dspec
policy StandardPerformanceNFRs {
nfr HighVolumeReadPath {
statement: "APIs tagged 'HighVolume' must respond in < 100ms at p95.";
applies_to: [ api.GetProductCatalog ];
}
}
infra: The Environment

Specifies configuration and deployment details

Specifying the Environment

To connect your application to its runtime world. Define environment variables, feature flags, and deployment settings, keeping configuration separate from logic.

dspec
infra ProductionEnvironment {
configuration AppConfig {
STRIPE_API_KEY: String { sensitive: true };
ENABLE_NEW_CHECKOUT: Boolean { default: false };
}
}
glossary: The Dictionary

Creates a shared understanding of terms

The Shared Dictionary

To eliminate ambiguity by creating a single source of truth for business and technical terminology. When a kpi mentions "Monthly Recurring Revenue", its definition is here.

dspec
glossary BusinessMetrics {
term "MRR" {
definition: "Monthly Recurring Revenue is the predictable...";
}
}
directive: The AI's Brain

You program the agent by defining patterns to translate abstract logic into concrete code. This is your control panel.

The Agent's "Cookbook"

This is the most powerful concept. It's where you **program the AI agent**, teaching it how to translate abstract keywords from your code specs (like PERSIST) into your specific tech stack's code. **You are in full control of the output.**

dspec
directive PrimeCart_TS_Agent_v3.2 {
target_tool: "TypeScript/TypeORM";
// Defines how 'PERSIST' is implemented
pattern PERSIST(entity, store) -> {
template: "await this.{{store | to_repo}}.save({{entity}});"{store | to_repo}}.save({{entity}}{entity}});";
}
}

The Metrics

Part 4

Measuring What Matters

Business value is the ultimate test of any system. KPIs connect your technical architecture to business outcomes, enabling powerful what-if analysis and data-driven decision making.

kpi: Business Intelligence

The Measure of Business Value

The Value

Instead of just saying "improve checkout," you define it with absolute clarity. The agent understands this spec as a core system objective.

dspec
kpi CheckoutConversionRate {
title: "Checkout Funnel Conversion Rate";
description: "The percentage of users who start a checkout and complete an order.";
// The agent understands this formula and its dependencies.
metric_formula: "(count(events.OrderCompleted) / count(events.CheckoutStarted)) * 100"(events.OrderCompleted) / count(events.CheckoutStarted)) * 100";
// A clear, verifiable target for success.
target: "> 65%";
// Directly links the business goal to the technical implementation.
related_specs: [ interaction.CheckoutFlow ];
}

✨ What-If Analysis

Because the agent understands the link between requirements, code, and KPIs, it can run a virtual simulation to predict the future. This creates a feedback loop between business strategy and technical implementation.

Before you write a line of code for a new feature, you can ask:

- "What is the projected impact of requirement.AddNewPaymentMethod on kpi.CheckoutConversionRate?"

The agent analyzes the proposed changes, simulates user flows, and provides a data-driven forecast, turning strategic planning from guesswork into a science.

The Cycle of Certainty:

Operating System
for Development

DefinitiveSpec isn't just a set of files; it's a rigorous, iterative process. This closed-loop system ensures that every piece of specification is traceable to a validated requirement, eliminating drift and ambiguity.

Define & Specify

From an Idea to a Blueprint

You begin by capturing business intent as a requirement and defining success with a kpi. Then, you create the architectural blueprint: the models,apis, and abstract code logic. This is the single source of truth.

Validate & Simulate

Find Flaws Before You Code

This is our crucial pre-flight check. The agent validates every spec for correctness and integrity. Here, you can run "What-If" analyses on KPIs or simulate complexinteractions to prove your design is sound before committing to implementation.

Generate & Verify

Automated, Consistent Implementation

With a validated blueprint, the agent acts as an automated builder. It translates yourcode specs into production-ready code, strictly adhering to the directive patterns your team has defined.

The Feedback Loop

The Golden Rule of DefinitiveSpec

The Spec is Truth. Always. If testing or a new insight reveals a flaw, you don't patch the code. You update the specification. This triggers the cycle again, ensuring your documentation and implementation are never out of sync.

Not a Chatbot

A Compiler
for Specifications

Our agent is not a creative co-pilot; it's a disciplined executor.It's a new kind of tool — a computer within an LLM, that takes natural language requirements and raw ideas as input and produces precise specifications as output.You ready to start writing high-quality code.

Bound by Protocol

Strict, Non-Negotiable Rules

The agent follows strict, non-negotiable rules. TheDDM-RULE-XXX protocol, likeDDM-RULE-001: SpecIsTruth, is hard-coded into its operation. It cannot add logic that isn't in the spec. It cannot ignore a policy. This ensures its behavior is predictable and aligned with your standards.

A Formal Command Interface

Clear Commands, Not Conversation

You interact with the agent like any other developer tool. It responds to clear commands, not vague conversation. You issue tasks like DSpec: Implement Code Spec orDSpec: Run Simulation. It requires specific inputs (the .dspec files) and produces structured outputs (code, analysis reports). It has an API, not a personality.

Human-Governed & Verifiable

You Program the Agent

Thedirective patterns that translate specs into code are your team's "cookbook." They are managed by your architects and governed by a formal process. We are so serious about this that we even have test specs for the agent itself, ensuring it complies with its own rules.

Download
Agent Manual
Methodology
Discord