> Translation of the core of the Software Humano Manifesto v2.1. The Spanish original retains doctrinal authority; where the two diverge, the Spanish text governs.
**PRODUCT AND DEVELOPMENT FRAMEWORK CORE**
# Core of the manifesto for human software development with artificial intelligence
Principles, product foundation, Job Stories and decision tests for building products centered on people's situated progress
We build tools to extend what people are capable of, not to display what software is capable of.
**Version 2.1**
September 2026
## OPERATIONAL INDEX FOR AGENTS · `SH-INDEX`
This navigation layer lets people, agents and adapters cite core obligations in a stable way. The identifiers add no doctrine, priority, stages, artifacts or criteria: they only point to content that has already been approved. A reference by identifier never replaces reading the passage cited, nor does it modify the authority of the text.
| **Family** | **Identifiers** | **Content** |
|---|---|---|
| Navigation | `SH-INDEX` | Operational index and rule for using identifiers |
| Principles | `P01`–`P10` | Ten commitments that govern decisions |
| Foundation | `SH-FUND` | Product definition, authority, scope and reference Job Stories |
| AI directives | `D01`–`D06` | Doctrine for teams and agents |
| Flow | `F01`–`F08` | Eight steps from the foundation to verification |
| Artifacts | `A01`–`A08` | Eight documentary answers matched to context |
| Stop conditions | `SH-STOP`, `STOP01`–`STOP07` | Conditions that prevent proceeding or accepting |
| Agent contract | `CR01`–`CR08` | Reusable instructions for development |
| Agent output | `O01`–`O09` | Expected content of results in natural language |
| Verification | `V01`–`V12` | Dimensions of evidence for accepting a solution |
| Cross-cutting controls | `SH-SCORE`, `SH-AP`, `SH-GOV`, `SH-DONE`, `SH-POCKET` | Decision, anti-patterns, governance, done and short guide |
Adapters may indicate which identifiers require attention in a particular operation. That selection guides what is loaded and does not authorize ignoring any other provision of the core that applies by reason of context, risk or contradiction.
## PURPOSE OF THIS DOCUMENT
### The problem this manifesto sets out to solve
How do we build software that amplifies people's capacity to achieve what they seek, without transferring the complexity of the technology to them?
Software gains capability quickly. Artificial intelligence accelerates that process further: today it is cheap to generate screens, options, automations and layers of abstraction. That abundance does not guarantee a better product. It also makes it possible to turn a weak decision into a great deal of correct code, and an unnecessary idea into a finished feature.
This manifesto establishes a doctrine for deciding what deserves to be built, how it must feel to use, and what evidence must exist before an implementation is accepted. Its unit of measurement is not the number of features delivered. It is the progress a person can achieve with clarity, trust and control.
Version 2.1 preserves the concreteness reached through Jobs to Be Done and Job Stories, and extends the framework's capacity to work with product definitions of differing length and depth. A Job Story remains a particularly useful way to describe the circumstance that triggers a need, the motivation that drives action and the outcome being sought. The foundation of a development effort, however, may also be expressed through epics, capabilities, requirements, rules, journeys, criteria or other coherent structures. The format of the input must not force the product's intent to be distorted.
#### The central conclusion
Function establishes what the software makes possible. Experience determines how much of that capability a person can actually put to use.
Experience is not an aesthetic layer added once the functionality has been solved. It is part of it. If a solution produces the correct result but requires the user to decipher the interface, remember unnecessary rules or fear making a mistake, the solution is still incomplete.
#### Scope and readers
The framework applies to products where the user experience directly influences the outcome: web and mobile applications, internal tools, learning systems, digital services, agent-enabled products and AI-assisted solutions. It is addressed to product managers, designers, developers and coding agents who take part in product decisions.
It does not prescribe a visual style, a technology, a PRD structure, a delivery strategy or an engineering framework. Neither does it remove the real complexity of the domain. It defines how to prevent the system's internal structure from becoming, for the team's convenience, additional work for the person using it.
This document contains the core of the manifesto. Translating it into specification-driven development methods and into particular frameworks must be done through separate annexes or adapters. No implementation may reduce its principles, alter the scope defined by product, or attribute to the agent an authority that the core reserves for people.
#### How to use this document
The document offers two depths of reading. The first makes the stance understandable in a few minutes. The second turns that stance into verifiable decisions during development.
| **Route** | **Content** | **Recommended use** |
|-------------|------------------------------------------------------------------------------------|---------------------------------------------------|
| Understand | Thesis and canonical text of the manifesto | Align the team before defining a solution |
| Decide | Ten principles, product foundation and Job Stories with rules and control questions | Decide between product and UX alternatives |
| Build | Doctrine specific to development with AI | Guide coding agents and human reviewers |
| Verify | Acceptance tests, scorecard and anti-patterns | Evaluate prototypes, implementations and deliveries |
#### The architecture of the framework
Each principle is expressed at several operational levels. No level replaces another. The product foundation preserves the authorized definition of what must be built and why. Jobs to Be Done can orient progress in general terms, and the Job Story offers this manifesto's reference form for making that progress concrete, situated and verifiable.
| **Level** | **Question it answers** | **Result** |
|-------------------------|-------------------------------------------------------------|-----------------------------------------------------|
| Principle | What we believe | A stable criterion for orienting decisions |
| Product foundation | What must be built, why and under what conditions | An authorized, traceable and verifiable base |
| Reference Job Story | When a need arises and what progress the person is after | A concrete form for designing and verifying |
| Rule | What it demands when designing or implementing | An observable behavior of the product and the team |
| Test | How we know whether we have met it | Evidence that allows accepting, revising or rejecting |
#### The boundary between core and implementation
The core defines principles, authorities, traceability conditions, acceptance criteria and limits for teams and agents. A general annex may translate these obligations into a specification-driven development method. Adapters for particular frameworks must resolve commands, templates, flows, persistence and compatibility without modifying the core. A change of framework does not in itself constitute a new version of the manifesto.
## CANONICAL TEXT
### Manifesto for human software development
The purpose of software is to extend what a person can do.
People do not come to our products in order to use features. They come because they want to understand, decide, create, learn, communicate, solve problems or move forward. That progress is our real product.
Progress does not happen in the abstract. It is triggered when a circumstance creates a need, a tension or a decision. Before designing a response we describe that circumstance, the motivation it produces and the outcome the person is seeking. The solution comes afterwards.
The product definition governs what must be built. It may be expressed as a single story or through an extensive PRD made up of stories, capabilities, rules, states, journeys and criteria. Development must understand that structure, preserve its meaning and account for its full scope. Breaking the work down, ordering it or running it in parallel does not authorize omitting or redefining it.
This is why experience is part of functionality. A system that lets someone complete a task but forces them to interpret the interface, remember conventions, work through unnecessary structures or wonder what will happen next, transfers to the user a problem the product should have solved.
We do not reject complexity. Many important problems are complex. What we reject is that the complexity of building them should automatically become complexity for whoever uses the tool.
We seek software that is simple to begin with and deep when needed. Software that reveals capabilities in context, explains without interrupting, anticipates without controlling and lets people recover without fear.
Every element must justify the attention it consumes. Every interaction must help us understand where we are, what we can do and what will happen next. Every detail must contribute to an experience that is coherent, fast and dependable.
Artificial intelligence must absorb complexity, not multiply it. It may propose, summarize and automate, but it remains subordinate to the person's intent. Critical rules, permissions, commitments and states that require certainty do not depend on a probabilistic interpretation.
Now that building is easier, our responsibility grows. Before adding a capability we ask what progress it enables, what burden it introduces, what risk it creates and whether it deserves to exist.
Our aim is for sophistication to remain behind the experience, and for the person in front of it to retain their purpose, their attention and their control.
The best software does not make users admire the software. It makes them marvel at what they can now do.
## DESIGN PRINCIPLES
### Ten commitments that govern decisions
The principles do not describe decorative aspirations. Each one must be capable of changing a decision, stopping an implementation or requiring additional evidence. A sentence with no practical consequences serves no function within the framework.
| **N** | **Principle** | **Main consequence** |
|-------|--------------------------------------------------------|----------------------------------------------------------------------------------------------------------|
| 1 | The user's progress is the unit of design | Ties every decision to its product foundation and uses Job Stories when they express the situation better |
| 2 | Experience is also functionality | Includes effort, emotion and friction in the definition of quality |
| 3 | Complexity belongs to the system | Avoids passing the internal model on to the user |
| 4 | Simple to begin with, deep when needed | Reveals power in context without limiting the expert user |
| 5 | The interface must not become another task | Reduces incidental learning and custom conventions |
| 6 | Attention is a product resource | Justifies every element and every decision requested |
| 7 | Trust is designed | Makes state, consequences, control and recovery visible |
| 8 | Quality lives in the accumulation of details | Treats micro-decisions and edge states as part of the product |
| 9 | Time and continuity are part of the interface | Integrates performance, availability and preservation of work |
| 10 | The person retains control and ownership | Subordinates assistance and automation to human intent |
## PRINCIPLE 1 · `P01`
### The user's progress is the unit of design
Do not design what the user can do. Design the progress they need to achieve.
#### What it means
A feature only makes sense if it helps a person move from a current situation to a desired outcome. The product foundation establishes the authorized reason for the development. Jobs to Be Done can define progress at a broad level, and the Job Story makes it operational by describing when the need arises, what motivates the person and what outcome they are seeking, without anticipating the solution.
#### Why it matters
When work is organized around features or generic profiles, a team can deliver a great deal and resolve very little. A Job Story forces the causality to be spelled out: the circumstance that triggers the need, the tension that drives action, and the better situation that would make progress recognizable. When the product uses another form, that same causality must be preserved to the extent that it applies.
#### Design rules
- Identify the product foundation and the authorized source that establishes the scope before designing a response.
- Where the foundation is expressed through Job Stories, place them within the higher-level progress or purpose to which they belong.
- Formulate each Job Story as circumstance, motivation and outcome, without naming a screen, a component or a feature.
- Ground decisions in observed behavior, the current obstacle or anxiety, and evidence that supports acceptance of the outcome.
#### Decision tests
- Can the authorized source that justifies this decision be identified, together with its relationship to the full scope?
- Where a Job Story exists, is the circumstance specific and observable, or does it merely describe a role?
- Are the motivation and the outcome backed by evidence, or were they assumed by the team?
- Does the formulation admit several possible solutions? If it already prescribes an interface without that being a product decision, it must be revisited.
**Sign of non-compliance.** “As a student I want to receive hints to solve derivatives” looks like a useful story, but it begins with a role and prescribes a feature. It does not explain when the blockage arises, what the person needs to understand, or how to recognize that they have regained momentum.
## PRINCIPLE 2 · `P02`
### Experience is also functionality
If it works but wears you down, it does not yet work well.
#### What it means
A product is not defined solely by the accuracy of its output. How much effort, uncertainty and attention it demands in order to obtain that output also matters. Whether the experience feels fluid or frustrating alters a person's real capacity to complete their work.
#### Why it matters
Two products can deliver the same result and yield different levels of performance. A burdensome experience causes abandonment, errors, dependence on support and loss of trust. That cost is functional, even though it does not appear in the technical specification.
#### Design rules
- Include effort, clarity and trust within the acceptance criteria.
- Test the complete flow, not just each screen or endpoint in isolation.
- Consider the emotional and cognitive state that accompanies the situation defined by the product and, where one exists, by the Job Story.
#### Decision tests
- Can the person concentrate on their objective, or must they manage the tool?
- Which moments provoke doubt, tension or interruption?
- Does a task done correctly leave the user with energy to carry on?
**Sign of non-compliance.** A technically valid form that wipes the data after an error turns correction into punishment. The validation works; the experience does not.
## PRINCIPLE 3 · `P03`
### Complexity belongs to the system
Just because it is complex to build does not mean it must be complex to use.
#### What it means
The domain may require rules, integrations and exceptions. The team must absorb that complexity and present it as understandable decisions. Internal tables, states and services should not dictate the user's language or navigation.
#### Why it matters
When the interface mirrors the architecture, the person has to learn how the product was built before getting any value from it. That transfer usually seems inevitable only because it is convenient for the team.
#### Design rules
- Translate internal concepts into the person's language and mental model.
- Resolve dependencies, defaults and sequences where there is sufficient context.
- Expose an exception only to those who genuinely have to decide it.
#### Decision tests
- Does this step exist because of a user need or because of the system's structure?
- Are we showing a technical entity that could be translated or inferred?
- Does the person need to understand this rule in order to make a good decision?
**Sign of non-compliance.** Asking the user to first choose an internal record type, where that distinction has no meaning for them, exposes the data schema as though it were a human need.
## PRINCIPLE 4 · `P04`
### Simple to begin with, deep when needed
Do not remove the power. Remove the obligation to face it before it is needed.
#### What it means
Simplicity does not consist of reducing the product's capability. It consists of matching what is visible to the moment, the level of experience and the decision at hand. Depth appears progressively and remains available.
#### Why it matters
A minimalist product can feel easy on day one and limiting on day ten. A product that displays all of its power from the outset can be unapproachable. Progressive disclosure avoids both extremes.
#### Design rules
- Show the main route first and reveal advanced options when the context makes them relevant.
- Preserve shortcuts and precision for expert users without imposing them on the beginner.
- Use good defaults, always editable where the decision matters.
#### Decision tests
- What exactly does the person need to see in this state?
- Does the simplification remove noise, or does it remove necessary capability?
- Can an expert user move quickly without the beginner having to carry that depth?
**Sign of non-compliance.** Hiding every option can produce a clean first impression and a dead end when a less common case comes up.
## PRINCIPLE 5 · `P05`
### The interface must not become another task
The person came to do their work, not to learn ours.
#### What it means
An interface must build on familiar expectations, an understandable hierarchy and immediate feedback. Every custom convention the user has to memorize consumes capacity that should be spent on the real problem.
#### Why it matters
The learning burden becomes especially damaging in educational, health, financial or infrequently used products. The person is already facing enough complexity in the content or in the decision.
#### Design rules
- Prefer known conventions where they solve the problem well.
- Explain in context, without requiring prior tutorials for basic actions.
- Make the primary action, the current state and the next possible step evident.
#### Decision tests
- Does the person understand what the elements mean without an external legend?
- Do they need to remember something from a previous screen in order to act correctly?
- Does the interface add a layer of learning unrelated to the situation or the outcome to be resolved?
**Sign of non-compliance.** A numbered sequence with no visible meaning forces people to learn the navigation at the same time as the content. The numbers organize things for the team, but they do not orient the user.
## PRINCIPLE 6 · `P06`
### Attention is a product resource
Everything we show competes with what the person came to do.
#### What it means
Attention is finite. Menus, alerts, animations, choices and text all demand a share of it. Design must manage that budget with the same discipline as performance or cost.
#### Why it matters
An interface can be free of errors and still fail through saturation. Accumulated load degrades understanding, increases accidental decisions and makes simple tasks feel heavy.
#### Design rules
- Require every visible element and every decision requested to answer to a verifiable circumstance, motivation or outcome.
- Establish hierarchy by relevance to the current state, not by giving every feature equal weight.
- Reduce interruptions and reserve strong signals for matters that genuinely require attention.
#### Decision tests
- What competes visually or mentally with the primary action?
- Can an element be removed without losing necessary information or control?
- Does the interface distinguish the urgent, the important and the optional?
**Sign of non-compliance.** Presenting five actions with equal visual weight forces the user to establish a priority that the product should already know from context.
## PRINCIPLE 7 · `P07`
### Trust is designed
A good tool explains enough for the person to act without fear.
#### What it means
Trust arises when the product shows its state, anticipates consequences, confirms results and offers recovery. It does not rest on general promises, but on predictable behavior.
#### Why it matters
Uncertainty holds action back. With AI, trust additionally requires distinguishing facts, inferences, proposals and actions already carried out. A fluent response cannot conceal its limits.
#### Design rules
- Show what is happening, what will change and when an action will be irreversible.
- Allow people to undo, correct or return to a safe state where that is reasonable.
- Clearly differentiate recommendations, automatic decisions and confirmed results.
#### Decision tests
- Does the person know what will happen before confirming?
- Can they verify what the system did and why?
- Is there a way to recover that is proportionate to the risk?
**Sign of non-compliance.** An agent that reports "done" without showing what changed forces people to trust its tone rather than the evidence.
## PRINCIPLE 8 · `P08`
### Quality lives in the accumulation of details
Quality rarely depends on one big decision. It is recognized in many small decisions that align with one another.
#### What it means
Typography, spacing, wording, focus, empty states, errors, transitions and micro-interactions form a single experience. No detail compensates on its own for a poor solution, but their accumulation can either reinforce or erode trust.
#### Why it matters
Users do not separate interface, engineering and content. They experience a complete product. One small inconsistency may be tolerable; a hundred inconsistencies turn use into constant friction.
#### Design rules
- Design and verify normal, empty, loading, error, success and recovery states.
- Keep language, hierarchy and behavior consistent throughout the flow.
- Review the product at actual size and with realistic content before approving it.
#### Decision tests
- Do the details reinforce the same logic, or do they contradict expectations?
- What happens in the less frequent states?
- Does the product feel deliberately built, or assembled from parts?
**Sign of non-compliance.** A button changes its label between steps, an error appears far from its field, and focus is lost after saving. Each defect is minor; together they break continuity.
## PRINCIPLE 9 · `P09`
### Time and continuity are part of the interface
The person experiences the wait before they know anything about our architecture.
#### What it means
Latency, availability, synchronization and preservation of work are properties of the experience. The user does not distinguish between infrastructure and interface when a response is slow, an action is duplicated or progress is lost.
#### Why it matters
Slowness changes behavior: it produces repeated clicks, hesitation, abandonment and errors. Loss of continuity forces people to rebuild context and destroys trust quickly.
#### Design rules
- Define response budgets for critical interactions.
- Show honest progress and allow work to continue when an operation may take time.
- Save work, context and state at a frequency proportionate to the cost of losing them.
#### Decision tests
- Does the interface respond immediately even though the underlying process continues?
- What does the person lose if the connection fails right now?
- Does the product avoid duplicate actions and ambiguous states?
**Sign of non-compliance.** A button with no feedback for three seconds invites a second press. The resulting duplication looks like user error, but it originates in the system.
## PRINCIPLE 10 · `P10`
### The person retains control and ownership
Helping does not mean deciding for the person or taking over their work.
#### What it means
Software can anticipate, recommend and automate. It must do so without hiding decisions, locking information away or preventing alternatives. In systems with AI, control includes understanding what information was used and what action was carried out.
#### Why it matters
Automation without human agency can accelerate the wrong path. Ownership and portability reduce dependence, strengthen trust and allow people to combine tools according to their needs.
#### Design rules
- Ask for confirmation in proportion to the impact, not for every gesture nor after an irreversible action.
- Allow reviewing, editing, exporting and reverting where the domain permits it.
- Explain the use of data and separate authorization, recommendation and execution.
#### Decision tests
- Can the person reject the proposal without losing their progress?
- Do they understand what data was used and for what purpose?
- Can they recover or take their content away in a useful format?
**Sign of non-compliance.** An AI that rewrites and publishes without a preview turns assistance into appropriation of the process.
## PRODUCT FOUNDATION AND REFERENCE FORM · `SH-FUND`
### From the product foundation to a verifiable solution
The product foundation is the authorized content that establishes what must be built, why it must exist, what results it must produce, what conditions it must respect and how compliance can be determined. It is not a new kind of document nor a mandatory template. It may be found in a Job Story, a Jobs to Be Done statement, an epic, a capability, a requirement, a business rule, a journey, an acceptance criterion or a coherent combination of these elements.
#### When the foundation is identifiable
A product foundation is identifiable when development can establish, without inventing product decisions, the following elements. They may be spread across one or several parts of the definition received, and they need not use these names or this order.
| **Element** | **Control question** | **Minimum condition** |
|--------------------------|------------------------------------------------------------|--------------------------------------------------------------|
| Source and authority | Where does it come from and who may modify it? | Traceable origin and recognized authority |
| Reason | What situation, need, problem or opportunity does it address? | Justification that is understandable without the solution |
| Result | What change or progress must it produce? | A result recognizable to people or to the product |
| Conditions and limits | What rules, constraints and exclusions must be respected? | Limits sufficient to prevent silent decisions |
| Evidence | How will we know it has been met? | Criteria, observations or tests proportionate to the risk |
The absence of a specific section or field in the PRD is not in itself a defect. The method must understand the structure the product uses. If a definition capable of materially changing the solution is missing, the agent must surface the gap and refer the matter to the corresponding authority; it must not fill it in through a silent inference.
#### Full scope and product authority
When an approved product definition contains multiple stories, capabilities, rules or specifications, all of them form part of the scope unless the definition itself or an authorized decision establishes otherwise. The development plan must understand the whole, resolve its relationships and dependencies and ensure its coverage. It may break the work down, order it, group it or run it in parallel; that breakdown does not modify the scope.
The plan organizes how the scope is implemented. It does not silently decide which part of the scope deserves to exist.
- Every omission, modification or deferral must be explicit, traceable and approved by the product authority.
- If constraints of time, resources or technology prevent covering the scope, the plan must make the incompatibility visible and request a decision.
- An incremental, phased or release-based strategy may be used where the project adopts one; it is not an obligation of the core.
- Completeness is determined by reconciling the implementation and the evidence against the complete product definition and its approved exceptions.
#### Job Stories as a reference form
This manifesto uses Job Stories as a reference form for showing how a product foundation can be carried through to design, implementation and verification. Job Stories make the circumstance, the motivation and the expected outcome explicit, which makes them a particularly useful representation for reasoning about human progress.
Their use in the explanations, rules, examples and tests does not require every product definition to be expressed through Job Stories, nor does it authorize automatically transforming a PRD into that structure. Where the definition uses another form, the method must preserve its meaning, its relationships and its authority. A derived Job Story may be proposed as a working view where it adds clarity, but it does not replace the source nor acquire authority by having been generated.
#### From Jobs to Be Done to Job Stories
Jobs to Be Done and Job Stories serve different functions. Jobs to Be Done maintains the product's direction: the broad progress that leads a person to adopt a solution in their life or work. The Job Story narrows that progress down to a concrete situation that can guide a design decision, an implementation and a test.
When this form is used, each Job Story must retain an explicit relationship to the corresponding higher-level job, purpose or outcome. That relationship prevents an isolated story from losing the product's direction.
#### Relationship between the levels
| **Level** | **Defines** | **Avoids** |
|-------------------------|--------------------------------------------------------------------------------------|-----------------------------------------------------------|
| Jobs to Be Done | The broad progress the person is seeking to achieve | Organizing the product around features |
| Job Story | The circumstance, motivation and outcome that trigger a concrete need | Designing from generic roles or literal requests |
| Product response | The system behavior chosen to address the story | Confusing the problem with the first solution imagined |
| Acceptance evidence | The observation that demonstrates progress in that circumstance | Accepting a delivery because it works technically |
#### Canonical form of a Job Story
When an observable circumstance occurs, I need to make progress without prescribing the solution, so that I can reach a recognizable outcome.
**When.** Describes the fact, change or tension that triggers the need. It must be observable or recognizable without depending on a fictional persona.
**I need.** Expresses the motivation, understanding or decision required. It does not name a screen, a button, an agent or a feature.
**So that I can.** Defines the improved situation the person is seeking to reach, and which will later have to be verified.
#### Minimum evidence accompanying the story
The sentence guides the conversation, but it does not replace research. A story ready to guide development must record only the evidence needed to support its decisions.
| **Element** | **Question** | **Minimum content** |
|------------------------|-----------------------------------------------------------------|--------------------------------------------------------------|
| Current behavior | What does the person do today? | Observed steps, workaround or abandonment |
| Obstacle or anxiety | What holds progress back or makes it risky? | Relevant doubt, cost, fear, effort or dependence |
| Causal evidence | What supports the link between circumstance and motivation? | Observation, interview, usage data or a declared assumption |
| Evidence of success | What would demonstrate that progress occurred? | Observable behavior or outcome within the circumstance |
#### When role still matters
Job Stories avoid using role as an automatic explanation. They do not eliminate real differences between people. Role, experience, age, permissions or a physical constraint must be incorporated when they causally change the circumstance, the risk or the valid solution. If they do not change the decision, they must not govern the story.
#### Quality tests before designing
- The circumstance describes a concrete trigger and not a category of user.
- The motivation expresses progress or understanding and not a requested feature.
- The outcome can be recognized without confusing it with completing the product's flow.
- The story is backed by evidence, or it clearly identifies the outstanding assumption.
- The formulation allows several responses to be compared, including the option of not building.
- The scope is sufficient to change a decision, but does not attempt to contain the user's entire work.
#### Chain of traceability
Development must be traversable in both directions: from each implemented decision back to the product foundation that justifies it, and from the complete product definition forward to the evidence that demonstrates its coverage. Where the foundation is expressed through Job Stories, traceability must preserve the circumstance, the motivation and the outcome of each applicable story.
| **Origin** | **Decision** | **Verification** |
|----------------------------|-------------------------------------------------------------------------------------|----------------------------------------------------------------------------|
| Product definition | What must be built and under what conditions | Every mandatory element has coverage or an approved exception |
| Jobs to Be Done | What general progress deserves attention where this form applies | The outcome remains relevant to the person |
| Job Story | What concrete circumstance must be addressed where the source uses this form | The story is validated and does not prescribe an unauthorized solution |
| Design and implementation | What behavior responds to the foundation | Every element has a traceable reason |
| Acceptance | What evidence authorizes declaring the development complete | Results, rules and criteria are met under the defined conditions |
## DOCTRINE FOR DEVELOPMENT WITH AI
### When building costs less, the decision matters more
Coding agents reduce the cost of turning instructions into software. That advantage shifts the bottleneck. The problem is no longer only whether a capability can be built, but whether it deserves to exist, whether it solves the right problem and whether it preserves the user's understanding.
AI must absorb complexity, not produce it.
An agent can implement a weak specification at great speed, reproduce conventional patterns that do not fit the context and add plausible options that nobody asked for. This is why AI-assisted development needs an explicit layer of intent, limits and verification.
#### Six directives for teams and agents
| **Directive** | **Requirement** | **Limit** |
|-------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------|
| `D01` Foundation before implementation | Understand the product definition, its authority, its scope and the evidence behind it before proposing components or code. Where Job Stories exist, preserve their circumstance, motivation and outcome. | Do not start building if a material ambiguity may alter the solution, the scope or a rule. |
| `D02` Sufficient specification before generation | Define states, decisions, constraints and acceptance criteria at the level the risk requires. | Do not turn a vague prompt into an extensive implementation and then use the code to discover the problem. |
| `D03` Deliberate simplicity | Prefer the solution that demands fewer concepts, decisions and memory from the user where both achieve the same result. | Less code is not the measure; less unnecessary burden is. |
| `D04` Determinism where it matters | Implement critical rules, permissions, calculations, states and validations as verifiable logic. | Do not delegate certainty, compliance or security to a model's variable behavior. |
| `D05` Verification before acceptance | Evaluate the flow, the edge states, accessibility, performance and the real outcome. | Generated code and passing unit tests do not amount to a finished product. |
| `D06` AI subordinate to the user | Use AI to propose, explain and execute within clear limits, keeping review and reversibility proportionate to the impact. | The fluency of a response never substitutes for evidence or authorization. |
#### The second governing question
Now that we can build almost anything more easily, what deserves to be built and what should we deliberately leave out?
This question introduces an obligation that could previously remain hidden by technical cost. It must be raised during the product definition and when evaluating alternatives, not used during implementation to unilaterally trim an approved scope. Every capability must justify its existence against a simpler alternative, including the alternative of not building it; once authorized, any exclusion requires a traceable product decision.
#### Determinism and generation
The choice is not between a deterministic product and a product with AI. A dependable system combines both according to the nature of each decision.
| **Type of behavior** | **Preferred treatment** | **Examples** |
|------------------------------------------------------------------------|------------------------------------------------|---------------------------------------------------------------|
| Must always produce the same result under the same conditions | Deterministic rule and automated test | Permissions, prices, limits, calculations, state transitions |
| Can yield several useful answers and requires interpretation | AI with context, limits and evaluation | Explaining, summarizing, proposing alternatives, classifying text |
| May affect money, reputation, security or rights | AI proposes; a rule or a person authorizes | Publishing, purchasing, deleting, sending, changing access |
| Uncertainty is part of the output | AI declares assumptions and confidence level | Recommendations, estimates, incomplete information |
## WORKFLOW
### From purpose to a verifiable solution
The flow prevents code generation from becoming the first act of design. It does not seek to create a documentation-heavy phase or to impose a structure on the PRD. It aims to understand the foundation received, produce the clarity needed to plan and maintain coverage through to acceptance.
| **Step** | **Decision** | **Work** | **Minimum evidence** |
|----------|------------------------------------|--------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|
| `F01` | Understand the foundation | Recognize the sources, the authority, the scope, the structure used and the expected results. | A faithful map of the product definition, without reformulating it for technical convenience. |
| `F02` | Establish coverage | Inventory the applicable stories, capabilities, rules, states, journeys, criteria and relationships. | Complete coverage, with gaps or contradictions made visible. |
| `F03` | Plan the implementation | Resolve dependencies, blockers, order, parallelism, integration and testing without modifying the scope. | A coherent plan that accounts for the whole approved definition. |
| `F04` | Make progress concrete | Use the existing Job Stories, or formulate a derived view where it adds clarity and is identified as such. | Circumstances, motivations and outcomes preserved where applicable. |
| `F05` | Establish the experience contract | Describe what the person must understand, decide and feel at the critical moments. | Main route, states and interaction promise. |
| `F06` | Model rules and risks | Separate deterministic logic, generative behavior, permissions and irreversible actions. | A map of decisions and limits. |
| `F07` | Explore and prototype | Compare alternatives and test understanding, hierarchy and recovery before optimizing code. | The reason for the chosen alternative and evidence from the journey. |
| `F08` | Build, integrate and verify | Implement the plan, maintain traceability and reconcile results against the full scope. | Code, tests and evidence of coverage; outstanding items and exceptions made explicit. |
#### Artifacts matched to context
Each artifact exists to answer a question, not to satisfy a template. It may be a section of the PRD, a derived view, a table, a test or a separate document. If the information already exists, it must be referenced and not duplicated. Depth depends on length, complexity, uncertainty and risk; if an artifact neither changes a decision nor helps verify one, it must be simplified or removed.
| **Artifact** | **Question** | **Minimum content** |
|-------------------------------------|-------------------------------------------------------------|----------------------------------------------------------------------------------------------------------|
| `A01` Map of the foundation | What must be built, why and with what authority? | Sources; scope; results; rules; limits; evidence; non-goals |
| `A02` Coverage map | How will the full scope be accounted for? | Mandatory elements; relationships; dependencies; implementation; tests; status; exceptions |
| `A03` Job Story sheet where applicable | When does the need arise and what change is the person after? | Circumstance; motivation; outcome; current behavior; anxiety; evidence; assumptions |
| `A04` Experience contract | What must the person understand and be able to do? | Main route; language; decisions; feedback; control; recovery |
| `A05` State model | What can happen and which transitions are valid? | States; events; rules; errors; permissions; persistence |
| `A06` Complexity budget | What burden are we adding? | New concepts; decisions; steps; exceptions; visible options |
| `A07` Acceptance plan | What evidence authorizes declaring the development complete? | Results; rules; Job Stories where they apply; accessibility; performance; edge states; metrics |
| `A08` Decision record | Why did we choose this alternative? | Alternatives; trade-offs; assumptions; decision; date; outstanding evidence |
#### Stopping rule before generating · `SH-STOP`
The agent should not begin an implementation if it cannot answer the following questions precisely, at the level required by the risk and the complexity:
- What is the authorized product definition and what scope does it establish?
- Which elements of the foundation justify the development and what evidence supports them?
- Does the plan account for all mandatory stories, capabilities, rules, states and criteria?
- Where Job Stories exist, are the circumstance, the motivation and the outcome separated from the solution?
- What is the main route and which alternative states matter?
- Which decisions must the user make and which can the system resolve?
- Which behavior requires deterministic certainty?
- What falls outside the scope and who established that exclusion?
- What evidence will demonstrate that the development is complete?
If an answer is missing that could materially change the solution, the scope, a rule or a right, the agent must stop and ask for it. If the uncertainty is minor, reversible and within its authority, it may declare an assumption and proceed without silently reducing the coverage it has committed to.
## REUSABLE CONTRACT
### Instructions for a development agent
The following contract can be incorporated into a repository's instructions, into a PRD or into a coding agent's prompt. It must be accompanied by the product's specific context and does not replace the definition of the problem.
**`CR01` Purpose.** Build the simplest solution that lets the user achieve the defined outcome, preserving clarity, control and the ability to recover.
**`CR02` Before programming.** Identify the authorized sources, explain the product foundation and confirm the full scope. Recognize the structure the definition uses; where it contains Job Stories, preserve their circumstance, motivation and outcome. Separate evidence from assumptions and identify any ambiguity that could materially change the solution.
**`CR03` When planning.** Account for every mandatory element and establish their dependencies, blockers, order, integration and tests. Do not select, omit or defer parts of the scope on your own initiative. If constraints prevent covering it, request a decision from the product authority.
**`CR04` When proposing.** Present the recommended alternative, a simpler alternative and the option of not building, where the decision still belongs to product. Explain how each one responds to the foundation, what burden it introduces and what trade-offs it demands.
**`CR05` When designing.** Do not expose internal structures. Use the user's language, known conventions, a clear hierarchy, progressive depth, editable defaults and immediate feedback.
**`CR06` When using AI.** Reserve critical rules for verifiable logic. Declare uncertainty. Do not carry out high-impact actions without proportionate authorization. Maintain traceability, review and reversibility.
**`CR07` When implementing.** Respect the agreed scope and preserve traceability to its foundation. Do not add features, modes, configurations or abstractions that were not requested. Cover empty, loading, error, success and recovery states, and integrate the related parts.
**`CR08` Before declaring the work complete.** Reconcile the implementation against the complete product definition. Verify results, rules, criteria and, where they apply, the Job Stories in their circumstances. Also check accessibility, perceived performance, errors, persistence of work and user control. Deliver evidence, outstanding items and approved exceptions.
#### Expected delivery format from the agent
1\. `O01` Authorized sources and product foundation that justify the development.
2\. `O02` Inventory of scope and coverage of the applicable stories, capabilities, rules, states and criteria.
3\. `O03` Jobs to Be Done and Job Stories where they form part of the definition or contribute a useful derived view.
4\. `O04` Available evidence, assumptions and outcome criteria.
5\. `O05` Chosen alternative and the reason for discarding more complex options.
6\. `O06` Files or components modified and the limits of the change.
7\. `O07` States and edge cases covered.
8\. `O08` Tests run and evidence of results.
9\. `O09` Risks, uncertainties, outstanding items, exceptions and decisions that still require human judgment.
#### Short prompt for starting a task
Before writing code, identify the authorized product definition, explain its foundation and confirm the full scope. Recognize all applicable stories, capabilities, rules and criteria; where Job Stories exist, preserve their circumstance, motivation and outcome. Distinguish evidence from assumptions. Plan dependencies and coverage without omitting or deferring scope on your own initiative. Implement the simplest solution that meets what was approved, and verify results, integration, errors and recovery.
## VERIFICATION
### Tests for accepting a solution
Acceptance must produce evidence. The impression that a screen looks clean, or that the code compiles, does not demonstrate that the product fulfills its purpose.
| **Dimension** | **Acceptance evidence** |
|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `V01` Coverage | Every mandatory element of the product definition has an implementation and evidence, or an explicit and approved exception. |
| `V02` Progress | People achieve the defined outcomes and can recognize them; where Job Stories exist, this is verified in their circumstances. |
| `V03` Causality | The evidence relates the situation, the need and the outcome without depending on a feature request; where it applies, it preserves circumstance and motivation. |
| `V04` Understanding | They can explain where they are, what they can do and what will happen next, without outside help. |
| `V05` Burden | They do not face decisions, concepts or data that the system could resolve safely. |
| `V06` Depth | The beginner finds a clear route and the advanced user retains sufficient capability. |
| `V07` Trust | The system anticipates consequences, confirms results and offers proportionate recovery. |
| `V08` Control | The person can review, correct, reject or revert according to the impact of the action. |
| `V09` States | Loading, empty, error, success, interruption and return all preserve context and orientation. |
| `V10` Accessibility | The flow works with keyboard, visible focus, understandable labels, contrast and the applicable assistive technologies. |
| `V11` Performance | Critical actions meet the response budget or show honest progress. |
| `V12` AI | Variable outputs declare uncertainty; critical rules are verifiable; sensitive actions require authorization. |
#### Decision scorecard · `SH-SCORE`
Assign 0 where there is no evidence, 1 where compliance is partial or depends on an unvalidated assumption, and 2 where there is sufficient evidence. The score guides the conversation; it does not replace judgment.
| **Criterion** | **Score** | **Evidence question** |
|--------------------------|-----------|----------------------------------------------------------------------------------------|
| Traceable foundation | 0 / 1 / 2 | Sources, authority, scope, results and conditions are identifiable |
| Product coverage | 0 / 1 / 2 | Every mandatory element has implementation, a test or an approved exception |
| Applicable Job Stories | 0 / 1 / 2 | Where they exist, circumstance, motivation and outcome retain sufficient evidence |
| User progress | 0 / 1 / 2 | The implementation produces the outcomes defined by the product |
| Cognitive load | 0 / 1 / 2 | It reduces or justifies concepts, decisions and steps |
| Interface clarity | 0 / 1 / 2 | State, action and consequence are understood |
| Control and recovery | 0 / 1 / 2 | Proportionate review, correction or reversibility exists |
| Progressive depth | 0 / 1 / 2 | Capability appears when it is appropriate |
| Dependability and timing | 0 / 1 / 2 | Performance, persistence and feedback meet expectations |
| Responsible use of AI | 0 / 1 / 2 | Uncertainty, limits and determinism have been resolved |
| Cumulative quality | 0 / 1 / 2 | States, language and micro-interactions are coherent |
Recommended exit criterion. No critical dimension may score 0. Criteria relating to security, permissions, money, personal data or irreversible actions must score 2 before release. For the rest, the team must define its threshold according to risk and scope.
#### Questions for a product review
- What authorized source and what product foundation justify this decision?
- Do the implementation and its tests account for the full scope?
- Where Jobs to Be Done or Job Stories exist, how does this decision relate to them?
- Does the formulation describe a need, or is it a feature request recast in another form?
- What cognitive load does it introduce and what does it remove?
- Are we exposing internal complexity?
- Can any element be removed without reducing capability or control?
- Does the person know what will happen before acting?
- Can they recover easily if they make a mistake or if the system fails?
- Is the AI proposing, deciding or executing? Is that level authorized?
- What would make us reject this implementation even though it technically works?
## ANTI-PATTERNS · `SH-AP`
### Signs that the product is drifting away from the manifesto
| **Anti-pattern** | **How it shows up** | **Response** |
|-----------------------------------------------|----------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| The Job Story is a feature in disguise | The motivation says to use a dashboard, receive alerts or press a button. | Reformulate the progress the person needs without anticipating the answer. |
| The circumstance was invented | The team writes a plausible story without observing behavior, tension or real context. | Mark it as a hypothesis and obtain evidence before extending the implementation. |
| The interface mirrors the database | The user has to choose internal types, states or relationships. | Translate the structure into human goals and decisions. |
| More options are mistaken for more value | Every exception turns into a visible control. | Resolve by context and reveal exceptions when they arise. |
| AI fills conceptual gaps | An ambiguous prompt produces a large implementation. | Stop, clarify the material assumptions and preserve the authorized scope. |
| The plan selects scope | Some stories or rules are implemented and the rest deferred without a product decision. | Restore full coverage, or record an explicit and approved modification. |
| Decomposition is mistaken for exclusion | A technical phase is presented as though it redefined what the PRD requires. | Separate execution order, progress status and committed scope. |
| The tutorial compensates for an opaque interface | The basic task requires prior explanation. | Review language, hierarchy, conventions and feedback. |
| Confirmation substitutes for reversibility | The system asks several times, but there is no undo. | Design recovery and use confirmations only according to risk. |
| The happy path defines the product | Errors, empty states and interruptions are left for later. | Model states before implementing and accept them explicitly. |
| A fluent answer looks true | The user does not distinguish fact, inference and proposal. | Show source, uncertainty, limits and a route to verification. |
| Technical speed hides the wait | The operation takes time with no feedback, or blocks the whole flow. | Respond immediately, show progress and preserve continuity. |
| Aesthetics paper over friction | The screen looks good, but demands unnecessary decisions. | Evaluate the complete journey and the real effort. |
| The agent adds things just in case | Modes, preferences and abstractions appear that nobody asked for. | Define exclusions and require justification per capability. |
#### A warning about simplicity
Simplicity can become an excuse for hiding information, denying legitimate cases or limiting the expert user. The framework does not reward empty interfaces. It rewards the right relationship between capability, moment and context.
Valuable simplicity does not remove what is necessary. It avoids demanding it before its time.
## WORKED EXAMPLE
### A calculus tutor for someone who does not yet understand
Consider an application that explains derivatives, proposes an exercise, offers a hint and finally shows the solution. The flow looks complete. However, if the person gets the exercise wrong after reading the explanation and still does not understand the solution, they reach a dead end. The application delivered content, but it did not produce progress.
#### From a feature request to the circumstance
**Weak formulation.** As a student I want to receive hints so that I can solve derivatives. The role is generic, the hint already prescribes the response, and the outcome does not distinguish understanding from mechanical progress.
**Main Job Story.** *When I have read an explanation and I still do not know which rule to apply, I need to identify the prior concept I do not understand, so that I can resume the exercise without depending on being shown the solution.*
**Recovery Job Story.** *When I see the solution and I still do not understand why the next step was chosen, I need to reconstruct a single decision using a different representation, so that I can explain the rule in my own words.*
Both stories belong to the same higher-level Jobs to Be Done: developing enough understanding to solve an equivalent exercise with growing autonomy. They describe different blockages, however, and may call for different responses.
#### Diagnosis from the manifesto
| **Principle** | **Problem observed** |
|---------------|-----------------------------------------------------------------------------------------|
| Progress | The system measures steps consumed, not understanding achieved. |
| Experience | The person ends up frustrated and with no route to recovery. |
| Complexity | The explanation preserves the expert's model instead of rebuilding the concept. |
| Interface | Numbers or stages without meaning add incidental learning. |
| Trust | The final solution is presented as closure, even though understanding is still absent. |
#### Evidence that completes the Job Story
| **Element** | **Observation** |
|------------------------|-------------------------------------------------------------------------------------------------------|
| Current behavior | The person asks for a hint, then the solution, and still cannot decide which rule to apply. |
| Obstacle and anxiety | They do not identify the missing prerequisite and are afraid to move on without understanding. |
| Evidence of success | They can choose and explain the rule in an equivalent exercise with less help. |
#### Redesign of the journey
1\. Detect the type of blockage: concept, notation, prior operation or interpretation of the problem statement.
2\. Reformulate using a different representation, rather than repeating the same explanation with more words.
3\. Check an earlier micro-skill through a brief, diagnostic question.
4\. Offer a worked example step by step, with one decision at a time and in the student's language.
5\. Ask them to explain the reasoning or complete an equivalent step before moving on.
6\. Always keep a route to go back, switch explanation or ask for human help.
#### What stays deterministic and what may use AI
| **Layer** | **Responsibility** |
|------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Deterministic | Sequence of states; mathematical validation; mastery of prerequisites; record of attempts; progression rules; prevention of dead ends. |
| AI-assisted | Reformulating an explanation; generating an analogy; classifying the blockage; adapting the tone; proposing an equivalent exercise within validated limits. |
| Human control | Letting the student or tutor choose another route, review the history and correct a mistaken inference by the system. |
#### Success criterion
The goal is not for the student to reach the end of the sequence. It is for them to be able to solve or explain an equivalent exercise with less help. That difference changes the interface, the logic, the measurement and the use of AI.
## GOVERNANCE · `SH-GOV`
### How to turn the manifesto into everyday practice
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. |
#### Evolution of the manifesto
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. |
#### Definition of done · `SH-DONE`
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.
## POCKET GUIDE · `SH-POCKET`
### Fourteen questions before accepting a decision
1\. What is the authorized source and what scope does it establish?
2\. Does the plan account for every mandatory element?
3\. What concrete circumstance triggers the need?
4\. What motivation or tension drives the person to act?
5\. What outcome would make the progress recognizable?
6\. What behavior or evidence demonstrates that the story occurs?
7\. Where a Job Story exists, does it describe the problem without prescribing the solution?
8\. What complexity does the system absorb, and what does it still pass on?
9\. What must the person see now, and what can wait?
10\. What will happen if they make a mistake, interrupt, or come back later?
11\. Do they retain control over the decision, the data and the outcome?
12\. Which part needs determinism and which part admits generation?
13\. What is the simplest alternative that meets the product foundation?
14\. What evidence would allow us to say it is done?
#### Seven reasons to stop an implementation
- `STOP01` There is no identifiable product foundation, or the solution appears to precede the problem.
- `STOP02` The plan does not account for the whole mandatory scope defined by product.
- `STOP03` There is an intention to omit, modify or defer a part without an authorized decision.
- `STOP04` A material ambiguity is being resolved by the agent without authorization.
- `STOP05` The interface exposes internal complexity that the system could absorb.
- `STOP06` A sensitive action lacks determinism, traceability or recovery.
- `STOP07` The team can only demonstrate that the code works, not that the user makes progress.
#### Three sentences that protect judgment
What circumstance triggers this need?
What progress does it enable?
What evidence demonstrates it?
## INFLUENCES AND NOTES
### Origin of this perspective
This framework is an independent elaboration inspired by public ideas from Craft and by the conversations that gave rise to this document. It is not an official Craft manifesto, and it does not attribute the operational rules proposed here to Craft's founder.
Four influences are taken from Craft: the union of form and function; the effect a tool has on the energy and capability of whoever uses it; adaptable complexity that appears when it is needed; and the human-first approach, as against systems that force people to accommodate themselves to their structure.
From Jobs to Be Done, progress is retained as the higher-level reference. From Job Stories, a concrete way of carrying that progress into design is adopted, through circumstances, motivations, outcomes, current behavior, anxieties and causal evidence.
Version 2.1 integrates these influences within a core capable of respecting heterogeneous product definitions. Job Stories remain a reference form and a worked example; they do not replace other authorized structures, nor do they allow their scope to be trimmed.
#### Sources consulted
Craft. [About Craft](https://www.craft.do/es/about). The founder's history and reflections on form, function, friction, adaptable complexity and attention to detail.
Balint Orosz. [Introducing Craft 3](https://www.craft.do/blog/welcome-to-craft3), 28 November 2024. Adaptation to context, reduction of cognitive load, performance and offline operation.
Balint Orosz. [Your content is yours and that is more empowering than ever](https://www.craft.do/blog/your-content-is-yours), 27 November 2025. Control over content, portability, AI and the human-first versus systems-first principle.
Alan Klement. [Designing Features Using Job Stories](https://www.intercom.com/blog/using-job-stories-design-features-ui-ux/), published by Intercom on 23 December 2013. Granular application of Jobs to Be Done to the design of features, interface and experience through context, causality, motivations and anxieties.
#### Closing statement
Technology can be extraordinarily sophisticated behind the interface. In front of it, there must remain a person focused on what they set out to achieve.