# S.A.W. 3.2 — Executable Specification

Version 3.2; normative revision `3.2.0-2026-09-27`. This document defines the S.A.W. (SDD Another Way) documentation protocol, replaces 3.1, and serves as a manual reference. `MUST` = obligation, `MUST NOT` = prohibition, `SHOULD`/`SHOULD NOT` = strong recommendation/adverse recommendation (justify any deviation), `MAY` = permission; these meanings apply regardless of language. Apply all relevant obligations; examples do not create exceptions. A project MUST remain usable with Markdown files alone, without agent, LLM provider, IDE, program, script, preset, Python, hardware, Git, branches, other version control system, or proprietary format imposed. The Markdowns hold authority; no indispensable rule may reside solely in a tool, plugin, hidden prompt, runtime, or prior conversation. A command/program MAY process the deterministic, an LLM semantic understanding, Markdown durable intention; business validation returns to the human. Automation MAY verify and prepare documentation operations, MUST NOT substitute for human decisions. It SHOULD remove more complexity than it adds.

## 1. Scope, Artifacts and Locations

A **S.A.W. project** is a documentary steering unit, regardless of its size: entire application, domain, function or other identifiable scope, without requiring a separate repository or organizational project. Each project has a documentary root and its own artifacts. Explicitly preserve intention, scope, rules, decisions, state, knowledge, validations and deviations. Each artifact answers its question; information SHOULD remain in its artifact and be referenced elsewhere rather than copied.

| Global Artifact | Role | Obligation |
|---|---|---|
| `README.md` | Working protocol, universal entry point | Required |
| `PROJECT.md` | Product, rationale and scope | Required |
| `RULES.md` | Active constraints | Required |
| `STATUS.md` | Current state of lots | Required |
| `LEDGER.md` | Enduring decisions and reasons | Required |
| `HISTORY.md` | Significant operations, actor and date | Required in this `-EXEC` version |

| Recognized Lot Artifact | Role |
|---|---|
| `SPEC-xxx.md` | Intention and requirements |
| `FINDINGS-xxx.md` | Acquired knowledge |
| `GATES-xxx.md` | Closure conditions |
| `CONVERGENCE-xxx.md` | Result, deviations and closure certification; MAY be absent before its preparation, MUST exist for a closed lot |

Place the six required global artifacts at the root, then each main lot under `Specs/<number>-<short-name>/` with its four canonical files; place a sub-lot under the parent folder in `<parent-number>-<child-number>-<short-name>/`. Also copy to the root the **executable** file of the applied version of S.A.W.; its name, version and revision MUST identify it without ambiguity. It is the distributed normative reference, without becoming an additional artifact type. Normative file names are in English. The short folder name SHOULD be descriptive, stable, lowercase with hyphens and independent of the lot state. The parent keeps its identifier: `LOT-001` MUST NOT become `LOT-001-000`.

## 2. Identifiers, references, dates and retention

Each identifier MUST be unique within its project and immutable; a withdrawn, cancelled or obsolete identifier MUST NOT be reused. The identifier is authoritative; the Markdown link is optional and a broken link does not invalidate it. Forms (`n` = digit, each numeric segment has three digits except `EVT` with six): `LOT-nnn`, sub-lot `LOT-nnn-nnn`, `REQ-<lot>-nnn`, `REQ-<lot>-<sub-lot>-nnn`, `F-<lot>-nnn`, `F-<lot>-<sub-lot>-nnn`, `G-<lot>-nnn`, `G-<lot>-<sub-lot>-nnn`, `D-nnn`, `R-nnn`, `EVT-nnnnnn` (only if the detailed format of `HISTORY` is chosen). An incarnation reference archived as `LOT-001-OBSOLETE-001` is unique, never reused and does not create a new logical identifier: that one remains `LOT-001`. Reference an object by its identifier (`Source: F-001-010`), with optional link.

