Status: accepted · 2026-10-16. The human decision
accepts R-033 through R-037. SCAFFOLD 0.2 comprises 36 requirements: the 31 from
SCAFFOLD 0.1, incorporated by reference without changing their text, and
the five below. R-017 remains excluded from both editions; ASILO 0.1 and MILPA 0.1 do not change.
Spanish is authoritative; translations are informative and human linguistic review is pending.
Technology-agnostic engineering requirements for software projects declaring SCAFFOLD 0.2. Multiple agents and AI in the final product are not required.
Provenance and authority
Five editorial proposals accepted by the methodology owner identified in the decision. reference/scaffold-accepted-0.2-sha256.json records scope, source, and digests.
Language
MUST, MUST NOT, SHOULD, and MAY retain the meaning adopted by SCAFFOLD 0.1 in its common fields; this edition does not amend the ASILO/MILPA normative-language document.
Exception
The human owner records reason, scope, duration, risks, recovery, and review date under the base edition. Engineering exceptions do not suspend ASILO permissions, secrets, or critical-effect review.
Applicability
Each requirement states its condition. “Not applicable” identifies the condition and reason; absent evidence or failed checks do not become “not applicable.”
Evolution
Changes to obligations, exceptions, or scope require a new human decision and identified edition. Method acceptance does not establish implementation conformance or independent review.
An artifact changes while tests or decisions based on the earlier revision still count as current.
Scope and condition
Artifacts with dependencies relevant to a project change: requirements, criteria, contracts, diagrams, components, configuration, migrations, and evidence.
Responsible actor
Technical owner for analysis; product owner for acceptance of affected work.
Verifiable formulation
Each artifact with relevant dependencies MUST declare a stable ID, revision or digest, authority, relationship type, and applicability. On change, the project MUST identify affected dependents and mark evidence based on changed inputs as stale. The current work revision MUST NOT be presented as complete until that evidence is regenerated or reviewed and acceptance required by R-022 and R-023 is obtained. A dashboard view MUST NOT keep an independent source of work state.
Expected evidence
Versioned references, declared relationships, impact report, invalidated evidence and its replacement or review. Prior history remains historical, not evidence of the current revision.
Check limits
A relationship declares a dependency, not proven semantic coverage. Unknown relationships are unevaluated; a digest does not decide meaning.
Residual risk
An incomplete graph can omit affected artifacts; coherent evidence can share an error.
Basis
Extends R-006; uses MILPA-R-001, R-007, and R-008 for authority, provenance, and visible contradictions.
Code, runtime configuration, and infrastructure rely on incompatible assumptions despite passing unit tests.
Scope and condition
Projects with deployment and runtime dependencies affecting operation.
Responsible actor
Technical and delivery owners.
Verifiable formulation
The project MUST declare relevant runtime dependencies: required and optional configuration, secret references without values, ports and network targets, resources and limits, health checks, runtime dependencies, and required operational properties. It MUST link them to code and deployment manifests, identifying revisions and environment. Declared integration checks MUST consider correspondence between those artifacts within their scope.
Expected evidence
Configuration, code, and deployment declarations and references; results of relevant variable, reference, connection, and limit checks, identifying tool, revision, and environment.
Check limits
Fields and values depend on service and environment; no universal technology or inventory is prescribed. Services without deployment record why this does not apply.
Residual risk
Declared correspondence may not represent effective configuration; static analysis can miss dynamic values.
Basis
Makes R-006, R-010, and R-027–R-028 concrete. Permissions, data, and secrets retain ASILO-R-004 and R-006.
Concurrent versions of code, jobs, events, and data become incompatible during deployment or rollback.
Scope and condition
Changes to persistent data or its schemas.
Responsible actor
Technical, data, and delivery owners; the project identifies who holds each responsibility.
Verifiable formulation
The change MUST declare backward and forward compatibility with versions that may coexist, data effects, migration strategy, verification, recovery, and conditions for retiring old structures. If it cannot be atomic and compatible, it MUST define a dependent work sequence and MUST NOT retire the previous structure before observable retirement conditions are met. An irreversible migration MUST have an explicit recovery strategy and human risk acceptance.
Expected evidence
Coexisting versions and compatibility matrix, work sequence, migration and data checks, retirement conditions, and recovery or rollback evidence.
Check limits
Expand-contract is an option. No engine, batch size, stability period, or universal zero-downtime promise is imposed.
Residual risk
Keeping an old column is insufficient for rollback if writes stopped; restoring data may lose later changes. Real locks and load can differ from tests.
Basis
Makes R-010, R-016, and R-028 concrete; retains ASILO critical-effect review and data limits.
Implementation violates domain, module, dependency, or data-flow boundaries despite matching API contracts.
Scope and condition
The project declares modules, layers, or trust boundaries.
Responsible actor
Technical owner.
Verifiable formulation
The project MUST identify owners, allowed dependencies, public interfaces, and forbidden relationships for declared boundaries. It MUST select checks appropriate to language and architecture to detect forbidden dependencies, cross-repository coupling, and drift in relevant diagrams. Where a relationship cannot be checked automatically, it MUST declare the limitation and review evidence.
Expected evidence
Boundary map and rules; check configuration and results, including rejection of a forbidden dependency; affected contracts and diagrams.
Check limits
AST checks, import rules, and architecture tests are options. DDD, hexagonal architecture, microservices, and universal naming rules are not required.
Residual risk
Static analysis and diagrams can miss dynamic dependencies or temporal effects; respecting boundaries does not prove internal correctness.
Basis
Makes R-006 and R-007 concrete; retains ASILO-R-002 layering and MILPA-R-007 links.
A local AI inherits remote credentials or permissions; repository zones do not contain server effects, and a local interface can send context to an external model.
Scope and condition
An AI-assisted engineering task connects to a server, including an inference server, or creates remote effects.
Responsible actor
Technical owner declares targets and scope; environment owner authorizes access; an authorized person decides critical effects under ASILO-R-005.
Verifiable formulation
The connection MUST link to the work item and declare origin, target, purpose, environment, protocol, and expected identity. It MUST distinguish the tool target from the model server. It MUST verify server identity using the protocol; mismatches MUST stop for review without disabling verification or silently accepting a new identity. It MUST declare session identity, capabilities, resources/paths, expiry, revocation, and limits; it MUST NOT inherit human access automatically or expand scope on a model request. It MUST declare authorized inbound/outbound data, treat remote responses as untrusted, and keep credentials out of model context and logs. It MUST check current authorization at the actual boundary before each action; critical effects retain approval of the specific target and object. Target, action, or scope changes MUST trigger authorization review. It MUST record task, context revision, environment/target, identity, operation, decision, date, and evidence with appropriate classification and retention. If disconnection leaves an outcome uncertain, it MUST reconcile state before retrying.
Expected evidence
Versioned configuration without credentials; tests of unauthorized targets, changed identity, revoked/expired sessions, writes under read-only access, malicious responses, absence of secrets, and retries after uncertain effects. Distinguishes simulation from controls tested in an authorized remote environment.
Check limits
VPN, tunnel, or an authorized connection does not grant other targets, port forwarding, elevation, or arbitrary commands. A Git hook cannot control completed actions. Human review for every connection and a specific proxy are not required.
Residual risk
Permitted effects can cause harm; apparently harmless responses can contain malicious instructions. A manifest does not prove effective containment.
Basis
Makes R-001, R-004, R-010, and R-027 concrete; applies ASILO-R-001 and R-003–R-007 under their conditions without amending them.
A project declares the edition it adopts. Adoption of 0.2 requires assessing these five
requirements under their conditions; historical outcomes under 0.1 do not become retroactive
violations. One person may hold existing human responsibilities under the base edition.
Horcón, SCAFFOLD Core, or another implementation may supply checks and adapters. Acceptance
does not assert that they exist. The decision record
identifies implementation and evaluation work still needed.