# S.A.W. 3.2 — SDD Another Way

## Normative specification of the protocol

## 1. Document Status

This document defines the documentation protocol of **S.A.W. — SDD Another Way**, version 3.2.

Normative revision: `3.2.0-2026-09-27`.

S.A.W. 3.2 replaces S.A.W. 3.1. It defines the protocol without depending on a utility, an agent, an IDE, or a version control system.
It has been proven by the implementation of SAW on several projects that the LLM used for coding could quite well follow and handle the "bureaucracy" without needing a separate utility. Outside of this rational and coherent use of the method, the latter can be entirely followed "manually", it was designed for that. But since AI is already present to produce code, using it for tracking the documents of the method seems natural and logical.

It describes:

- mandatory artifacts;
- their content;
- their mutation rules;
- the lifecycle of a lot;
- validations;
- closure;
- capitalization;
- the structured grouping of projects into an Application.

The manual protocol constitutes the reference.

A S.A.W. project MUST remain usable without a particular agent, without an IDE and without an imposed version control system.

This version does not authorize the parallel execution of several lots in the same project. Distinct projects of the same Application MAY be executed simultaneously according to section 20 bis, when their parallelism contract is explicit.

## 2. Normative Vocabulary

The following words have a stable normative meaning, regardless of the language of the document:

| Term | Meaning |
|---|---|
| `MUST` | Absolute obligation. |
| `MUST NOT` | Absolute prohibition. |
| `SHOULD` | Strong recommendation. Any deviation SHOULD be justified. |
| `SHOULD NOT` | Strongly discouraged practice. Any deviation SHOULD be justified. |
| `MAY` | Permissive possibility. |

## 3. Object of S.A.W.

S.A.W. is a delegation and continuity method based on a lightweight documentary protocol.

A "S.A.W. project" is a documentary steering unit. It MAY represent an entire application, a sub-function, or another identifiable scope of work; it does not imply either a distinct project in the usual organizational sense or a separate code repository. Each unit nevertheless retains its own documentary root and project artifacts.

The size of the team or project is not a criterion for applicability of S.A.W.

S.A.W. is distinguished by the absence of hardware or software dependency specific to the method.

In particular, it does not require:

- specific hardware;
- any script;
- any preset;
- a Python environment;
- an IDE;
- a version control system;
- an LLM agent or provider.

A system capable of storing and modifying Markdown files is sufficient to apply the method manually.

The human remains at the center of decisions.

No decision is automatic.

A deterministic verification or documentary operation MAY be automated.

This automation MUST NOT substitute a human decision required by the protocol.

It allows explicitly preserving:

- the intention;
- the scope;
- the rules;
- the decisions;
- the state of work;
- acquired knowledge;
- validations;
- deviations between intention and result.

Markdown artifacts constitute the protocol.

The protocol is directly applicable with Markdown files.

## 4. Principles

### 4.1 Transparency

Any rule governing work MUST be readable in the artifacts.

An indispensable behavior MUST NOT reside solely in:

- a program;
- a plugin;
- a hidden prompt;
- an external runtime;
- a prior conversation.

### 4.2 Independence

S.A.W. MUST NOT impose:

- Git;
- another version control system;
- an IDE;
- an agent;
- an LLM provider;
- a branch system.

### 4.3 Source of Truth

Markdown files are the source of truth.

A proprietary representation MUST NOT take authority in their place.

### 4.4 Separation of Responsibilities

Each artifact answers a distinct question.

Information SHOULD remain in the artifact to which it belongs.

Other artifacts SHOULD reference it without copying it.

### 4.5 Distribution of Processing

```text
deterministic operation   → program or command
semantic understanding    → LLM
lasting intention         → Markdown
business validation       → human
```

### 4.6 Proportionality

Automation SHOULD remove more complexity than it introduces.

## 5. Artifacts

S.A.W. defines ten required artifacts.

### 5.1 Global Artifacts

| Artifact | Question |
|---|---|
| `README.md` | How to work in this project? |
| `PROJECT.md` | What is the project and why does it exist? |
| `RULES.md` | Which active rules govern the project? |
| `STATUS.md` | What is the current state of lots? |
| `LEDGER.md` | Which durable decisions have been made and why? |
| `HISTORY.md` | Which significant operations have been performed, by whom and when? |

The six global artifacts are required, including `HISTORY.md`, without exception related to project size. The form of the log SHOULD be indicated in `README.md` so that executors know how to record operations.

### 5.2 Lot Artifacts

| Artifact | Question |
|---|---|
| `SPEC-xxx.md` | What must the lot accomplish? |
| `FINDINGS-xxx.md` | What was learned during the lot? |
| `GATES-xxx.md` | Under what conditions can the lot be closed? |
| `CONVERGENCE-xxx.md` | What was obtained and why is the lot closed? |

## 6. Disk Organization

### 6.1 Main Lot

```text
/
├── README.md
├── PROJECT.md
├── RULES.md
├── STATUS.md
├── LEDGER.md
├── HISTORY.md
├── SAW-3.2-SPECIFICATION.md
└── Specs/
    └── 001-export-pdf/
        ├── SPEC-001.md
        ├── FINDINGS-001.md
        ├── GATES-001.md
        └── CONVERGENCE-001.md
```

`CONVERGENCE-001.md` MAY be absent prior to the preparation of closure.

`HISTORY.md` MUST be present at the root of the project according to section 14 bis.

The file containing the executable specification of the applied S.A.W. version MUST be copied to the root of the project. Its file name, its version, and its revision MUST allow it to be identified without ambiguity. This file is a normative reference distributed with the project; it does not constitute an additional project artifact.

### 6.2 Sub-lot

```text
Specs/
└── 001-export-pdf/
    └── 001-002-pdf-a/
        ├── SPEC-001-002.md
        ├── FINDINGS-001-002.md
        ├── GATES-001-002.md
        └── CONVERGENCE-001-002.md
```

The parent lot retains its identifier.

`LOT-001` MUST NOT become `LOT-001-000` after its creation.

### 6.3 Names

Normative file names are in English.

Folder names use:

```text
<numeric-identifier>-<short-name>
```

The short name SHOULD be:

- descriptive;
- stable;
- written in lowercase;
- separated by hyphens;
- independent of the state of the active lot.

## 7. Identifiers

### 7.1 General Rules

Every identifier MUST be unique within the project.

Every identifier MUST be immutable.

A withdrawn, cancelled, or deprecated identifier MUST NOT be reused.

The identifier is authoritative.

A Markdown link is optional.

### 7.2 Canonical Forms

| Element | Form | Example |
|---|---|---|
| Lot | `LOT-nnn` | `LOT-001` |
| Sub-lot | `LOT-nnn-nnn` | `LOT-001-002` |
| Requirement | `REQ-<lot>-nnn` | `REQ-001-003` |
| Sub-lot Requirement | `REQ-<lot>-<sub-lot>-nnn` | `REQ-001-002-003` |
| Finding | `F-<lot>-nnn` | `F-001-010` |
| Sub-lot Finding | `F-<lot>-<sub-lot>-nnn` | `F-001-002-010` |
| Gate | `G-<lot>-nnn` | `G-001-004` |
| Sub-lot Gate | `G-<lot>-<sub-lot>-nnn` | `G-001-002-004` |
| Decision | `D-nnn` | `D-023` |
| Rule | `R-nnn` | `R-012` |
| History Event | `EVT-nnnnnn` | `EVT-000042` |