Default timestamping: `YYYY-MM-DDTHH:mm:ss`. An international project SHOULD impose `YYYY-MM-DDTHH:mm:ss±HH:mm`; any choice different from the default MUST be recorded in `RULES.md`. Human validation requires a free-form name; several persons MAY appear, without imposed address, account or cryptographic signature. S.A.W. does not determine their authority.

Any element ceasing to be active MUST remain present with a title beginning with `[OBSOLETE]` (optional date: `[OBSOLETE YYYY-MM-DD]`). A replacement MUST bear `Replaced by: <id>` on the old one and `Replaces: <id>` on the new one; `Replaced by` is the normative form. Obsolete content MUST be retained and MUST NOT be rewritten, except for typographical correction without change of meaning. When completely replacing a lot document, keep the canonical name for the active one (`SPEC-001.md`) and successively archive `SPEC-001-OBSOLETE-001.md`, `...-002.md`; the suffix designates an archive, not a new lot. A genuinely different objective MUST receive a new `LOT`. A completely obsolete incarnation MAY be retained in `001-name-OBSOLETE-001/`; its files SHOULD bear the same suffix, the active replacement resumes the canonical path, and `STATUS` MUST contain a line for each recognized obsolete incarnation and for the active one. No existing file must be destroyed.

## 3. Bootstrap and global artifact contracts

`README.md` MUST remain the universal entry point and allow finding all applicable rules without conversation memory or unwritten local convention. Minimal sections: `# S.A.W. project protocol`, then `## 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`. Do not put detailed product definition, detailed technical rules, detailed lot status, or decision history there. `Protocol reference` MUST indicate applied version and revision, declare that the project follows the method described in the executable file copied to the root, and provide a direct Markdown link to it; an unidentified "current version" is insufficient. An autonomous transmission MUST include this specification and the documents necessary for bootstrap. Consult applicable procedures before execution; competence in the requested work may be assumed, but MUST NOT be assumed for unwritten local decisions or procedures.

For any work on a lot, read **in this order**: `README.md` → `PROJECT.md` → `RULES.md` → all **active** decisions of `LEDGER.md` → explicitly referenced obsolete decisions → `STATUS.md` → `SPEC` → `FINDINGS` → `GATES` → `CONVERGENCE` if present. Reading all active decisions is mandatory; an unreferenced obsolete decision MAY not be read in full. `HISTORY` is not in the usual bootstrap but SHOULD be consulted when chronology aids resumption, reconciliation, or audit. All lot artifacts MUST begin with a short reference to the root `README.md` (for example `> Before working on this lot, read the repository root README.md.`), without copying the bootstrap there.

`PROJECT.md` defines the product, why it exists and, in an Application, its contribution and its own scope. Minimal sections: `# Project`, then `## Purpose`, `## Problem`, `## Users and actors`, `## Scope`, `## Out of scope`, `## Stable functional characteristics`, `## Glossary`. It is very stable; MUST NOT contain lot status, current tasks, detailed technical choices, or decision history. Its elements have no default identifier, but MAY receive one for a stable reference. A significant modification is reserved for the human.

`RULES.md` contains active constraints (platforms, languages, runtimes, architecture, imposed/forbidden libraries, security, tests, conventions, dates). An initial rule does not require a ledger; form: `## R-nnn — Title`, `Status: ACTIVE`, `Source: Initial project rule`, `Rule: ...`, `Replaces: None`, `Replaced by: None`; `Rationale` optional. After initialization, any added or modified rule MUST reference a ledger decision; preserve the old text under `## [OBSOLETE date] R-...` with `Status: OBSOLETE`, `Replaced by: R-...`, `Decision: D-...`, and create the new rule `Status: ACTIVE`, `Source: D-...`, `Replaces: R-...`. For a finding: finding → human decision → ledger → old obsolete rule if needed → new active rule. Any evolution MUST specify its scope in the rule or its decision: future work, current lot, designated closed results, or all affected results. The decision MUST examine potentially affected lots, record follow-ups, and explicitly signal that no action is necessary if that is the finding. For ongoing lots, handle validations according to §7. A new rule MUST NOT automatically reopen a closed lot: identify any applicable incompatibility and its handling in the decision; resumption remains human (§8–9). Prior convergence remains unchanged until a resumption and attests to the original context.

