Software that remembers what it’s supposed to be.
AI is transforming how quickly we build software. Agents can write code, design systems, investigate problems, and collaborate across entire projects.
Who remembers what we’re building, why it works this way, and what must remain true as it evolves?
Today, that understanding is scattered across tickets, code, documentation, tests, and conversations. Much of it lives in the memories of developers — or the temporary context of AI agents.
When people change, agents restart, or projects grow, that understanding must be reconstructed.
Identity-Driven Development (IDD) changes where that knowledge lives.
Instead of relying on whoever is doing the work, IDD gives the product itself a persistent identity — connecting its purpose, behavior, architecture, implementation, and verification throughout its lifetime.
The meaning survives the implementation.
Every meaningful part of a product has a purpose. A feature, capability, configuration, or workflow exists to fulfill some expectation.
IDD gives these product concepts durable identities that remain consistent as the software changes. Their definitions connect to the code that implements them, the architecture that supports them, the tests that verify them, and the work that shapes their evolution.
A ticket closes. An agent finishes its session. An implementation gets replaced. The product’s identity remains.
New developers and agents can discover what something is, why it exists, how it works, and what has actually been verified — without reconstructing its entire history.
One connected understanding. Many sources of truth.
At the heart of IDD is the Product Identity Spine — a connected structure relating everything that defines, implements, and evolves a product. It brings together:
These aren’t sequential stages. They’re relationships surrounding the same persistent product identities.
And IDD doesn’t replace existing development tools.
Still owns code history.
Still verify behavior.
Still record releases.
Still organize work.
The spine connects these systems without duplicating their authority.
The result is a product whose meaning can be discovered and understood across tools, teams, and AI agents.
What should happen isn’t necessarily what is happening.
IDD makes an important distinction between four different kinds of product knowledge.
What do we promise? The behaviors and expectations the product is designed to fulfill.
What did we configure? The settings and decisions that determine how the product should operate.
What is happening? The actual condition of a system, capability, or environment.
Why do we believe it works? Tests, observations, and verification records supporting specific claims.
A feature can be defined but not implemented. Implemented but not enabled. Enabled but not working. A passing test doesn’t necessarily mean production behaves correctly.
IDD preserves these distinctions, making it clear what we know, what we’ve verified, and what remains uncertain.
Agents shouldn’t have to rediscover the product every time they work.
AI agents are becoming increasingly capable, but they still face a fundamental continuity problem.
Each agent needs to understand the project, its architecture, its requirements, and the consequences of its changes. Giving agents longer memories or larger context windows helps, but doesn’t solve the underlying problem.
The product needs its own durable source of understanding.
With IDD, agents and developers work against the same identified product concepts and expectations. They can discover relevant definitions, understand relationships, trace changes, and connect their work back to the product’s intended behavior.
Different agents. Different models. Different development tools.
One shared understanding of the product.
The methodology doesn’t dictate how agents reason or which tools developers use. It provides the persistent structure that keeps their work connected.
Not just a philosophy. A working development practice.
A portable methodology pack that installs into software projects.
Structure and practices for defining product identities, connecting promises to implementation, and keeping traceability across development.
Works alongside existing repositories, tools, and workflows — for human developers and AI-powered engineering environments.
At Alchemize, IDD isn’t simply something we recommend.
We use it to build our own platform, and we bring it into the software projects we develop.
The Alchemize Platform is built using IDD, serves as a proving ground for the methodology, and provides tools that integrate directly with IDD-enabled projects.
Through its Product Catalog, identified promises, verification mappings, and connected work records, the platform makes product identity accessible and actionable for developers and agents.
The methodology stands independently. The platform extends what you can do with it.
As both evolve, we continue to strengthen the connections between product intent, implementation, verification, and runtime behavior.
Software should outlive the context that created it.
Software engineering has always been about more than writing code. It’s about creating systems that can be understood, maintained, and evolved long after their original developers have moved on.
AI dramatically accelerates that process — and makes preserving product understanding even more important.
Identity-Driven Development brings that continuity into the development process itself.
Not as another document to maintain. Not as a memory an agent might retrieve. But as persistent, connected product identities that remain meaningful across people, tools, implementations, and time.
The product’s identity lives in durable, connected records, so continuity doesn’t depend on whoever happens to be doing the work.
Built by Alchemize. Practiced in our projects. Integrated with our platform.
Explore how we’re bringing persistent product identity into AI-powered software development.