Numeric segments use three digits padded with zeros, except `EVT`, which uses six.

`EVT` is used only if the project chooses the detailed format of `HISTORY.md`.

### 7.3 Archive References

An archived incarnation uses a reference of the form:

```text
LOT-001-OBSOLETE-001
```

This reference is not a new logical lot identifier.

The logical identifier remains `LOT-001`.

The suffix distinguishes preserved incarnations of the same logical lot.

An assigned archive reference MUST be unique and MUST NOT be reused.

### 7.4 References

Minimal reference:

```markdown
Source: F-001-010
```

Reference with optional link:

```markdown
Source: [F-001-010](../Specs/001-export-pdf/FINDINGS-001.md#f-001-010)
```

A broken link does not render the identifier invalid.

## 8. Dates and persons

### 8.1 Default format

The default format is:

```text
YYYY-MM-DDTHH:mm:ss
```

Example:

```text
2026-09-24T15:10:00
```

### 8.2 International project

An international project SHOULD impose a UTC offset:

```text
YYYY-MM-DDTHH:mm:ss±HH:mm
```

Example:

```text
2026-09-24T15:10:00+02:00
```

The choice of format MUST be recorded in `RULES.md` when it differs from the default format.

### 8.3 Human identity

Human validation requires a free name.

S.A.W. imposes neither an electronic address, nor an account, nor a cryptographic signature.

Several persons MAY be indicated.

S.A.W. does not determine whether a person possesses the required authority.

## 9. Obsolescence and replacement

### 9.1 Marking

An element that ceases to be active MUST remain present.

Its title MUST begin with:

```text
[OBSOLETE]
```

A date MAY be added:

```text
[OBSOLETE 2026-09-24]
```

A replaced element MUST contain:

```text
Replaced by: <identifier>
```

The replacement MUST contain:

```text
Replaces: <identifier>
```

The normative form is `Replaced by`.

### 9.2 Retention

The content of an element marked `[OBSOLETE]` MUST be retained.

It MUST NOT be rewritten after its obsolescence.

A typographical correction MAY be made if it does not change the meaning.

### 9.3 Complete replacement of a lot document

The active document retains the canonical name:

```text
SPEC-001.md
```

The first fully replaced version becomes:

```text
SPEC-001-OBSOLETE-001.md
```

Subsequent replacements use:

```text
SPEC-001-OBSOLETE-002.md
SPEC-001-OBSOLETE-003.md
```

The suffix `OBSOLETE-nnn` identifies a documentary archive.

It does not create a new logical lot.

A genuinely different objective MUST receive a new lot identifier.

### 9.4 Complete replacement of a lot

An obsolete incarnation MAY be retained in a suffixed folder:

```text
001-export-pdf-OBSOLETE-001/
```

Its files SHOULD use the same suffix.

The active replacement resumes the canonical path of the same logical lot.

`STATUS.md` MUST contain a line for the obsolete incarnation and a line for the active incarnation.

## 10. `README.md`

### 10.1 Responsibility

`README.md` defines the working protocol of the project.

It MUST remain the universal entry point.

It MUST NOT contain:

- the detailed definition of the product;
- detailed technical rules;
- the detailed status of lots;
- the history of decisions.

### 10.2 Minimal sections

```markdown
# S.A.W. project protocol

## Purpose of this file
## Protocol reference
## Mandatory bootstrap
## Starting a lot
## Working on a lot
## Validating a lot
## Closing a lot
## Mutation rules
## Human-only decisions
```

### 10.3 Mandatory bootstrap

To work on a lot, the reading order is:

```text
1. README.md
2. PROJECT.md
3. RULES.md
4. All active decisions of LEDGER.md
5. Explicitly referenced obsolete decisions
6. STATUS.md
7. SPEC-xxx.md
8. FINDINGS-xxx.md
9. GATES-xxx.md
10. CONVERGENCE-xxx.md, if this file exists
```

Reading all active decisions is mandatory.

The ledger contains only durable decisions. This reading prevents an applicable decision from being discarded by imperfect relevance detection.

An obsolete decision not referenced MAY not be read in full.

`HISTORY.md` is not part of the usual bootstrap. It SHOULD be consulted when the chronology of an operation aids a resumption, reconciliation, or audit.

### 10.4 Reference from a lot

Artifacts of a lot MUST begin with a short reference to the root `README.md`.

Example:

```markdown
> Before working on this lot, read the repository root README.md.
```

Bootstrap instructions MUST NOT be copied into lot files.

### 10.5 Document autonomy

From `README.md`, an executor MUST be able to find all rules necessary for applying the protocol in the project, without prior conversation or unwritten local convention.

The `Protocol reference` section MUST identify the version and revision of S.A.W. applied. It MUST indicate that the project follows the S.A.W. method described in the executable specification file copied to the root of the project, and contain a direct Markdown link to this file. A reference to an unidentified current version is not sufficient.

A transmission announced as autonomous MUST include this executable specification file and the documents necessary for the bootstrap. The normative reference is therefore always available locally at the root of the project; it does not constitute an eleventh type of project artifact.

Example:

```markdown
## Protocol reference

This project follows S.A.W. 3.2, as described in [SAW-3.2-SPECIFICATION.md](SAW-3.2-SPECIFICATION.md).

Revision: `3.2.0-2026-09-27`
```

Applicable procedures MUST be consulted before their execution. It is not necessary to copy the entire method into each artifact.

Document autonomy presupposes the necessary skills for the requested work. It MUST NOT presuppose knowledge of decisions or procedures specific to the project that are not written.

## 11. `PROJECT.md`

### 11.1 Responsibility

`PROJECT.md` defines what is built and why.

When the S.A.W. project corresponds to a sub-function of an Application, this file defines its own scope and its contribution to the whole.

It is very stable.

### 11.2 Minimal sections

```markdown
# Project

## Purpose
## Problem
## Users and actors
## Scope
## Out of scope
## Stable functional characteristics
## Glossary
```

### 11.3 Excluded content

`PROJECT.md` MUST NOT contain:

- the status of lots;
- current tasks;
- detailed technical choices;
- decision history.

### 11.4 Identifiers

Elements of `PROJECT.md` do not receive a default identifier.

An identifier MAY be added if a stable reference is necessary.

## 12. `RULES.md`

### 12.1 Responsibility

`RULES.md` contains the active constraints of the project.

It may notably define:

- platforms;
- languages;
- runtimes;
- architecture;
- imposed or forbidden libraries;
- security;
- tests;
- conventions;
- date formats.

### 12.2 Form of an initial rule

A rule present at project creation does not require a ledger decision.

```markdown
## R-001 — Rule title

Status: ACTIVE
Source: Initial project rule

Rule:
The project MUST ...

Rationale:
...

Replaces: None
Replaced by: None
```

`Rationale` is optional.

### 12.3 Evolution of a rule

Any rule added or modified after initialization MUST reference a ledger decision.

Old rule:

```markdown
## [OBSOLETE 2026-09-24] R-001 — Rule title

Status: OBSOLETE
Replaced by: R-008
Decision: D-023

Rule:
The project MUST ...
```

New rule:

```markdown
## R-008 — New rule title

Status: ACTIVE
Source: D-023
Replaces: R-001

Rule:
The project MUST ...
```

The old rule retains its text.