`STATUS.md` is **the sole authority** on current lot status, without detailed history or tracking of persons/agents. Minimal table: `Lot reference | Parent | Title | Status | Replaced by | Comment`. A reference is the canonical identifier or that of an archived incarnation; register the lot as soon as `Planned` (a draft MAY be absent) and all recognized obsolete incarnations. Do not copy status as authority in any other artifact. Before interruption/transmission, artifacts MUST indicate available result and its location (or absence), known remaining work, blockages and their release conditions, and next action/decision; `STATUS` MUST give a current summary or references, possibly in a per-lot section. Reference rather than duplicate: causes in `FINDINGS`, validations in `GATES`, intention/dependencies in `SPEC`. Update this information when it changes; a single sentence is not an activity log.

`LEDGER.md` keeps only durable decisions and their reasons, not a logbook, problem/order list, or findings copy. Form: `## D-nnn — Title`; mandatory fields `Date`, `Decided by`, `Decision`, `Reason`; optional `Source`, `Related`, `Consequences`, `Replaces`, `Replaced by` (`Source: None` allowed for the initial). Multiple authorized decision-makers MAY be indicated. Another clause may make information mandatory even if its field is optional, notably the scope/consequences of a rule. A validated decision is immutable: a substantive correction creates a new decision, marks the old one `[OBSOLETE]`, and links the two; only a typographical correction without meaning change MAY be direct.

## 4. Operation History

`HISTORY.md` is **mandatory** in this `-EXEC` version: its absence MUST block planning, validation, and closing of a lot. It chronologically logs significant acts of the document project, without replacing `LEDGER`, `STATUS`, or other artifacts. Its existence and form SHOULD be announced in `README.md`. The executor MUST record therein creation/transitions of lots, evolution of requirement/rule/gate, decision/finding, validation, convergence, resumption/reconciliation; operations that are close MAY be grouped into a single intelligible entry; reads, searches, and commands without documentary effect MAY be omitted. It is not an exhaustive development log. The detailed format remains optional.

Detailed format MAY use `EVT-nnnnnn` in the title, then `Date`, `Actor`, `Operation`, `References`, `Documents`, `Decision`, `Outcome`, `Summary`: date per §2; actor = executor; references = objects; documents = paths relative to root; decision = ledger identifier or `None`; observed outcome (`Started`, `Applied`, `Interrupted`, `Reconciled`); summary MAY be brief. If `EVT`s are employed, they MUST be unique and SHOULD grow; correction/reconciliation SHOULD reference the concerned event. Keep entries by addition; a simple operation SHOULD be noted after application; for a compound operation, a start entry and a result entry are advised if the chosen level of detail permits it, while a manual summary record MAY note only the verified result. A `Started` without result calls for verification: compare artifacts per §10, without inferring the state from the log alone. An unwritten entry SHOULD prompt reconciliation without inventing historical date or actor. The log allows reconstruction of recorded facts, without guaranteeing capture of every edition nor old versions; archives, gate histories, convergences, and eventual versioning keep their contents per their rules.

## 5. SPEC and FINDINGS

`SPEC-xxx.md` defines the intent of the lot, without global rules, work logs, findings, gate results, or conclusion. Minimal structure: `# LOT-nnn — Title`; reference to root README; `## Objective`, `## Context`, `## In scope`, `## Out of scope`, `## Requirements`, `## Important cases`, `## Dependencies`, `## Known constraints`. `Parent` and `Created` are optional; `Status` MUST NOT be authoritative there. An active requirement has `### REQ-... — Title` followed by its normative text. Before `In-progress`, the spec MAY be completed without decision; after, cosmetic correction/without change of meaning MAY remain direct, but addition, removal, or change of meaning MUST reference a ledger decision, keep the old text visible and never reuse its identifier. The old requirement bears `[OBSOLETE date]`, `Replaced by: REQ-...`, `Decision: D-...`; the new one bears `Replaces: REQ-...`, `Decision: D-...`.

