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.2: acceptance decision¶
| Field | Record |
|---|---|
| Date | 2026-10-16; approval time not recorded. |
| Responsible person | José Adrián Ruiz-Carmona, SCAFFOLD methodology owner; public Codeberg account kasailabs, as recorded for 0.1. |
| Decision and provenance | Explicit owner approval during review of the five proposals. This record preserves a summary without publishing the private conversation. |
| Edition | SCAFFOLD 0.2 — accepted. |
| Accepted scope | R-033–R-037: impact and evidence invalidation, runtime/infrastructure/code correspondence, compatible data migration, structural boundaries, and remote engineering connections. |
| Base | The 31 SCAFFOLD 0.1 requirements are incorporated by reference without changing their files or digests. Total for 0.2: 36 requirements. |
| Reference text | Additional requirements; Spanish is authoritative. Provisional IDs PROP-033–PROP-037 respectively become R-033–R-037. |
| Formalization | Approved text is expressed as records of actor, condition, obligation, evidence, limit, and residual risk; responsibilities and exceptions retain the base edition. No new thresholds or mandatory tools are introduced. |
| Integrity | reference/scaffold-accepted-0.2-sha256.json records digests of the Spanish text and this decision, included IDs, and an intact reference to 0.1. This is evidence of integrity, not cryptographic authentication of the approver. |
| Approval limits | Does not accept engineering or jurisdiction profiles, new axioms, translations as reviewed, implementations, certifications, or ASILO/MILPA amendments. R-017 remains pending and excluded. |
| Publication | Commit, push, tags, and portal deployment are not part of this methodological approval. |
Transition¶
A project declares whether it applies 0.1 or 0.2; directories or SDK installation do not determine the edition. Adoption of 0.2 assesses the five requirements under their conditions. Historical 0.1 outcomes retain their edition; changed inputs invalidate their use as current evidence without erasing the historical outcome. Both editions keep separate records.
Verification still needed¶
Acceptance does not prove working controls. Implementations need to map each requirement to checks and preserve real results. Identified priorities:
- Refactor: before/after behavioral evidence and relevant characterization cases tied to work and exact revisions; lower complexity does not prove equivalence.
- Operational quality: scenarios, environment, load, and measurements for nonfunctional goals; thresholds belong to the project or profile and are not universal.
- Remote access: test authorization, revocation, target and server identity, data sent to the model, and recovery from uncertain outcomes in an authorized environment.
These are implementation and evaluation tasks, not three more accepted requirements. No independent
review or real provider, remote access, or migration tests are claimed. Informative translations
retain review_status: pending until competent review.