### 12.4 Evolution circuit

An evolution resulting from a finding follows this circuit:

```text
Finding
→ human decision
→ LEDGER.md
→ old rule marked [OBSOLETE], if necessary
→ new active rule
```

### 12.5 Scope of an evolution

Any evolution of a rule MUST specify its scope of application in the rule or by reference to its decision: future work, current lot, already designated closed results, or set of affected results.

The decision MUST record the examination of potentially affected lots and the retained follow-ups. The absence of necessary action MUST be indicated explicitly when it is the conclusion of this examination.

For a lot in progress, the effect on acquired validations MUST be handled according to section 17.10.

A new rule MUST NOT automatically reopen a closed lot. If a closed result becomes incompatible with an applicable rule, the decision MUST identify that result and the retained treatment. Any potential resumption remains a human decision and follows sections 18.6 and 19.3.

Prior convergence remains unchanged as long as the lot is not resumed. It attests to closure in its original context, and not compliance with all future rules.

## 13. `STATUS.md`

### 13.1 Responsibility

`STATUS.md` provides the current state of lots.

It does not constitute a detailed history.

It does not follow the people or agents who worked on the lots.

### 13.2 Minimal form

```markdown
| Lot reference | Parent | Title | Status | Replaced by | Comment |
|---|---|---|---|---|---|
| LOT-001 | — | Export PDF | Closed | — | — |
| LOT-002-OBSOLETE-001 | — | Old import | Obsolete | LOT-004 | Replaced |
| LOT-003 | — | Mobile mode | Cancelled | — | No longer required |
```

`Lot reference` contains the canonical identifier or the reference of an archived incarnation.

A lot appears in `STATUS.md` starting from the `Planned` state.

A draft MAY remain absent.

All recognized obsolete incarnations MUST appear.

### 13.3 Authority

`STATUS.md` is the sole authority on the current state of a lot.

The state MUST NOT be copied into `SPEC`, `FINDINGS`, `GATES` or `CONVERGENCE` as current authoritative state.

### 13.4 Resumption information

Before transmitting or interrupting work on a lot, artifacts MUST allow identifying:

- the available result and its location, or the absence of a result;
- the known remaining work;
- any blockages and the conditions for their removal;
- the next necessary action or decision.

`STATUS.md` MUST provide a current summary or references allowing to retrieve this information. An additional section per lot MAY be used if the `Comment` column is not sufficient.

The knowledge underlying a blockage remains in `FINDINGS`, remaining validations in `GATES`, and intention as well as dependencies in `SPEC`. This information SHOULD be referenced rather than copied.

This minimum resumption does not constitute an activity log. A single sentence MAY suffice if it provides all necessary information. It MUST be updated when the described situation changes.

## 14. `LEDGER.md`

### 14.1 Responsibility

`LEDGER.md` preserves durable decisions.

It MUST NOT become:

- a logbook;
- a list of all problems;
- a copy of the findings;
- a list of all commands executed.

### 14.2 Form of a Decision

```markdown
## D-023 — Decision title

Date: 2026-09-24T15:10:00
Decided by: Alice Martin
Source: F-001-010
Related: LOT-001, R-012

Decision:
...

Reason:
...

Consequences:
...

Replaces: None
Replaced by: None
```

Mandatory fields:

- `Date`;
- `Decided by`;
- `Decision`;
- `Reason`.

Optional fields:

- `Source`;
- `Related`;
- `Consequences`;
- `Replaces`;
- `Replaced by`.

An initial decision MAY use:

```text
Source: None
```

Several decision-makers MAY be listed if they possess the necessary authority.

The optional nature of a field does not exempt from preserving information required by another section. In particular, the scope and consequences of a rule change MUST be documented in accordance with section 12.5.

### 14.3 Mutation

A validated decision is immutable.

A substantive correction produces a new decision.

The old decision becomes `[OBSOLETE]` and references the new one.

A typographical correction without change of meaning MAY be made.

## 14 bis. `HISTORY.md`

### 14 bis.1 Responsibility and coverage

`HISTORY.md` is the chronological log of significant operations performed on the document project. It describes the acts executed; `LEDGER.md` preserves durable decisions and their reasons, `STATUS.md` the current state, and other artifacts their own content. A history entry does not replace any of these records.

`HISTORY.md` MUST exist at the root of the project, just like the other required global artifacts. The detailed format of section 14 bis.2 remains optional.

The executor MUST record important operations that modify the document project: creation and transitions of a lot; evolution of a requirement, rule or gate; recording of a decision or finding; validation; convergence; resumption or reconciliation. Nearby operations MAY be grouped into a single intelligible entry. Reads, searches and commands without documentary effect MAY remain outside the log. `HISTORY.md` does not constitute an exhaustive development log but a reading guide for the full design cycle. Details are in the other logs.

### 14 bis.2 Detailed format

Each operation MAY be described by an identified event and explicit fields, which facilitates filtering and reconciliation with other artifacts:

```markdown
## EVT-000042 — Requirement replaced

Date: 2026-09-24T16:42:18+02:00
Actor: Codex
Operation: Replace requirement
References: LOT-001, REQ-001-002, REQ-001-007
Documents: Specs/001-base64-cli/SPEC-001.md
Decision: D-003
Outcome: Applied

Summary:
REQ-001-002 was preserved as obsolete and replaced by REQ-001-007.
Reciprocal replacement references were added.
```

In this format, `Date` follows section 8; `Actor` names the executor; `References` identifies the affected objects; `Documents` gives their paths relative to the project root; `Decision` refers to a ledger decision, or is `None`; `Outcome` indicates the observed result, for example `Started`, `Applied`, `Interrupted` or `Reconciled`. `Summary` MAY remain brief.

Identifiers `EVT-nnnnnn` are specific to the detailed format. If they are used, they MUST be unique and SHOULD be increasing; a correction or reconciliation SHOULD reference the preceding concerned event.

### 14 bis.3 Writing, correction and resumption

The log is kept by appending to the end of the file. Existing entries MUST be preserved; a correction SHOULD be made by a new entry specifying what changes. A simple operation SHOULD be noted after its application. For a compound operation, a start entry and a result entry are advised if the chosen level of detail permits it. A brief manual maintenance MAY only record the verified result.

An event `Started` without subsequent result signals an operation to verify. For any resumption, the executor MUST compare artifacts and apply section 22.8; he MUST NOT deduce the actual state from the log alone. If he notices an unlogged write, he SHOULD add a reconciliation entry without inventing a date or historical actor.

The log allows reconstructing the chronology of recorded events, but does not guarantee capture of each manual edition nor exact restoration of old file versions. Archives, gate histories, convergences and any versioning mechanisms preserve prior contents according to their own rules.

## 15. `SPEC-xxx.md`

### 15.1 Responsibility

`SPEC` defines the intent of the lot.

It does not contain:

- global rules;
- the work log;
- findings;
- gate results;
- closure conclusion.

### 15.2 Minimal sections

```markdown
# LOT-001 — Lot title

> Before working on this lot, read the repository root README.md.

Parent: None
Created: 2026-09-24T10:00:00

## Objective
## Context
## In scope
## Out of scope
## Requirements
## Important cases
## Dependencies
## Known constraints
```

`Parent` and `Created` are optional.

`Status` MUST NOT appear as an authoritative state.

### 15.3 Active requirement