`FINDINGS-xxx.md` preserves knowledge, without automatically transforming a finding into a decision. Structure: `# Findings — LOT-...`; reference to README; each `## F-... — Title` bears `Status`, `Found at`, `Finding`, `Destinations`; `Evidence` and `Impact` are optional, author not required. States: `OPEN`, `RESOLVED LOCALLY`, `PROMOTED TO LEDGER`, `PROMOTED TO RULE`, `DEFERRED TO LOT`, `DISCARDED`. Several terminals MAY combine for several destinations; `OPEN` does not combine with terminal; `DISCARDED` does not combine with promotion and MUST give a reason. Cumulative destinations: `Local`, `Ledger: D-...`, `Rule: R-...`, `New lot: LOT-...`, `Discarded`. Creating a lot from a finding requires a human decision. `OPEN` does not automatically forbid `Ready-to-close`, but each finding MUST be examined and processed before closure: no `OPEN`, terminal states consistent with destinations, existing references, recipient lot at least `Planned`, local resolution sufficiently explained, motivated rejection. Processing of the finding must be completed; work of a subsequent lot MAY remain to be done, without dispensing from explicitly accepting any potential deviation from active requirements of the closed lot.

## 6. GATES: definition, verdicts, evidence

`GATES-xxx.md` defines closure conditions, without describing implementation or becoming a second spec. Create it with the lot; define the gates **before** `Planned`. After `In-progress`, addition, removal, or change of direction MUST reference a ledger decision. Exclusive types: `AUTO` (deterministic verdict, even when launched by agent/LLM), `LLM` (semantic analysis), `HUMAN` (human verdict). All business validation MUST be `HUMAN`, except for a human decision demonstrating the absence of business impact. Verdicts: `TO TEST`, `PASS`, `FAIL`, `N/A`. Moving to `N/A` requires a human decision recorded in the ledger; this decision MUST specify reason and conditions of non-applicability.

Each gate has `## G-... — Title`, `Type`, `Status`, `Defined at`, `Condition`. For `AUTO`, define `Method`, then retain `Tested at`, `Evaluated result`, `Result`, `Evidence`. For `LLM`, retain `Evaluated at`, `Evaluated result`, `Evaluator`, `Rationale`; a concise justification is mandatory, as well as identification of the model when available. For `HUMAN`, retain `Validated at`, `Validated by`, `Evaluated result`, `Comment`; `PASS` requires timestamp and human name, comment/evidence optional; an LLM MUST NOT declare it satisfied. Any evaluation MUST identify sufficiently the examined result to judge its validity at closure, in `GATES` or by reference: document version, named delivery, retained copy, or VCS revision may suffice; multiple gates MAY share an identification. A path to changing content alone does not distinguish two results. No Git, hash, or complete archiving is imposed: choose a proportional means.

An active gate (not removed/replaced) participates alone in the current verdict: `PASS` valid satisfied, `N/A` with applicable decision dispenses, `TO TEST`/`FAIL` prohibits closure; an obsolete gate is historical. `[OBSOLETE]` is not a fifth verdict. Removal/replacement MUST retain definition and history, apply §2 and, after startup, reference the ledger; a replacement MUST have new identifier and reciprocal links; a removal without replacement MUST be motivated. `N/A` remains active and must not be confused with removal.

