Translation

Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.

SCAFFOLD 0.1: accepted edition

Human decision recorded: 13 October 2026. SCAFFOLD 0.1 is accepted as a methodology for engineering with assistants, alongside the accepted ASILO 0.1 and MILPA 0.1 editions. The decision comes from the explicit instruction received during the documentation review: SCAFFOLD must appear approved, like ASILO.

Edition scope

SCAFFOLD organises software projects built by people and assistants, from start-up to delivery: project charter and baseline survey, planned work and cadence, crews of people and agents, write zones, handoffs, batches, branches, environments, deployment, releases and measurement. Edition 0.1 includes 31 accepted requirements: SCAFFOLD-R-001 to SCAFFOLD-R-016 and SCAFFOLD-R-018 to SCAFFOLD-R-032, with their records and the handoff note format on the requirements page. Spanish is authoritative; English is an informative translation.

Accepting SCAFFOLD does not change ASILO 0.1 or MILPA 0.1 texts or exceptions. Declaring its use requires project evidence; this decision does not certify an implementation or claim widespread adoption in the industry.

Amendment outside the edition

SCAFFOLD-R-017 remains proposed and is excluded from the 31 requirements in force. It proposes an exception to MILPA-R-007 for systems that do not declare their end of a link. Accepting SCAFFOLD does not approve that change to MILPA: MILPA-R-007 retains its authority and its only current exception, for exploratory links. The ID is retained and will not be reused.

Edition completed — 14 October 2026

Human decision recorded: 14 October 2026. The owner instructed that SCAFFOLD be completed as a software project management method —framing from scratch or from the state the project is in, planned work, link with version control, branches, environments, deployment, releases and crews of people and agents— and be included in the first edition rather than opening another. Added are SCAFFOLD-R-019 to SCAFFOLD-R-032, the roles named by the records and the open formats of the project cycle. Requirements R-001 to R-016 and R-018 keep their wording; their "State and edition" field now records both dates. The registry reference/scaffold-accepted-0.1-sha256.json keeps the 13 Oct digests as a superseded revision, so that provenance is not lost.

Traceability and evolution

The initial classification as a candidate guide and the later description as “de facto” are superseded by this acceptance. The separate registry reference/scaffold-accepted-0.1-sha256.json fixes the edition, date, included IDs, exclusion and accepted page digests, separately from the historical ASILO/MILPA registries. A later normative change requires a human decision and an identified edition. This record documents the decision; it grants no authority to accept other editions.

See the methodology, requirements and history.