```markdown
### REQ-001-001 — Requirement title

The system MUST ...
```

### 15.4 Replaced requirement

```markdown
### [OBSOLETE 2026-09-25] REQ-001-001 — Requirement title

Replaced by: REQ-001-006
Decision: D-031

The system MUST ...
```

New requirement:

```markdown
### REQ-001-006 — New requirement title

Replaces: REQ-001-001
Decision: D-031

The system MUST ...
```

### 15.5 Mutation

Before `In-progress`, the spec MAY be completed without ledger decision.

After `In-progress`:

- a correction without change of meaning MAY be made without decision;
- an addition, removal, or change of meaning MUST reference a ledger decision;
- replaced content MUST remain visible;
- the replaced identifier MUST NOT be reused.

## 16. `FINDINGS-xxx.md`

### 16.1 Responsibility

`FINDINGS` preserves knowledge acquired during the lot.

A finding is not automatically a decision.

### 16.2 Form of a finding

```markdown
# Findings — LOT-001

> Before working on this lot, read the repository root README.md.

## F-001-010 — Finding title

Status: OPEN
Found at: 2026-09-24T11:20:00

Finding:
...

Evidence:
...

Impact:
...

Destinations:
- Local
```

`Evidence` and `Impact` are optional.

The author of the finding is not required.

### 16.3 States

Possible states:

```text
OPEN
RESOLVED LOCALLY
PROMOTED TO LEDGER
PROMOTED TO RULE
DEFERRED TO LOT
DISCARDED
```

Several terminal states MAY be combined when a finding has multiple destinations.

`OPEN` does not combine with a terminal state.

`DISCARDED` does not combine with a promotion.

A `DISCARDED` finding MUST contain a reason.

### 16.4 Destinations

Possible and cumulative destinations:

```text
Local
Ledger: D-xxx
Rule: R-xxx
New lot: LOT-xxx
Discarded
```

Creating a lot from a finding is a human decision.

An `OPEN` finding does not automatically prohibit `Ready-to-close`.

It MUST be reviewed before closure.

Its final destination MUST then be populated.

### 16.5 Required processing at closure

A finding MUST NOT remain `OPEN` at closure.

Each finding MUST possess one or more terminal states consistent with its destinations. The referenced decisions, rules, and lots MUST exist; a recipient lot MUST be at least `Planned`.

A local resolution MUST sufficiently explain the processing performed to allow subsequent understanding. A rejection MUST retain its reason.

Processing of the finding MUST be completed, but work delegated to a subsequent lot MAY remain to be realized. This deferral does not exempt accepting any potential deviation from the active requirements of the closed lot.

## 17. `GATES-xxx.md`

### 17.1 Responsibility

`GATES` defines closure conditions.

It does not describe implementation.

It MUST NOT become a second spec.

### 17.2 Creation

`GATES` is created with the lot.

The gates MUST be defined before transitioning to `Planned`.

After `In-progress`, any addition, removal, or change in direction of a gate MUST reference a ledger decision.

### 17.3 Types

Allowed types:

```text
AUTO
LLM
HUMAN
```

`AUTO` produces a deterministic verdict.

`LLM` produces a semantic analysis.

`HUMAN` reserves the verdict to a human.

An agent or an LLM MAY launch an `AUTO` gate.

The type remains `AUTO` if the verdict comes from a deterministic command.

All business validation MUST be of type `HUMAN`, except for a human decision demonstrating the absence of business impact.

### 17.4 States

Allowed states:

```text
TO TEST
PASS
FAIL
N/A
```

Transitioning to `N/A` requires:

- a human decision;
- an entry in the ledger.

### 17.5 Gate AUTO

```markdown
## G-001-001 — Build succeeds

Type: AUTO
Status: TO TEST
Defined at: 2026-09-24T10:00:00

Condition:
The build completes successfully.

Method:
dotnet build -m:1

Tested at:
Evaluated result:
Result:
Evidence:
```

### 17.6 Gate LLM

```markdown
## G-001-002 — Rules consistency

Type: LLM
Status: TO TEST
Defined at: 2026-09-24T10:00:00

Condition:
No active requirement contradicts an active rule.

Evaluated at:
Evaluated result:
Evaluator:
Rationale:
```

An LLM gate MUST retain:

- a concise justification;
- model identification when available.

### 17.7 Gate HUMAN

```markdown
## G-001-003 — User journey validation

Type: HUMAN
Status: TO TEST
Defined at: 2026-09-24T10:00:00

Condition:
The user journey is accepted.

Validated at:
Validated by:
Evaluated result:
Comment:
```

To obtain `PASS`, a HUMAN gate MUST contain:

- a timestamp;
- the human's name.

The comment and evidence are optional.

An LLM MUST NOT declare a HUMAN gate satisfied.

### 17.8 Test History

A `FAIL` gate MAY become `TO TEST` again, then `PASS`.

A `PASS` gate whose validation is no longer applicable MUST return to `TO TEST` per section 17.10.

Previous attempts MUST be retained in a section:

```markdown
### Test history
```

Before any reset or new evaluation, the previous verdict, its date, identification of the evaluated result, available evidence or justifications, and the validator's identity when required MUST be retained in this history. This obligation also applies to successful attempts.

### 17.9 Active, Obsolete, and Inapplicable Gates

An active gate is a closure condition that has not been removed or superseded by obsolescence. Only active gates participate in the current verdict.

| Situation | Effect on Closure |
|---|---|
| Active gate `PASS`, validation still applicable | Condition satisfied. |
| Active gate `N/A`, with applicable human decision | Condition declared inapplicable. |
| Active gate `TO TEST` or `FAIL` | Closure prohibited. |
| Obsolete gate | Retained for history; excluded from current verdict. |

Removal or replacement of a gate MUST retain its definition and history, apply the marking of section 9, and, after startup, reference the ledger decision. A replacement MUST use a new identifier and reciprocal references. Removal without replacement MUST indicate the reason.

The `[OBSOLETE]` marking is distinct from the gate's `Status` field; it does not constitute a fifth verdict.

A `N/A` gate remains active. Its decision MUST specify the reason and conditions of inapplicability. Removal of a gate and its transition to `N/A` MUST NOT be confused.

### 17.10 Validity After Modification

Any modification of a result, requirement, applicable rule, or validation condition likely to affect an acquired validation MUST trigger an impact review.

This review MUST be briefly recorded in `GATES`, directly or by reference to a decision documenting this impact. Affected gates MUST return to `TO TEST` after retaining their previous results. If the impact cannot be determined, all active gates other than `N/A` gates whose decision remains applicable MUST be re-evaluated.

Maintaining a `PASS` following an examined modification MUST be justified. An affected HUMAN validation MUST be obtained again from a human; technical justification cannot substitute for it.

The applicability of `N/A` decisions MUST also be re-examined. If their conditions are no longer met, the concerned gates MUST return to `TO TEST`. A new transition to `N/A` requires a new human decision recorded in the ledger.

If these operations render an active gate `TO TEST` or `FAIL` while the lot is `Ready-to-close`, the lot MUST return to `In-progress` before proceeding with work.

### 17.11 Identification of Evaluated Result

Each evaluation MUST sufficiently identify the examined result to determine what the verdict concerns and whether it remains applicable to the result presented at closure.

This identification MUST be retained in `GATES`, directly or by reference. The `Evaluated result` field MAY designate a document version, a named delivery, a retained copy, or a revision when the project uses a version control system. Multiple gates concerning the same result MAY reference a common identification.