A gate `FAIL` MAY become `TO TEST` then `PASS`. Before any reset **or new evaluation**, preserve in `### Test history` the previous verdict, its date, identification of the evaluated result, available evidence/justifications and validator identity if required, including for an old `PASS`. Any modification of the result, a requirement, an applicable rule or a validation condition that could affect an established result MUST trigger an impact examination briefly recorded in `GATES` or by referenced decision. Affected gates MUST return to `TO TEST` after archiving their results; if the impact is indeterminable, re-evaluate all active gates except `N/A` still applicable. Justify any `PASS` maintained after examination; an affected `HUMAN` validation MUST be redone by a human. Re-examine `N/A` decisions: if their conditions cease, return to `TO TEST`; a new `N/A` requires a new human decision in the ledger. If an active gate becomes `TO TEST`/`FAIL` during `Ready-to-close`, revert to `In-progress` before proceeding.

## 7. CONVERGENCE and closure

`CONVERGENCE-xxx.md` certifies closure by comparing active requirements, actual result, visible intention evolutions in `SPEC`, essential findings, and essential gate results, without copying these artifacts. For **each** active requirement, establish precise satisfaction or acceptable deviation referenced by human decision; grouped identifiers with common conclusion MAY suffice, without matrix nor exhaustive text copy. Identify in `Result obtained` the finally accepted result and align it with results evaluated in `GATES`. Minimal structure: `# Convergence — LOT-...`; reference to README; `Closed at`, `Closed by`, `Decision`, `Convergence`; `## Result obtained`, `## Differences from active requirements`, `## Essential gate results`, `## Findings disposition`, `## Residual work`, `## Closure decision`, `## Historical convergences`.

`Convergence` equals `TOTAL` if all active requirements are satisfied, `PARTIAL` if at least one deviation is accepted by human. A `PARTIAL` requires ledger entry with decision, reason, date, and human identity; an unaccepted deviation prohibits closure. No accepted deviation nor `PARTIAL` neutralizes `FAIL`/`TO TEST`. An ordinary total closure does not require ledger entry; `PARTIAL`, gate `N/A`, accepted deviation during closure, and any exceptional decision in requirement demand one. After closure, current stable convergence: MUST NOT modify it before resumption; keep it unchanged if lot `Obsolete`/`Abandoned` without resumption.

**Manual closure procedure, in this logical order:** (1) bootstrap and resolution of blocking inconsistencies; (2) identify presented result, active gates, withdrawals/replacements; (3) verify `AUTO`, `LLM`, `HUMAN`, validity of their results and decisions/conditions `N/A`, redo necessary validations and refuse if active gate `FAIL`/`TO TEST`; (4) examine each active requirement, obsolete ones and replacements, each finding and its destination; (5) prepare `CONVERGENCE` `TOTAL`/`PARTIAL`; (6) obtain necessary human decisions and record in ledger, update `RULES` with scope/consequences, create/schedule decided lots, complete findings and re-examine affected validations/deviations by resuming necessary controls; (7) verify absence of refusal, pass `Ready-to-close` if necessary; (8) present to human the identified result, convergence, and associated decisions, obtain his acceptance; (9) finalize `CONVERGENCE` and approved cross-referencing updates, control their consistency; (10) set `STATUS` to `Closed` **last**. Any modification during closure preparation follows gate validity rules; acceptance pertains to the result and deviations actually presented in finalized convergence. Human MAY accept a deviation during closure, with ledger decision; if deviation requires result modification, revert from `Ready-to-close` to `In-progress` before modifying and re-examining gates. Human acceptance MUST NOT bypass normative conditions.

Refuse closure if: active gate `TO TEST`/`FAIL`; gate `HUMAN` applicable without named and dated human; `N/A` without applicable decision; irregular gate mutation; invalid validation for presented result; result or link to evaluated results not identifiable; active requirement not examined; deviation neither corrected nor accepted; finding `OPEN`, not examined or without compliant treatment/destination; mandatory decision absent; relevant documentary inconsistency not resolved; convergence impossible. After refusal, `Ready-to-close` → `In-progress`; `In-progress` remains there or becomes `Blocked` if work impossible; `Blocked` remains there until unblocking, per §9.

## 8. Resumption, Reactivation and Capitalization

