Accepted edition — 13 Oct 2026; completed on 14 Oct 2026. Thirty-one requirements are in force:
SCAFFOLD-R-001 to SCAFFOLD-R-016 and SCAFFOLD-R-018 to SCAFFOLD-R-032.
Human acceptance decision.
Informative translation: the Spanish text is authoritative.
These fields apply to each accepted record below. The meaning of MUST, MUST NOT,
SHOULD and MAY follows the normative vocabulary,
adopted by SCAFFOLD 0.1 without changing ASILO or MILPA.
Field
Value
State and edition
accepted · SCAFFOLD 0.1 · R-001 to R-016 and R-018 since 13 Oct 2026; R-019 to R-032 since 14 Oct 2026.
Class
Technology-agnostic engineering requirement. R-019 to R-032 also cover software project management and are agnostic about tracking tools and code-hosting services.
General scope
People and assistants building software in repositories that declare SCAFFOLD 0.1. R-019 to R-032 also apply to the planning, integration and delivery of that software, by decision of the owner on 14 Oct 2026.
Exception
The human owner records reason, scope, duration, risks, rollback and review date. R-012 and R-013 define specific procedures; they do not exempt ASILO/MILPA. A departure from SHOULD records the reason and accepted risk.
Provenance
Own SCAFFOLD editorial corpus, consolidated into edition 0.1 by the recorded human decision. The Basis field records relationships with ASILO 0.1 and MILPA 0.1, not an amendment to them.
Acceptance evidence
Human decision and separate reference/scaffold-accepted-0.1-sha256.json registry in the method repository.
Future decisions
Revisions require a new identified edition and human decision; amendment R-017 remains outside this edition.
Each record adds its problem, application scope and condition, accountable human role,
verifiable statement, expected evidence, residual risk and basis. The project identifies
the people occupying these roles. A record is read together with these common fields.
Roles are responsibilities, not job titles. One person MAY hold several; in a one-person
project, that person holds all of them. An agent holds none.
Role
Answers for
Product owner
Goal, project charter, order of the work list and acceptance of what is done.
Coordination owner
Zones, cadence, crews, assignment and periodic review.
Technical owner
Architecture, contracts, branching model, dependencies and the technical baseline survey.
Delivery owner
Environments, artefact promotion, deployment, rollback and releases.
Batch owner
One specific batch: zones, assistants, handoffs and result.
Crew owner
A crew of people, of agents or mixed, and the supervision of its agents.
Records R-001 to R-018 name their actor by the task ("person responsible for…"). The
project states which role holds each one; if it does not, the coordination owner answers.
Startup with missing references or excessive context.
Scope and application condition
Initial context is prepared for a task with assistants.
Accountable actor
Task context owner.
Verifiable statement
The repository SHOULD declare a start-up context: the short list of current artefacts an assistant reads first. What it cites MUST exist. Each task remains subject to its own context budget, with maximum data classification and expiry.
Expected evidence
Entry list, existing references and that task’s budget.
Residual risk
A current artefact can contain incorrect information.
Basis
Related: the per-task context budget, which is not reused across tasks (ASILO-R-003). Adds: an entry catalogue each budget may include.
Person responsible for the batch, with giver and receiver identified.
Verifiable statement
When changing assistant within a batch, the giver MUST leave a handoff note with the fields of the guide and a state. A taken note MUST NOT be edited; if the goal changes, it is cancelled with a reason and another is opened. Changing tool grants neither permissions nor continuity.
Expected evidence
Note with complete fields, states, history and digest when taken.
Residual risk
A complete note may describe the real state incorrectly.
Basis
No accepted basis: the context guide describes the handoff as an explanatory technique, not a standard. Adds: obligation, state, taking by the receiver and no editing once taken.
Contract, architecture map and code MUST declare the version they correspond to, and the repository SHOULD be able to check that a change in one does not leave another outdated without warning.
Expected evidence
Corresponding versions and check result, or reason for departing from SHOULD.
Residual risk
Synchronised artefacts may share an error.
Basis
Related: links between projects with contract and version (MILPA-R-007); the dependency rule SHOULD be checked automatically when the profile allows it (ASILO-R-002). Adds: internal synchrony of one repository, with the same force as ASILO-R-002 for the check (SHOULD).
Work without a verifiable goal, boundaries or closure.
Scope and application condition
Work with assistants in the repository.
Accountable actor
Person responsible for the batch.
Verifiable statement
Work MUST be organised in batches of type feature, fix, restructuring or investigation, with goal, responsible person, zones, assistants, interval, state and result. Cost is recorded as data or as "unknown", never as a disguised estimate.
Expected evidence
Record with type, goal, owner, zones, assistants, interval, state, result and cost or unknown.
Residual risk
A complete record does not prove work quality.
Basis
Related: facts separated from hypotheses in reports used for decisions (MILPA-R-002); limits of cost, actions and time per automated execution (ASILO-R-007), which a batch does not replace. Adds: organisational unit, cost record and closing.
Integration without checks or a critical effect without a human decision.
Scope and application condition
Before integrating a batch or producing a catalogued critical effect.
Accountable actor
Person responsible for integration and the critical effect.
Verifiable statement
Before integrating a batch, the checks the repository declares MUST run. An assistant MUST NOT integrate or deploy by itself whatever the project's catalogue of critical effects includes; everything else follows the declared checks.
Expected evidence
Check results and informed confirmation for the critical effect.
Residual risk
Checks and human review may miss errors.
Basis
Related: ASILO-R-005 requires an explicit catalogue of critical effects whose minimum includes publishing or sending to third parties; deploying may fall there. Adds: checks per integration, and integration or deployment as explicit candidates for that catalogue. The human decision is limited to what is catalogued, because ASILO-R-005 warns that asking approval for everything leads to approving without reading.
Engineering configuration published inside the product.
Scope and application condition
An artefact is built for deployment.
Accountable actor
Person responsible for building and publishing.
Verifiable statement
Configuration exclusive to the engineering layer (zones, notes, batches, configuration of the coding assistants) MUST stay out of the deployed artefact, checked on the built artefact.
Expected evidence
Inventory and check of the built artefact establishing exclusion.
Residual risk
The inventory may miss files or embedded data.
Basis
No accepted basis. ASILO-R-002 asks to declare layers and their dependency rule, not to exclude files. Adds: checked exclusion.
Exploration that bypasses controls or becomes canonical without closure.
Scope and application condition
The project chooses to enable exploration mode.
Accountable actor
Person authorising exploration and its exit.
Verifiable statement
A project MAY declare an isolated exploration mode. Before it starts, it MUST identify the zone, synchrony and batch checks that may be suspended, their scope and duration, and the responsible person. Other SCAFFOLD requirements, ASILO/MILPA requirements, permissions, data limits and critical-effect review remain in force. Every result MUST be discarded or brought into a formal batch with the applicable checks before integration.
Expected evidence
Prior declaration of suspendible controls, boundaries and exit recorded as discard or formal batch.
Residual risk
Exploration isolation may fail.
Basis
Related: a separate place for non-canonical temporary material (MILPA-R-006) and exploratory links marked and unpublished (exception of MILPA-R-007). Adds: formal mode and its exit.
An urgency path is used to skip engineering checks.
Accountable actor
Person responsible for activation and later review.
Verifiable statement
An urgency path to skip engineering checks MUST be defined in advance, leave a record when used and end in a later review. It does not exempt the review ASILO-R-005 requires, before or after the fact according to that record's emergency exception.
Expected evidence
Prior procedure, usage record and later review, with the applicable ASILO-R-005 decision.
Residual risk
A later review cannot undo every effect.
Basis
Cites: emergency defined in advance (ASILO-R-005). Adds: the procedure for the engineering layer.
Writes across repositories without scope or contract.
Scope and application condition
A root coordinates several repositories.
Accountable actor
Person responsible for coordination across repositories.
Verifiable statement
The root of a composite project MUST declare which repositories it coordinates and through which contract they communicate. Writing into a child repository from the root MUST NOT happen except through a batch opened in that child.
Expected evidence
Child manifest, contracts and batches opened in the affected children.
Residual risk
Manifests may not reflect the real structure.
Basis
Cites: parent node in the manifest, inheritance outside 0.1 (MILPA-R-004); scope no wider than the invoker's (ASILO-R-004). Adds: direction of work between levels.
Root context absorbing code without a child batch.
Scope and application condition
A task is prepared in a composite root.
Accountable actor
Root context owner.
Verifiable statement
From the root, context MUST be limited to the children's manifests, contracts, maps and notes; their code enters through a batch in the child. Each root task remains subject to its own context budget.
Expected evidence
Root budget and source list; child batch for access to its code.
Residual risk
A manifest or note may expose unexpected information.
Basis
Cites: permitted sources per task (ASILO-R-003). Adds: default rule for the coordinating level.
Building without an agreed goal, scope or owners; each person or assistant infers the purpose on their own.
Scope and application condition
Every project that declares SCAFFOLD, whether starting from scratch or adopting the method over existing work.
Accountable actor
Product owner.
Verifiable statement
Before the first feature batch is opened, the project MUST have a project charter with goal, problem it solves, scope and exclusions, people responsible for product, coordination, technical matters and delivery, catalogue of critical effects, data restrictions and an observable success criterion. The charter MUST carry a version and a date; changing it MUST be recorded as a decision of the product owner.
Expected evidence
Charter with version, named owners, catalogue of critical effects and change history.
Residual risk
A complete charter may describe the wrong goal.
Basis
Cites: human owner and scope in the manifest (MILPA-R-004); catalogue of critical effects (ASILO-R-005). Adds: the charter as the starting point of planned work.
The method is adopted over an existing system without knowing what is there: planning rests on assumptions and decisions already made are reopened.
Scope and application condition
SCAFFOLD is adopted over a repository, product or project that already has code, users or commitments.
Accountable actor
Technical owner.
Verifiable statement
When adopting SCAFFOLD over existing work, the project MUST record a baseline survey with: inventory of repositories and environments, existing checks and their latest result, versions in use, known owners, known debt and risks, and work in progress. Each item MUST be marked as a fact with a source or as a hypothesis. Work in progress MUST become work items or be discarded with a reason.
Expected evidence
Dated survey, with facts and hypotheses separated, and work items created from it.
Residual risk
What nobody remembers does not appear in the survey.
Basis
Cites: facts, inferences and hypotheses kept separate (MILPA-R-002). Adds: the survey as an entry point from any moment of the project.
Work nobody asked for, no criterion for knowing when it is done, and no way to find out why it was done.
Scope and application condition
All planned work of the project.
Accountable actor
Product owner.
Verifiable statement
Planned work MUST be recorded as work items with a stable identifier, type, goal, verifiable acceptance criteria, responsible person, state, dependencies and a parent item or none. A feature or fix batch MUST cite at least one work item; an investigation or restructuring batch MAY be opened without one if it declares its reason. An identifier MUST NOT be reused.
Expected evidence
Work list with complete items and batches linked to them.
Residual risk
Well-written acceptance criteria may ask for the wrong thing.
Basis
Related: work batches (SCAFFOLD-R-009); dependencies between batches (SCAFFOLD-R-016). Adds: the work item as the planned unit, distinct from the batch that executes it.
An assistant, a tool or whoever arrives first decides what is built and in what order.
Scope and application condition
Planned work is ordered, accepted or discarded.
Accountable actor
Product owner.
Verifiable statement
The order of the work list, the acceptance of a finished item and its discarding MUST be decided by people with that declared role. An assistant MAY propose items, criteria and order; it MUST NOT reorder, accept or discard without a person's decision being recorded.
Expected evidence
History of ordering and acceptance with the person who decided.
Residual risk
A person may accept without reviewing.
Basis
Related: human review of critical effects (ASILO-R-005). Adds: priority and acceptance of work as human decisions.
Work that is unclear gets started, and work that is not finished gets declared done.
Scope and application condition
A work item goes into progress or is marked done.
Accountable actor
Coordination owner for the definition of ready and the definition of done; acceptance follows SCAFFOLD-R-022.
Verifiable statement
The project MUST declare a definition of ready to start and a definition of done, with a version. An item MUST NOT be marked done unless its acceptance criteria and the definition of done have been checked and a person has accepted it. The definition of done MUST include the repository's integration checks (SCAFFOLD-R-010).
Expected evidence
Versioned definitions and, for each finished item, the checks run and the person who accepted.
Residual risk
A weak definition of done lets incomplete work through.
Basis
No accepted basis in ASILO/MILPA. Adds: definition of ready and definition of done.
More work is opened than finished, the team does not synchronise and the same problems recur.
Scope and application condition
Every project with work in progress.
Accountable actor
Coordination owner.
Verifiable statement
The project MUST declare its cadence: fixed-length cycles or continuous flow. In continuous flow it MUST declare a work-in-progress limit per state or per person and crew. With any cadence, the project MUST declare how often it holds a review of finished work and a process improvement session, and hold them with date, participants and agreements recorded; each agreement SHOULD become a work item.
Expected evidence
Declared cadence, work-in-progress limits where they apply, and minutes of reviews and improvement sessions.
Residual risk
Meetings may be held without changing anything.
Basis
No accepted basis in ASILO/MILPA. Adds: cadence, work-in-progress limit and periodic review.
It is unknown which change implements which work, or which work a release includes.
Scope and application condition
Every work branch, committed change, integration request and release.
Accountable actor
Technical owner.
Verifiable statement
Every work branch and every integration request MUST cite the identifier of the work item or batch they implement. Every committed change MUST satisfy SCAFFOLD-R-003 in a machine-readable field. From a release it MUST be possible to obtain the list of work items it includes, and from an item, its changes.
Expected evidence
Declared naming convention, references in branches, changes and requests, and a query that lists items per release.
Residual risk
A reference may point to the wrong item.
Basis
Cites: attribution of changes (SCAFFOLD-R-003). Related: provenance (MILPA-R-001). Adds: two-way traceability between work, changes and releases.
Changes reach the main branch without review or checks, or branches live so long that integrating them becomes another project.
Scope and application condition
Repositories with version control where people or assistants work.
Accountable actor
Technical owner.
Verifiable statement
The repository MUST declare its branching model: main branch, branch types, who integrates and with which checks. The main branch MUST be protected: an assistant MUST NOT write to it without an integration request reviewed by a person. A work branch SHOULD belong to a single batch and have a declared maximum lifetime. Two assistants MUST NOT write to the same branch at the same time unless a turn is declared.
Expected evidence
Declared branching model; protection configured in the hosting service or, without a service, a declared rule and a check of the main branch history; age of open branches.
Residual risk
The protection may be disabled or have forgotten exceptions.
Basis
Cites: write zones and turn (SCAFFOLD-R-001); checks before integrating (SCAFFOLD-R-010). Adds: branching model and protection of the main branch. Reviewing an integration request is code review; it is not the confirmation of critical effects under ASILO-R-005, which remains reserved for what is catalogued.
Environments with no declared purpose: real data in testing, secrets shared between environments, deployments by whoever has access.
Scope and application condition
Every environment where the software runs: local, integration, testing, staging, production or others.
Accountable actor
Delivery owner.
Verifiable statement
The project MUST declare its environments with purpose, maximum data classification value admitted, origin of its secrets, who may deploy to it and entry checks. Classification uses a scale with a name and defined values (MILPA-R-003). An environment that uses secrets MUST have its own secrets, not shared with another environment. A non-production environment MUST NOT receive real data above its declared value except under a recorded exception. Deploying to production MUST appear in the catalogue of critical effects.
Expected evidence
Declaration of environments and deployment record with person and checks.
Residual risk
A copy of data may leave its environment by an undeclared route.
Basis
Cites: sensitive data and secrets (ASILO-R-006); critical effects (ASILO-R-005). Adds: declared environments and deployment to production as a critical effect; SCAFFOLD-R-010 already anticipated that the catalogue would include deployments.
What reaches production is not what was tested, and there is no known way back.
Scope and application condition
An artefact is promoted between environments or deployed.
Accountable actor
Delivery owner.
Verifiable statement
The artefact promoted between environments MUST be the same one that passed the checks, identified by its cryptographic digest, and MUST NOT be rebuilt per environment; per-environment configuration is injected separately. Before deploying to production, a rollback plan MUST exist. On deployment, version, digest, environment, the person who authorised it and the result MUST be recorded. If an urgency path (SCAFFOLD-R-013) deploys an artefact different from the checked one, it MUST record its digest and what was skipped, and the deployment enters the later review.
Expected evidence
Artefact digest at each promotion, rollback plan and deployment record.
Residual risk
A rollback may not undo data changes.
Basis
Related: exclusion of the engineering layer from the artefact (SCAFFOLD-R-011). Adds: artefact identity across environments and rollback.
Releases with no declared meaning and no record of what changed or who authorised it.
Scope and application condition
A version of the software is published or deployed.
Accountable actor
Delivery owner.
Verifiable statement
The project MUST declare its versioning scheme and which change requires bumping each component. Every published release MUST have an immutable tag in version control, release notes derived from its work items and from the batches without an item that it includes, incompatible changes flagged and the person who authorised it. Publishing to third parties follows the catalogue of critical effects (ASILO-R-005). A published tag MUST NOT be moved to another change.
Expected evidence
Declared scheme, tags, release notes and authorisation.
Residual risk
An incompatible change may go unflagged.
Basis
Related: links with contract and version (MILPA-R-007); version synchrony (SCAFFOLD-R-006). Adds: versioning scheme and release record.
Nobody answers for a group of agents, or a human team does not know what each assistant may do.
Scope and application condition
The project works with crews: teams of people, of agents or mixed.
Accountable actor
Coordination owner.
Verifiable statement
Each crew MUST declare its responsible person, members, write zones and the types of work it accepts. Each agent in a crew MUST have an agent profile with scope, per-run limits (ASILO-R-007) and a supervising person; that profile is not the project profile of MILPA-R-006. A crew made up only of agents MUST NOT accept work, order the work list, approve its own result or authorise a deployment.
Expected evidence
Record of each crew with owner, members, profiles and zones.
Residual risk
Declared supervision may not be exercised.
Basis
Cites: identity and scope of each agent (ASILO-R-004); budgets (ASILO-R-007). Adds: the crew as the unit of assignment with a human owner.
Work is assigned without knowing who will do it or whether it fits the available capacity; agent capacity is confused with that of people.
Scope and application condition
A work item or a batch is assigned.
Accountable actor
Coordination owner.
Verifiable statement
Every item in progress MUST have a responsible person even if an agent executes it. Planning MUST distinguish the capacity of people, measured in available time, from that of agents, limited by budget and by the human review their results require. An estimate MUST be recorded as an estimate, separate from measured data.
Expected evidence
Assignments with owner, declared capacity by type and estimates separated from data.
Residual risk
Human review may become the bottleneck without being measured.
Basis
Related: cost as data or "unknown" (SCAFFOLD-R-009); facts and hypotheses (MILPA-R-002). Adds: assignment and differentiated capacity.
The process is claimed to improve without being measured, and incidents are forgotten without anything changing.
Scope and application condition
Projects that deliver software to a production environment or publish it.
Accountable actor
Coordination owner, with the delivery owner for incidents.
Verifiable statement
The project MUST declare which delivery indicators it measures, how it obtains them and how often. Every production incident and every rollback MUST have a later review with facts, probable causes as hypotheses and actions; each action MUST become a work item. A claim of improvement MUST NOT be made without measurement before and after.
Expected evidence
Indicators with source, incident reviews and work items created from them.
Residual risk
An indicator can improve without the outcome improving.
Basis
Cites: facts, inferences and hypotheses (MILPA-R-002). Related: evaluation of AI failures (ASILO-R-008). Adds: delivery measurement and incident review.
State: proposed. It is not a requirement in force.
Proposed amendment to MILPA-R-007, which today requires every link to be declared at both ends. It was decided on 13 October 2026 to propose it; it is not accepted. If accepted: a link with a system that does not declare its end MUST be marked as external, with the other party's contract used and its version or capture date, and a handoff note MUST NOT have an external system as receiver. Until accepted, MILPA-R-007 applies with its existing exceptions.
Contradicts MILPA-R-007 as it stands (its only exception is exploratory links). Related: external content is untrusted (ASILO-R-001).
The Basis field in each record distinguishes Cites, Related and No accepted basis
in ASILO/MILPA. “No accepted basis” means the requirement is new to SCAFFOLD, not that it
lacks acceptance in SCAFFOLD 0.1. Its own acceptance does not transfer requirements to another method.
R-017 remains a proposed MILPA amendment requiring a separate decision.
SCAFFOLD-R-005 uses this open, product-independent field format, accepted in SCAFFOLD 0.1.
The explanatory context guide supplies the meaning of the referenced sections.
No particular serialisation, file extension or software product is required:
Field
Content
Identifier
Unique within the repository.
Giver and receiver
Who hands off and who receives.
Note state
abierta (open), tomada (taken), bloqueada_por (blocked by), cerrada (closed) or cancelada (cancelled). It is a scheme of its own; it does not convert into the state of a requirement, a link or a batch.
Blocked by
Identifier of another note, or none.
Origin
Note it comes from if it was returned, or none.
Expiry
Date, or not declared. It informs; it does not change the state by itself.
Goal, references and reviews, limits in force
The sections of the context guide.
Results; facts, inferences and hypotheses; decisions; next action
The sections of the context guide.
State history
Date, state, who and reason for each change.
Digest when taken
Cryptographic digest of the content the receiver read.
Closing a note says its work ended; it neither approves nor accepts its content.
Like the handoff note format, these formats are lists of fields, with no mandatory serialisation
or product. A task manager, a file in the repository or a spreadsheet can satisfy them. The
templates page shows them with a fictional example.
Format
Requirement
Minimum fields
Project charter
R-019
Version and date; goal; problem; scope and exclusions; owners for product, coordination, technical matters and delivery; catalogue of critical effects; data restrictions; observable success criterion; change history.
Baseline survey
R-020
Date; repositories and environments; checks and latest result; versions in use; owners; debt and risks; work in progress and its destination; each item as a fact with a source or as a hypothesis.
Work item
R-021
Identifier; type (iniciativa (initiative), función (feature), corrección (fix), reestructuración (restructuring), investigación (investigation) or another declared type); goal; acceptance criteria; owner; state; parent; dependencies; batches, branches, changes and release that implement it.
Item state
R-021, R-023
propuesto (proposed), listo (ready), en_curso (in progress), en_revisión (in review), terminado (done) or descartado (discarded). It is a scheme of its own: it is not the state of a batch, a note or a requirement.
Integration request
R-025, R-026
Item or batch; branch; responsible person; assistants involved; checks and result; human reviewer; critical effects it touches or none.
Deployment record
R-027, R-028
Version; artefact digest; environment; person who authorised; checks; rollback plan; result and time.
Release note
R-029
Version and tag; items included; incompatible changes; person who authorised; date.
Crew record
R-030
Name; owner; members, people and agents; profile, scope, budget and supervisor of each agent; zones; types of work it accepts.
Closing, finishing or deploying records a fact; it does not by itself approve the quality of the result.
Declaring zones does not stop a tool from writing outside them; a note can lie; a synchronised
contract can be wrong; a complete batch record can document bad work; a person can integrate
without reading. An ordered work list can be ordered badly; a definition of done can be weak; an
indicator can improve without the product improving. SCAFFOLD orders and makes visible; it does
not eliminate collisions, errors or hallucinations.