A path designating content susceptible to change is not sufficient on its own to distinguish successive results.

This obligation imposes neither Git, nor cryptographic hash, nor complete archiving for every attempt. The project chooses a proportional means allowing distinction of actually evaluated results.

## 18. `CONVERGENCE-xxx.md`

### 18.1 Responsibility

`CONVERGENCE` certifies the closure of a lot.

It compares:

- the active requirements of the spec;
- the actual result;
- the visible evolutions of intention in the spec;
- the essential elements of the findings;
- the essential results of the gates.

It does not copy either the spec, the findings, or the gates.

For each active requirement, convergence MUST allow establishing that it is satisfied or that a precisely identified gap has been accepted by a referenced human decision.

Identifiers grouped with a common conclusion MAY suffice. An exhaustive matrix and duplication of the text of requirements are not required. An active requirement MUST NOT be omitted from this review.

The section `Result obtained` MUST identify the finally accepted result and allow it to be reconciled with the results evaluated in `GATES` according to section 17.11.

### 18.2 Minimal Sections

```markdown
# Convergence — LOT-001

> Before working on this lot, read the repository root README.md.

Closed at: 2026-09-24T16:00:00
Closed by: Alice Martin
Decision: None
Convergence: TOTAL

## Result obtained
## Differences from active requirements
## Essential gate results
## Findings disposition
## Residual work
## Closure decision
## Historical convergences
```

### 18.3 Levels

Allowed values:

```text
TOTAL
PARTIAL
```

`TOTAL` means that all active requirements are satisfied.

`PARTIAL` means that at least one gap has been accepted by a human.

A partial convergence requires an entry in the ledger containing:

- the decision;
- the reason;
- the date;
- the identity of the human.

An unaccepted divergence prohibits closure.

The acceptance of a gap and a `PARTIAL` convergence MUST NOT neutralize an active gate `FAIL` or `TO TEST`. The closure conditions of section 17.9 remain applicable.

### 18.4 Closure Decision

An ordinary total closure does not require an entry in the ledger.

Other cases require an entry in the ledger.

This includes:

- a partial convergence;
- a gate declared `N/A`;
- a gap accepted during closure;
- any exceptional closure decision.

### 18.5 Stability

After closure, current convergence is stable.

It MUST NOT be modified until the lot is resumed.

If the lot becomes `Obsolete` or `Abandoned` without resumption, its convergence MUST be preserved without modification.

### 18.6 Resumption

When a closed, obsolete, or abandoned lot is resumed with modification:

1. all existing convergence MUST be read;
2. the resumption MUST be decided by a human and recorded in the ledger, after verification of the preconditions of section 19.3;
3. if a previous closure exists, the sections of its current closure MUST be copied without loss into a new entry of `Historical convergences`, then the current sections MUST be reset;
4. previous gate results MUST be preserved in `Test history`;
5. all applicable active gates MUST return to `TO TEST`, and `N/A` decisions MUST be re-examined according to section 17.10;
6. the lot returns to `In-progress` in `STATUS` after these preparations;
7. all applicable validations MUST be obtained again before a new closure.

A lot that became `Obsolete` before any closure MAY not possess convergence. In this case, a historical convergence MUST NOT be invented. A possible draft of convergence MUST be identified as such and preserved before its reset; it does not constitute a previous closure.

Each historical entry MUST retain at minimum:

- the former convergence level;
- the former closure date;
- the former closure owner;
- the former result;
- the former gaps;
- the former closure decision.

Entries already present in `Historical convergences` MUST remain unchanged.

### 18.7 Reactivation without modification

A lot `Abandoned` MAY become valid again without new validation if:

- no modification is made to the result;
- no new active rule invalidates it;
- a human explicitly decides reactivation;
- the ledger contains the motivation, identity, and date.

In this case:

- convergence is not reset;
- the lot becomes `Closed` again;
- gates are not replayed.

## 19. Lot States

### 19.1 Authorized States

```text
Draft
Planned
In-progress
Blocked
Stand-by
Ready-to-close
Closed
Cancelled
Obsolete
Abandoned
```

### 19.2 Meaning

| State | Meaning |
|---|---|
| `Draft` | Files in preparation. The lot is not yet recognized as planned. |
| `Planned` | Spec and gates defined. The lot may be started. |
| `In-progress` | Lot currently executing. |
| `Blocked` | Execution impossible until the blockage is resolved. |
| `Stand-by` | Parent lot suspended during execution of a sub-lot. |
| `Ready-to-close` | Work completed, active gates `PASS` still valid or `N/A` allowed. Human closure pending. |
| `Closed` | Lot closed after convergence and human decision. |
| `Cancelled` | Lot stopped before closure and not replaced. |
| `Obsolete` | Lot replaced, closed or not. |
| `Abandoned` | Previously closed result, subsequently abandoned without replacement. |

### 19.3 Normative Transition Table

This table defines authorized transitions. Any transition absent from the table MUST NOT be performed. The detailed procedures referenced complete its preconditions and effects; section 26 scenarios illustrate them.

Any transition MUST respect the sequentiality of section 20. Entry into a state occupying the active slot requires that slot to be free or already occupied by the same lot, except for coordinated transfer from parent to sub-lot.

`Ledger not required` means that the transition alone does not require a durable decision; any other necessary decisions remain subject to the protocol.

| Departure | Arrival | Preconditions | Human decision and ledger | Mandatory documentary effects |
|---|---|---|---|---|
| `Draft` | `Planned` | Identifier assigned, spec and gates defined; section 21.2. | Ledger not required. | Register the lot in `STATUS`. |
| `Planned` | `In-progress` | Bootstrap performed; slot available or parent/sub-lot transfer compliant with section 20.3. | Start decided by a human; ledger not required. | Update `STATUS` and, for a sub-lot, suspend its parent. |
| `In-progress` | `Blocked` | A blockage prevents execution. | Ledger not required to record the blockage. | Document the blockage, its release condition, and resumption information; update `STATUS`. |
| `Blocked` | `In-progress` | Release condition satisfied; necessary decisions obtained. | Ledger not required for this transition alone. | Update resumption information, examine impact on validations, and update `STATUS`. |
| `In-progress` | `Stand-by` | Start of a sub-lot identified and authorized by a human. | Ledger not required for the transfer alone. | Preserve parent resumption information; coordinate both states in `STATUS` per section 20.3. |
| `Stand-by` | `In-progress` | Sub-lot motivating suspension `Closed`, `Cancelled` or `Obsolete`; slot free. | Return decided by a human; ledger not required for this transition alone. | Examine sub-lot result and its impact on parent validations; update resumption information and `STATUS`. |
| `In-progress` | `Ready-to-close` | Work completed; all active gates `PASS` still valid or `N/A` allowed. | Ledger not required, except for decisions necessary to gates. | Verify gate results and decisions; update `STATUS`. |
| `Ready-to-close` | `In-progress` | Correction requested, closure refused, or validation became invalid. | Correction decisions per their nature; ledger not required for the return alone. | Record reason in concerned artifacts, handle affected validations, and update `STATUS`. |
| `Ready-to-close` | `Closed` | Closure procedure completed, no refusal cause. | Human acceptance; ledger in cases of section 18.4. | Finalize `CONVERGENCE`, complete approved updates, then update `STATUS`. |
| `Draft`, `Planned`, `In-progress`, `Blocked`, `Stand-by`, `Ready-to-close` | `Cancelled` | Stop before closure, without replacement, per section 19.6. For a suspended parent, exit of explicitly resolved sub-lot. | Human decision recorded in ledger. | Preserve files and register final state in `STATUS`, even for a draft absent until then. |
| `Draft`, `Planned`, `In-progress`, `Blocked`, `Stand-by`, `Ready-to-close`, `Closed` | `Obsolete` | Replacement identified. For a suspended parent, exit of explicitly resolved sub-lot. | Human decision recorded in ledger. | Preserve files and any convergence; establish replacement references and `STATUS` lines per section 9. |
| `Closed` | `Abandoned` | Result not retained, without replacement. | Motivated human decision recorded in ledger. | Preserve unchanged convergence; update `STATUS`. |
| `Closed`, `Obsolete`, `Abandoned` | `In-progress` | Resumption with modification; slot available or parent/sub-lot transfer authorized. For `Obsolete`, exit of explicitly resolved replacement. | Human decision recorded in ledger before application. | Prepare resumption per section 18.6, then update `STATUS`. |
| `Abandoned` | `Closed` | Result unchanged and no active applicable rule invalidates it; section 18.7. | Motivated, dated, and named human decision in ledger. | Preserve convergence and gates; update `STATUS` without new validation. |