To resume **with modification** a lot `Closed`, `Obsolete` or `Abandoned`: read all convergence; obtain before application the human decision in the ledger and the preconditions of §9; if prior closure, copy without loss its current sections into a new entry `Historical convergences`, then reset the current sections; keep gate results in `Test history`, return all applicable active gates to `TO TEST`, re-examine `N/A` per §6; only then register `In-progress` in `STATUS`, modify, redo all applicable validations and obtain a new human closure. Obsolescence before closure MAY have no convergence: do not invent historical closure; identify and keep all drafts before reset. Each historical entry MUST retain at minimum old level, date, owner, result, deviations and closure decision; do not modify previous historical entries.

A lot `Abandoned` MAY become `Closed` **without modification nor new validation** only if the result is unchanged, no new active rule invalidates it and a human explicitly decides reactivation in the ledger with reason, date and identity. Keep convergence and gates; update `STATUS`.

Before closure, handle all findings, record durable decisions, update approved rules, create/schedule decided lots and register residual work. Reserved human decisions are: significant modification of `PROJECT`, evolution of `RULES`, change of meaning of spec/gates after startup, verdict `HUMAN`, `N/A`, acceptance of deviation/`PARTIAL`, lot created since finding, closure, cancellation, replacement, abandonment, resumption and reactivation. Automation MAY prepare them but MUST request human decision before making them effective.

## 9. States, transitions, and sequencing of a project

Allowed states: `Draft` (files in preparation, not planned), `Planned` (spec/gates defined), `In-progress` (execution), `Blocked` (execution impeded), `Stand-by` (parent suspended for sub-lot), `Ready-to-close` (work finished, gates valid, awaiting human closure), `Closed` (convergence and human acceptance), `Cancelled` (stopped before closure, without replacement), `Obsolete` (replaced, closed or not), `Abandoned` (result closed then discarded without replacement). **Only** the transitions below are permitted; any other MUST NOT be performed. Each transition respects the active slot, its preconditions, and the referenced procedures. "Ledger not required" does not exempt a decision required for another reason.

| Departure → Arrival | Preconditions, mandatory decisions, and effects |
|---|---|
| `Draft → Planned` | Identifier assigned, spec sufficiently defined and gates defined; ledger not required; enter into `STATUS`. |
| `Planned → In-progress` | Bootstrap completed, slot available or compliant transfer; start decided by human, no ledger for the transition; update `STATUS`, suspend parent if sub-lot. |
| `In-progress → Blocked` | Real blockage; ledger not required for recording; document cause, lift, and resumption, then `STATUS`. |
| `Blocked → In-progress` | Lift condition satisfied and necessary decisions obtained; ledger not required for transition; update resumption, examine validations, then `STATUS`. |
| `In-progress → Stand-by` | Sub-lot identified and start authorized by human; ledger not required for transfer; keep parent resumption and coordinate `STATUS`. |
| `Stand-by → In-progress` | Sub-lot responsible `Closed`/`Cancelled`/`Obsolete`, slot free; return decided by human, no ledger required for the transition; examine result/validations of parent, update resumption and `STATUS`. |
| `In-progress → Ready-to-close` | Work finished, all active gates `PASS` valid or `N/A` authorized; ledger not required except for gate decisions; verify and set `STATUS`. |
| `Ready-to-close → In-progress` | Correction, rejection, or invalid validation; correction decisions according to their nature, no ledger for return alone; record reason, process gates, and update `STATUS`. |
| `Ready-to-close → Closed` | Procedure completed and no cause of rejection; human acceptance, ledger per §7; finalize convergence and approved updates, then `STATUS`. |
| `Draft/Planned/In-progress/Blocked/Stand-by/Ready-to-close → Cancelled` | Stop before closure without replacement; explicitly resolve fate of sub-lot if parent suspended; human decision at ledger; keep files and enter final state into `STATUS`, even if draft absent until then. |
| `Draft/Planned/In-progress/Blocked/Stand-by/Ready-to-close/Closed → Obsolete` | Replacement identified; resolve sub-lot if parent suspended; human decision in ledger; keep files/convergence, link replacements and enter incarnations into `STATUS`. |
| `Closed → Abandoned` | Result not retained without replacement; motivated human decision at ledger; keep convergence unchanged, update `STATUS`. |
| `Closed/Obsolete/Abandoned → In-progress` | Resumption with modification, slot available/transfer authorized; if `Obsolete`, resolve fate of replacement; prior human decision at ledger; prepare §8, then `STATUS`. |
| `Abandoned → Closed` | Result unchanged, no active rule applicable invalidating; motivated, dated, and named human decision at ledger; keep convergence/gates and update `STATUS` without revalidation. |

