Governance

The manifesto loses value if it is confined to an opening presentation. It must appear at the moments when the team makes decisions: definition, design, generation, review and post-launch learning.

Responsibilities

Responsible	Main obligation
Product	Establishes the authorized definition, the scope, the results, the rules, the non-goals and the evidence of success; validates Jobs to Be Done and Job Stories where they are used.
Design	Translates the product foundation into journeys coherent with the person's mental model and protects their attention; uses Job Stories where they help make the situation concrete.
Engineering	Absorbs complexity and guarantees states, performance, accessibility and recovery.
AI agent	Plans and implements within the foundation and the contract; declares assumptions, maintains coverage and neither reduces nor extends scope on its own initiative.
Human review	Evaluates causality, meaning, risk, the complete experience and the evidence; it is not limited to reviewing code.

Control points

Moment	Decision required
Before designing	Sources, authority, scope, results, evidence, assumptions and non-goals are clear; the Job Stories are understood where they exist.
Before generating code	The plan covers the complete definition and establishes dependencies, chosen response, routes, states, critical rules, risks and acceptance.
During construction	The breakdown organizes the work without altering the scope; blockers, outstanding items and exceptions remain visible.
Before integrating	Every change preserves traceability to its foundation, respects scope, covers states and passes technical tests.
Before release	The complete implementation demonstrates results, coverage, understanding, control and quality of experience.
After release	Outcome, friction, abandonment and errors are observed; the foundation, the stories and their assumptions are revisited where appropriate.

The principles must be stable; the rules and tests may evolve with new evidence. Every change should record the problem observed, the decision modified and the reason. The framework must not grow by accumulation: a new rule is only incorporated if it resolves a gap the existing ones do not cover.

Change control for versions 2.0 and 2.1

Version 1.0 remains as the founding formulation. Version 2.0 preserves its thesis and its ten principles, but replaces generic operational references to Jobs to Be Done with a more concrete and verifiable chain.

Area	Adjustment in version 2.0	Content that remains
Unit of design	The Job Story makes progress concrete within a job defined through Jobs to Be Done.	The user's progress remains the principal measure.
Architecture	A level is added between principle and rule.	Principles, rules and tests keep their function.
Flow and artifacts	Circumstance, motivation, outcome and evidence are required before designing.	The minimum documentation that changes decisions is retained.
Development with AI	The agent must reformulate and respect the Job Story.	Limits, determinism and human review continue.
Acceptance	The outcome is tested under the circumstance described.	Accessibility, performance, states and control remain mandatory.
Example and governance	Causal traceability and validation of stories are added.	The calculus tutor and the control points keep their purpose.

Version 2.1 preserves the thesis, the ten principles, the doctrine for AI, the Job Stories and the worked example. It extends the core to accommodate product definitions of differing form, length and depth, without imposing a structure upstream or assuming an incremental strategy.

Area	Adjustment in version 2.1	Content that remains
Foundation	An authorized, traceable and verifiable base is defined, which may take different forms.	Human progress continues as the principal measure.
Job Stories	They are declared a reference form, not a universally mandatory structure.	Their canonical form, evidence, tests and examples are preserved.
Scope	Full coverage is required and unauthorized omissions or deferrals are prohibited.	Product continues to define scope and non-goals.
Planning	Breakdown, sequence and parallelism are separated from any scope decision.	Prior clarity, rules, risks and acceptance continue.
Delivery strategy	Incrementality ceases to be an assumption of the core.	Each project may adopt phases or releases where appropriate.
SDD implementation	It is reserved for independent annexes and adapters.	The core keeps principles and guarantees that every implementation must respect.

A development is complete when every mandatory element of the product definition has an implementation and verifiable evidence, or an explicit and approved exception; when people achieve the intended outcomes under the defined conditions; and when the system's behavior and the quality of the experience have been verified with rigor proportionate to the risk.

Where the foundation includes Job Stories, verification must demonstrate the outcome in their circumstances. Completeness includes correct code, but it does not end there. It requires coverage of the scope, integration between its parts, dependable critical states, an experience that does not force anyone to learn the product's architecture, AI within explicit limits, and clarity about what must be observed after launch.