### 19.4 Application of Work Transitions

A requested correction during closure MUST cause the lot to return to `In-progress`. If this correction reveals a blockage, the `In-progress → Blocked` transition is then applied.

An operation interrupted between multiple writes MUST be handled per section 22.8; it does not authorize an additional transition.

### 19.5 Conditions of Exceptional Transitions

Any cancellation, obsolescence, abandonment, resumption, or reactivation transition requires a human decision recorded in the ledger.

Cancellation or replacement from `Ready-to-close` is direct when table preconditions are satisfied; a prior return to `In-progress` is not necessary.

Resumption of an `Obsolete` lot MUST explicitly resolve the fate of its replacement and preserve immutable archives. There MUST remain only one active incarnation of the logical lot.

### 19.6 Cancellation, Obsolescence, and Abandonment

`Cancelled` means:

- the lot has not been closed;
- it will not be realized;
- it is not replaced.

`Obsolete` means:

- the lot is replaced;
- its replacement is indicated;
- the decision is in the ledger.

`Abandoned` means:

- the lot has been closed;
- its result is no longer retained;
- no lot replaces it;
- the reason is in the ledger.

No existing file must be destroyed.

A cancelled or obsolete lot before closure MAY not have convergence.

Existing convergence MUST be preserved.

## 20. Sequentiality

### 20.1 General rule and rationale for sequentiality

In each S.A.W. project, work packages are executed one after another.

This sequentiality results from the documentary workflow: in the nominal flow, a work package releases the slot to the next work package only after its closure. This closure imposes the examination of findings, the evaluation of all applicable gates, and the required human convergence and acceptance. Thus, sequentiality protects the continuity of intent, validations, and known state before proceeding.

The `Cancelled` and `Obsolete` outputs may also release the slot according to authorized transitions, but they constitute documented exceptional treatments. They MUST NOT be used to bypass a gate or simulate a nominal closure.

Only one work package MAY occupy the active work slot of this project.

The states occupying this slot are:

```text
In-progress
Blocked
Ready-to-close
```

Therefore, there MUST exist at most one work package of this project within the set of these three states.

A parent `Stand-by` constitutes the only normal suspension associated with this slot.

### 20.2 Blocking

A `Blocked` work package blocks the execution of all other work packages of the same project.

The process resumes when this work package becomes:

- `In-progress`;
- `Cancelled`;
- `Obsolete`.

### 20.3 Sub-work package

Starting a sub-work package places its parent in `Stand-by`.

Before this transfer, the parent MUST be `In-progress` and the sub-work package MUST satisfy the preconditions for its start or resumption. The suspended parent and the concerned sub-work package MUST be identifiable in `STATUS`.

The sub-work package becomes the unique `In-progress` work package.

The transition of the parent to `Stand-by` MUST be recorded before that of the sub-work package to `In-progress`. An interruption between these recordings falls under section 22.8.

After closure, cancellation, or obsolescence of the sub-work package, the return of the parent to `In-progress` is manual.

This return MUST wait for the active slot to be free and MUST include the examination of the effect of the sub-work package result on the parent's work and validations.

### 20.4 Scope of sequentiality

The active slot, blocking, and transitions of sections 19 and 20 are specific to a project. The simultaneous execution of multiple work packages of the same project remains out of scope of this version.

## 20 bis. Application and parallelism between projects

### 20 bis.1 Definition and architectural intention

The English term `Application` designates a set of S.A.W. projects that contribute to the same application. These projects MAY correspond to a feature, to an entire domain such as invoice entry or printing, or to a part of a feature. They do not need to be organizational projects nor distinct codebases. A project MAY also remain autonomous, without belonging to a documented Application.

The mere presence of a parent directory named Application does not make parallelism valid. When an Application is used to organize executable projects in parallel, it MUST express the intention, responsibilities, and coherence of this breakdown in its own Markdown artifacts.

A structured Application MUST be placed above the roots of its projects and must contain:

- `README.md`, work bootstrap at the Application scale;
- `APPLICATION.md`, nature, purpose, and scope of the Application;
- `RULES.md`, global rules applicable to member projects;
- `STATUS.md`, global tracking of project progress;
- `PROJECTS.md`, inventory, scopes, and paths of member projects;
- `LEDGER.md`, durable architectural and coordination decisions;
- `HISTORY.md`, journal of significant coordination operations.

`PROJECTS.md` MUST list all member projects of the Application. Each project name MUST be distinct in this list and each path MUST allow unambiguous identification of the root of the corresponding project. Each entry MUST specify its scope, responsibilities, and known dependencies.

Example organization:

```text
my-application/
├── README.md
├── APPLICATION.md
├── RULES.md
├── STATUS.md
├── PROJECTS.md
├── LEDGER.md
├── HISTORY.md
├── api/
│   ├── README.md
│   ├── PROJECT.md
│   └── ...
└── client/
    ├── README.md
    ├── PROJECT.md
    └── ...
```

In this example, `PROJECTS.md` could contain:

```markdown
| Project | Path | Scope |
|---|---|---|
| API | api/ | Application service and public interface |
| Client | client/ | User interface |
```

The Application's `README.md` answers the same question as a project README: how to work within the concerned scope. It MUST direct to `APPLICATION.md`, `RULES.md`, relevant decisions from `LEDGER.md`, `STATUS.md`, then to the concerned project. The `README.md` of each member project MUST begin by requesting reading of the Application's `README.md` before its local bootstrap.

The `RULES.md` of each member project MUST begin by requesting reading and application of the Application's `RULES.md`. It does not repeat global rules; it contains only local rules or clarifications and exceptions explicitly referenced. Each `SPEC` of a member project MUST begin by requesting reading of the Application's `README.md` and its project's `README.md`.

The Application's `STATUS.md` is a coordination view of projects and their dependencies; it MUST identify its update date or origin. It does not hold authority over the status of a lot: the `STATUS.md` of each project remains sole authority for its lots.