A correction requested during closure MUST pass through `In-progress`, then optionally `Blocked`. An interrupted documentation operation follows §10 and creates no additional transition. Any cancellation, obsolescence, abandonment, resumption, or reactivation requires human decision at ledger. From `Ready-to-close`, cancellation or replacement may be direct. Resuming `Obsolete` MUST resolve the replacement, preserve archives, and leave only one active incarnation of the logical lot. `Cancelled` = not closed/not realized/without replacement; `Obsolete` = replaced with replacement and decision; `Abandoned` = closed then result not retained without replacement with reason. A cancelled/obsolete lot before closure MAY not have convergence; keep any existing convergence.

**Only one active slot per project**: at most one lot among `In-progress`, `Blocked`, `Ready-to-close`. The `Blocked` lot blocks all other lots of the same project until `In-progress`, `Cancelled`, or `Obsolete`. Nominally, the next lot awaits closure (findings treated, gates evaluated, convergence, human acceptance). `Cancelled`/`Obsolete` MAY also free the slot as documented exceptions, MUST NOT serve to bypass a gate or simulate a closure. `Stand-by` is the only normal suspension of the parent. To start a sub-lot, parent MUST be `In-progress`, sub-lot ready to start/resume and both identifiable in `STATUS`; enter **first** the parent `Stand-by`, **then** the sub-lot as sole `In-progress`; an interruption between entries follows §10. After closure/cancellation/obsolescence of the sub-lot, the return of the parent is manual, awaits a free slot, and examines the effect of the sub-lot on its work and its validations. No parallelism of lots within the same project is defined.

## 10. Creation, execution and interrupted writes

A physical draft MAY comprise `SPEC`, `FINDINGS`, `GATES` without convergence. The lot becomes `Planned` when an identifier is assigned, the spec is sufficiently defined, gates are defined, and registration in `STATUS`; before that, it remains `Draft`. After `In-progress`, correction without change of meaning does not require a decision; any modification of the meaning of `SPEC`/`GATES` requires a ledger decision and preservation of replaced information. Reconstruct context via bootstrap; before working, resolve inconsistencies touching intention, validations or state, and consult recovery information. The human decides startup; record new knowledge in `FINDINGS`, changes of intention in `SPEC`, re-examine validations after modification and maintain recovery information. Evaluate each active applicable gate according to its type on an identified result. `Ready-to-close` is possible and remains valid only with `PASS` applicable or `N/A` authorized for all active gates.

A recorded decision does not prove that its effects have been written. For any multi-write operation: **(1)** obtain the required human decision and record it in the ledger before application if required; **(2)** preserve prior contents/results before replacement/reinitialization; **(3)** update governed artifacts, references and affected validations; **(4)** verify consistency; **(5)** write in `STATUS` the state change attesting completion **last** among content and state, then the result entry in `HISTORY`. A state allowing recovery (`In-progress`) is recorded after documentary preparations and before modification of the result; for parent/sub-lot, respect order §9. In case of interruption, MUST compare writes to the decision and identify what is missing. If the decision clearly rules the continuation, MUST complete without new decision nor re-requesting already documented acceptance. If required decision absent, ambiguous or incompatible, obtain human clarification before dependent work and record a new durable decision if necessary; without required decision, MAY complete from preserved facts and applicable rules without inventing information. `STATUS` remains the recorded authority; never resolve an inconsistency by erasing old validation/decision/closure; preserve traces and authorized transitions. Manual reconciliation without imposed tool/transaction; record events in `HISTORY` according to §4 without taking it for sufficient proof of artifacts.