The Application does not possess lots. A gate, convergence, or truly cross-cutting delivery result MUST be governed by a distinct integration project, member of the Application, with its own artifacts and gates.

### 20 bis.2 Parallelism contract and simultaneous execution

Breaking down an Application into several S.A.W. projects allows simultaneous execution of lots belonging to different projects only when an identified architectural authority is able to guarantee that these projects can progress without incompatible risk. This guarantee MUST be inscribed in a decision of the Application's `LEDGER.md` before parallel startup.

This decision, called parallelism contract, MUST identify:

- scopes and responsibilities of each concerned project;
- their dependencies and interfaces;
- shared resources, files, or product zones;
- owner of each modifiable zone;
- justification of independence allowing simultaneous execution;
- coordination mechanism and conflict resolution when shared writing remains necessary.

Each possesses its own lots, identifiers, `STATUS.md`, decisions, and active slot. Uniqueness of identifiers is assessed within each project; a reference between projects SHOULD therefore specify the name of the source project and that of the target project.

The presence of a lot `In-progress`, `Blocked` or `Ready-to-close` in a project does not occupy the slot of another project. A blockage in a project does not automatically block lots of other projects. In each of them, the rule of a single active lot from sections 19 and 20 continues to apply.

Dependencies, decisions, and shared resources touching several projects MUST be made explicit in the parallelism contract and referenced by artifacts of concerned projects. Application documents do not hold authority over the status of a lot or on a decision proper to a project.

Organization SHOULD avoid that several projects simultaneously modify the same product files. If this sharing is necessary, organizers MUST define and apply a coordination mechanism for file writes and conflict resolution before launching these works in parallel. They can, for example, use Git, compare differences, and merge modifications, or schedule file writes over time. This need results from their breakdown and shared resources; choice of mechanism belongs to them. S.A.W. imposes neither Git nor other coordination tool, nor effective simultaneous execution.

## 21. Creation of a lot

### 21.1 Physical draft

Physical creation MAY produce:

```text
SPEC-xxx.md
FINDINGS-xxx.md
GATES-xxx.md
```

`CONVERGENCE-xxx.md` is not necessary at this stage.

### 21.2 Recognized lot

The lot becomes `Planned` when:

- its identifier is assigned;
- its spec is sufficiently defined;
- its gates are defined;
- it is entered into `STATUS.md`.

Before that, it remains `Draft`.

### 21.3 Modification after startup

After `In-progress`:

- a correction without change of meaning does not require a decision;
- any change of meaning of the spec or gates requires a ledger decision;
- replaced information remains preserved.

## 22. Lifecycle

### 22.1 Bootstrap

The context is reconstructed in the order defined in `README.md`.

Before proceeding with work, inconsistencies that may affect intention, validations, or the lot state MUST be resolved according to section 22.8. The resumption information defined in section 13.4 MUST be consulted when they exist.

### 22.2 Intention

`SPEC` defines the expected result.

`GATES` defines closure conditions.

### 22.3 Execution

The lot moves to `In-progress` by human decision.

New knowledge is added to `FINDINGS`.

Intention changes are versioned in `SPEC`.

The effect of modifications on acquired validations MUST be examined according to section 17.10. The information necessary for an interruption or a transfer MUST be preserved according to section 13.4.

### 22.4 Validation

Each applicable active gate is evaluated according to its type and on an identified result.

A lot may become or remain `Ready-to-close` only if all its active gates are:

- `PASS` with a validation still applicable to the presented result;
- or `N/A` with a recorded human decision whose conditions remain fulfilled.

### 22.5 Convergence

Convergence compares active intention to the actual result.

It indicates `TOTAL` or `PARTIAL`.

It establishes the treatment of each active requirement, identifies the accepted result, and summarizes the gates as well as the destination of findings in accordance with section 18.1.

### 22.6 Capitalization

Before closure:

- all findings are examined and possess a terminal treatment compliant with section 16.5;
- durable decisions are recorded in the ledger;
- approved rules are updated;
- newly decided lots are created or planned;
- residual work is recorded.

### 22.7 Closure

Closure is always decided by a human.

After acceptance:

- `CONVERGENCE` is finalized;
- approved cross-cutting updates are written;
- `STATUS` moves the lot to `Closed`.

Any modification made during closure preparation MUST be subject to the same gate validity rules as during execution. Human acceptance MUST concern the result and discrepancies actually presented in the finalized convergence.

### 22.8 Interrupted Documentary Operations

A recorded decision does not, by itself, prove that all its documentary consequences have been applied.

For an operation involving multiple entries:

1. the required human decision MUST be obtained and, when the protocol requires it, recorded in the ledger before its application;
2. contents and results to be preserved MUST be saved before their replacement or reset;
3. governed artifacts, references, and affected validations MUST be updated;
4. their consistency MUST be verified;
5. the state change attesting to the completion of the operation MUST be written in `STATUS` last among state and content artifacts; the result entry in `HISTORY.md` follows this verification.

A state permitting work resumption, such as `In-progress`, is recorded after required documentary preparations and before result modifications. Parent/child-lot transfers follow the special order of section 20.3.

When an operation has been interrupted, the executor MUST compare performed entries to the recorded decision and identify those that remain to be executed. If the decision unambiguously determines the continuation, the operation MUST be completed in accordance with this decision, without inventing a new one or requesting acceptance already documented.

If a required decision is absent, ambiguous, or incompatible with other artifacts, human clarification MUST be obtained before continuing dependent operations. A new durable decision MUST be recorded in the ledger when necessary. When no decision is required, an incomplete documentary entry MAY be completed from preserved facts and applicable rules, without inventing information.

`STATUS` remains the authority on the recorded state. An inconsistency with a convergence or a decision MUST NOT be resolved by erasing a prior validation, decision, or closure. Repair MUST preserve existing traces and respect authorized transitions.

This procedure requires manual reconciliation of information, without imposing a transactional mechanism nor a tool. Corresponding events SHOULD be recorded in `HISTORY.md` according to section 14 bis; the log does not replace artifact comparison.

## 23. Manual close procedure

The normative procedure is:

```text
1. Read the artifacts according to the bootstrap and resolve blocking inconsistencies.
2. Identify the presented result and active gates; verify withdrawals and replacements.
3. Verify the verdicts of applicable active AUTO gates.
4. Verify the evaluations of applicable active LLM gates.
5. Verify the validations of applicable active HUMAN gates.
6. Verify that the validations pertain to the presented result and remain valid; redo those that are necessary.
7. Refuse closure if an active gate remains TO TEST or FAIL.
8. Verify the decisions and non-applicability conditions of active N/A gates.
9. Establish, for each active requirement, its satisfaction or the deviation to be accepted.
10. Examine obsolete requirements and their replacements.
11. Examine each finding and prepare its terminal treatment as well as its destinations.
12. Prepare CONVERGENCE and qualify the convergence as TOTAL or PARTIAL.
13. Obtain the required human decisions and record them in the ledger.
14. Update RULES with the scope and consequences of approved evolutions.
15. Create or plan subsequent lots decided by the human.
16. Complete the treatment of findings; re-examine the effect of modifications on validations and deviations, then return to the concerned controls if necessary.
17. Verify the absence of a refusal cause and record Ready-to-close if that is not already the current state.
18. Present to the human the identified result, the convergence, and the associated decisions for acceptance of closure.
19. After acceptance, finalize CONVERGENCE and complete approved updates; verify their consistency.
20. Pass the lot to Closed in STATUS last.
```

The human MAY accept a deviation during closure.

This decision MUST be recorded in the ledger.

If the deviation requires a modification of the result, a `Ready-to-close` lot MUST return to `In-progress` before this modification. The affected gates MUST be treated according to section 17.10.

The human retains the final say on acceptance of the result. This acceptance MUST NOT bypass normative closure conditions.

## 24. Refusal to Close

The closure MUST be refused if:

- an active gate is `TO TEST` or `FAIL`;
- an active applicable HUMAN gate lacks identified and dated human validation;
- an active gate `N/A` does not possess its decision, or the conditions for that decision are no longer met;
- a gate withdrawal or replacement does not comply with mutation rules;
- acquired validation is no longer applicable to the presented result;
- the presented result or its relationship to evaluated results cannot be identified;
- an active requirement has not been examined;
- a nonconformity is neither corrected nor accepted;
- a finding remains `OPEN`, has not been examined, or does not possess terminal treatment and compliant destinations;
- a mandatory decision is missing;
- a documentary inconsistency affecting intent, validations, or lot status remains unresolved;
- convergence cannot be established.

After refusal, a `Ready-to-close` lot reverts to `In-progress`. A lot already `In-progress` remains so, or becomes `Blocked` if execution is impossible; a lot already `Blocked` remains so until the lifting condition is satisfied. These operations follow the table in section 19.3.

## 25. Role of the Human

The following operations are reserved for the human:

- significantly modify `PROJECT.md`;
- approve an evolution of `RULES.md`;
- decide on a change in meaning after the start of a lot;
- validate a HUMAN gate;
- declare a gate `N/A`;
- accept a deviation;
- accept partial convergence;
- create a lot from a finding;
- close a lot;
- cancel, replace, abandon or resume a lot.

Automation MAY prepare these operations.

It MUST request the human decision before making them effective.

## 26. Reference scenarios

These scenarios illustrate the normative table of section 19.3 and the associated procedures. Their abbreviated presentation does not exempt from the validity, traceability, and consistency checks required by the protocol.

### 26.1 Nominal lot

```text
1. Create SPEC, FINDINGS and GATES.
2. Complete SPEC and GATES.
3. Record the Planned lot.
4. Pass the lot In-progress.
5. Execute the work.
6. Record the findings.
7. Pass all active gates on an identified result.
8. Pass the lot Ready-to-close.
9. Prepare a TOTAL convergence.
10. Obtain human acceptance.
11. Finalize CONVERGENCE.
12. Pass the lot Closed.
```

No ledger closure entry is mandatory.

### 26.2 Finding producing a rule

```text
1. Create F-001-010.
2. Confirm the finding.
3. Obtain a human decision D-023 specifying the scope of the rule and the affected lots.
4. Mark the old rule [OBSOLETE], if necessary.
5. Create the new rule.
6. Reference D-023 in RULES.
7. Mark the finding PROMOTED TO LEDGER and PROMOTED TO RULE.
8. Summarize this destination in CONVERGENCE.
9. Apply to the concerned lots the decided follow-ups, notably the revalidation of affected gates.
```

### 26.3 Partial closure

```text
1. All active gates are still valid PASS or N/A authorized.
2. A discrepancy remains.
3. The human accepts the discrepancy.
4. The ledger receives the decision, the reason, the date and the identity.
5. CONVERGENCE indicates PARTIAL.
6. The residual work is described.
7. The human closes the lot.
```

### 26.4 sub-lot

```text
1. LOT-001 is In-progress.
2. The human creates LOT-001-002.
3. LOT-001 goes Stand-by.
4. LOT-001-002 becomes the unique lot In-progress.
5. LOT-001-002 is closed, cancelled or rendered obsolete.
6. After examination of the sub-lot result and its impact on parent validations, the human restores LOT-001 to In-progress if the slot is free.
```

### 26.5 Replaced lot

```text
1. The human decides replacement.
2. The ledger receives the decision.
3. Existing files and any convergence are preserved.
4. Reciprocal replacement references are added.
5. The active replacement uses the appropriate canonical path.
6. Consistency of artifacts and references is verified.
7. STATUS records the old lot Obsolete and the new documentary status of the replacement.
```

### 26.6 Resumption of a closed lot

```text
1. Read the old convergence.
2. Decide resumption in the ledger.
3. Move the previous convergence to Historical convergences.
4. Reset the current convergence.
5. Keep gate results in Test history, set applicable active gates back to TO TEST and re-examine N/A decisions.
6. Pass the lot In-progress when preparations are completed and the slot is available.
7. Perform the modifications.
8. Redo the validations.
9. Produce a new convergence.
10. Obtain a new human closure.
```

### 26.7 Reactivation without modification

```text
1. LOT-001 is Abandoned.
2. The human confirms that no modification is necessary.
3. Active rules are verified.
4. The ledger receives the motivated, dated and nominally signed decision.
5. Existing convergence remains unchanged.
6. LOT-001 becomes Closed again.
```

## 27. Compliance criteria for a project

Compliance with S.A.W. 3.2 requires adherence to all applicable normative obligations.

The following list constitutes a synthetic check and does not replace these obligations:

- the ten required artifact types are defined;
- the six required global artifacts exist, including `HISTORY.md`;
- each recognized lot possesses a spec, findings, and gates;
- each closed lot possesses a convergence;
- the bootstrap is explicit;
- the executable specification file of the applied method is copied to the project root;
- the `Protocol reference` section of `README.md` identifies the version and revision of the protocol, indicates that the project follows the method described in this file, and links to it via a direct Markdown link;
- an autonomous transmission contains the references and information necessary for resumption;
- identifiers are unique;
- obsolete information is preserved;
- durable decisions are in the ledger;
- significant operations are recorded by addition in `HISTORY.md` according to the chosen level of detail;
- human validations are identified and dated;
- evaluated and accepted results are identifiable and validations remain applicable;
- only active gates participate in the current verdict, with `N/A` decisions applicable when they are used;
- each active requirement is examined and each finding possesses a terminal treatment upon closure;
- the scope of rule evolutions and their effects on the existing are documented;
- no lot is closed automatically;
- authorized transitions and sequentiality are respected in each project, including when it belongs to an Application;
- any Application that authorizes parallelism possesses its required artifacts, a comprehensive inventory of its projects, and an approved parallelism contract;
- the global status of an Application is identifiable as a coordination view and does not contradict the authoritative statuses of projects;
- interrupted documentary operations are reconciled before continuing work that depends on them;
- the project remains usable without dependency on an agent, an IDE, or a version control system.

## 28. Out of scope for this version

This version does not define:

- parallel execution of lots within the same S.A.W. project;
- management of rights and human authorities;
- authentication;
- cryptographic signature;
- a version control system;
- an LLM provider;
- a graphical interface;
- a proprietary format.

## 29. Protocol Summary

```text
Read before acting.
Define the intention and the gates.
Execute a single lot at a time per S.A.W. project.
Preserve the findings.
Log changes of meaning.
Validate according to the nature of each gate.
Identify the evaluated result and re-examine validations after modification.
Compare the intention with the result.
Let the human decide.
Capitalize durable decisions.
Maintain a history proportional to the project's means.
Preserve information necessary for resumption.
Reconcile interrupted entries before continuing.
Do not silently destroy anything.
```