## 11. Application and parallelism between projects

An **Application** is a set of S.A.W. projects contributing to the same application (function, domain, or part of function), without requiring a separate repository or organizational project; a project MAY also be autonomous. A simple parent directory does not validate parallelism. A structured Application is above the roots of its projects and MUST possess `README.md` (global bootstrap), `APPLICATION.md` (nature/purpose/scope), `RULES.md` (global rules), `STATUS.md` (project tracking), `PROJECTS.md` (inventory/scopes/paths), `LEDGER.md` (architectural decisions and coordination) and `HISTORY.md` (significant coordination operations, per §4). `PROJECTS.md` MUST list **all** members with distinct name, unambiguous path, scope, responsibilities, and known dependencies.

The Application README MUST direct to `APPLICATION`, `RULES`, relevant decisions of its `LEDGER`, `STATUS`, then the project. The README of each member project MUST begin by requesting reading of the Application README before local bootstrap; its `RULES` MUST begin by requesting reading and applying the global `RULES`, without copying them, and keep only local rules or explicit references/exceptions to clarifications. Each member `SPEC` MUST begin by requesting reading of the Application README and that of the project. The Application `STATUS` is a coordination view of projects/dependencies with update date or origin; the project-only `STATUS` is authoritative for its lots. The Application does not possess lots: gate, convergence, or cross-project delivery MUST be governed by an integration member project with its own artifacts/gates.

Two member projects MAY execute their lots simultaneously **only** if an identified architectural authority guarantees their progression without incompatible risk and prescribes **before** parallelism a decision in the Application `LEDGER`: the **parallelism contract**. It MUST identify, for each concerned project, scope/responsibilities, dependencies/interfaces, shared product files/zones/resources, owner of each modifiable zone, justification of independence, coordination, and conflict resolution if shared writing. Each project keeps its lots, identifiers, `STATUS`, decisions, and slot; identifier uniqueness is local to the project, so inter-project references SHOULD name source and target. An active/blocked/ready-to-close lot in a project does not occupy another's slot and its blocking does not automatically block others. Dependencies, decisions, and common resources MUST be explicit in the contract and referenced in concerned projects; Application documents do not hold authority over state/decisions proper to a project. Simultaneous modifications of the same product files SHOULD be avoided; if indispensable, define and apply **before** parallel work a coordination mechanism for writings and conflict resolution (free tool, Git optional). No effective parallelism nor tool is imposed.

## 12. Compliance Verification and Limits

A compliant project respects **all** applicable obligations above, notably: six required global artifacts including `HISTORY.md` even for a very small project, the four lot types (convergence for every closed lot), bootstrap and versioned local executable reference linked directly in README, autonomous transmission and documented resumption, unique identifiers, retention of obsolete items, durable decisions on the ledger, significant operations added to `HISTORY` per §4, dated/nominal human validations, identifiable evaluated/accepted results, only active gates counted with `N/A` decided, examination of each active requirement and terminal handling of each finding, scope/effects of rules, human closure, transitions/sequentiality, reconciliation of interruptions, independence of tools. An Application enabling parallelism requires its artifacts, exhaustive inventory and approved contract; its global status must remain a consistent coordination view with the authoritative statuses of projects. This summary does not replace any preceding clause.

Outside the scope of 3.2: lot parallelism within a project, management of rights/human authorities, authentication, cryptographic signature, VCS, LLM provider, graphical interface and proprietary format. Execution rule: read before acting, define intention/gates, execute one lot at a time per project, retain findings and meaning changes, validate each gate on an identifiable result, compare intention/result, have the human decide, capitalize, document resumption, reconcile any interruption and do not silently destroy anything.