Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
description: SCAFFOLD manages software projects built by people and AI assistants, from framing to delivery: work, branches, environments, releases and crews.¶
SCAFFOLD — Software projects with people and AI assistants¶
SCAFFOLD is an approved methodology for managing software projects built by people and artificial intelligence (AI) assistants: one person with one assistant, a team with several assistants, or several crews of people and agents. It covers the whole project, from framing —from scratch or from wherever the project stands— to delivery and learning: project charter, planned work, cadence, crews, write zones, batches and handoffs, branches, environments, deployment and releases.
It answers practical questions: what is built and who decides, who does each task, who changes each path, how a task is linked to its changes and its release, how something reaches production and how it is rolled back, and what was learned.
Accepted edition: SCAFFOLD 0.2 — 16 Oct 2026. The acceptance decision identifies 36 requirements: the 31 from 0.1, retained by reference, and R-033–R-037. R-017 remains pending outside both editions. ASILO 0.1 and MILPA 0.1 retain their text and authority.
SCAFFOLD 0.2 introduces no new principles. Each requirement records its basis; new records formalize impact, runtime and infrastructure, migrations, structure, and remote connections. Spanish is authoritative; translations are informative.
The scaffolding analogy¶
A physical scaffold supports the builders while the work progresses and is removed when it ends. It shows where to climb, which section each crew works on and where material is left for the next shift. The finished building does not depend on the scaffolding.
Before the scaffold goes up there is a work order and, if the building already exists, a survey of what has been built. In software, the project charter is the work order; the baseline survey records what is already there; crews are the teams of people and agents; write zones say which section each one works on; the handoff note leaves the material for the next shift; the batch says what work is being done and when it ended; delivery to production is the handover of the works, authorised by a person. Under SCAFFOLD-R-011, none of that travels into the deployed system. The analogy explains; it does not show that a control works.
Scope and limits¶
- ASILO bounds data, permissions and effects. When an assistant acts as an agent with access to tools or data, identity and scope under ASILO-R-004 remain in force. SCAFFOLD organises construction with one AI assistant or several; each control retains its condition. Using AI without building software is outside SCAFFOLD’s scope.
- It does not replace the human review of critical effects in ASILO-R-005 nor the separation of facts and hypotheses in MILPA-R-002; it uses them.
- It does not replace Scrum, Kanban or a task manager: it defines what to record and who decides; each team chooses its cadence and tool (work and cadence).
- It does not promise lower consumption, fewer errors or no collisions. It orders and makes visible; any claim about savings or stability requires measurement.
How it relates to the other methods¶
| Method | Question | What SCAFFOLD takes from it |
|---|---|---|
| MILPA | What do we know, where does it come from and who answers for it? | Project manifest, restricted zones, links with contract and version, facts separated from hypotheses. |
| ASILO | What may an AI system do and how is it checked? | Scope of each agent, context budget per task, data and secrets, review of critical effects. |
| SCAFFOLD | How is software planned, built and delivered with people and assistants? | Adds charter and baseline survey, planned work and cadence, crews, write zones, handoffs, batches, branches, environments, releases, deployment exclusion and composite projects. |
Managing changes by jurisdiction¶
Adding or updating a localization is managed as project work: scope, work item, affected contracts, acceptance criteria, checks and integration. The change retains traceability to the delivered release and the relevant rollback plan. These are application examples for R-006, R-010, R-021, R-023 and R-025, subject to their conditions; they add neither requirements nor principles to SCAFFOLD 0.1.
The shared jurisdictional guide keeps one matrix and example for the three methods. Delivering regional changes explains versions, tests and artefacts. Accepting the work does not replace methodological acceptance of the profile, legal review or authorization of an operation.
Pieces of the method¶
| Piece | What it is | Possible check |
|---|---|---|
| Project charter | Goal, scope, owners, critical effects and success criterion, with a version. | That it exists before the first feature batch and that its changes have a recorded decision. |
| Work item | Planned work with an identifier, acceptance criteria, owner and state. | That every feature or fix batch cites one and that nothing is finished without human acceptance. |
| Crew | Team of people, of agents or mixed, with a human owner, zones and profiles. | That each agent has a scope, a budget and a supervisor. |
| Write zone | Paths an assistant changes; shared paths with a turn rule; restricted paths nobody changes. | Changes outside the zone flagged before committing. |
| Handoff note | Goal, references, limits in force, results, facts and hypotheses, decisions and next action; with a state. | Who took it, whether it changed after being taken, whether it expired, which other note it depends on. |
| Work batch | A feature, a fix, a restructuring or an investigation, with an owner, zones, assistants, interval and result. | A batch does not close before the one it depends on, nor with pending notes. |
| Start-up context | Short list of current artefacts an assistant reads first. | That what it cites exists and is current. |
| Branch and integration request | Short-lived branch per batch; request that cites the work and its checks. | That the main branch is protected and that work–change–release traceability works in both directions. |
| Environment and release | Declared environments; the same artefact promoted by digest; release with tag and notes. | Deployment record with authorisation and rollback plan. |
| Composite root | Folder that coordinates several repositories through their manifests and contracts. | That from the root manifests, contracts, maps and notes are read, not code, and that a declared inheritance is not presented as in effect. |
stateDiagram-v2
accTitle: SCAFFOLD: note and batch states
accDescr: Two state machines: a handoff note starts open (abierta), becomes taken (tomada) when the receiver takes it and closed (cerrada) when the work is finished, is blocked (bloqueada_por) while waiting for another note and returns to open when that one closes, and is cancelled (cancelada) with a reason from open or taken, or when returned. A work batch starts open (abierto) and ends either closed (cerrado), with a written result and nothing pending, or discarded (descartado) with a reason.
direction LR
state "Handoff note" as nota {
[*] --> abierta
abierta --> tomada: the receiver takes it
abierta --> bloqueada_por: waits for another note
bloqueada_por --> abierta: the other one closed
tomada --> cerrada: work finished
abierta --> cancelada: with a reason
tomada --> cancelada: with a reason or returned
}
state "Work batch" as lote {
[*] --> abierto
abierto --> cerrado: written result and nothing pending
abierto --> descartado: with a reason
}SVG (Scalable Vector Graphics) diagram: SCAFFOLD: note and batch states · Editable Mermaid source. State values stay in Spanish, as in the method's other classification values: abierta open, tomada taken, bloqueada_por blocked by, cerrada closed, cancelada cancelled; abierto open, cerrado closed, descartado discarded.
In SCAFFOLD 0.1, the note starts open and only its receiver takes it. A taken note is not edited: if the goal changes, it is cancelled with a reason and another one is opened. The receiver can return it to the giver with the reason, and both stay linked. A batch ends closed, with a written result, or discarded, with a reason. Closing neither approves nor accepts the content: it records that the work ended.
A small example¶
A fictional team works with two assistants on an online shop. The first writes in src/; the
second, in tests/. The file README.md is shared and the policies folder is restricted. A feature
batch is opened: "export orders to CSV" (comma-separated values), owned by Ana. The first assistant finishes the code and
leaves a handoff note to the second with what changed and what it did not check. The second takes
it, writes the tests, closes it, and Ana closes the batch with the result. Had the second found
that the orders contract does not accept the new field, it would have returned the note instead of
forcing the change.
The project cycle¶
| Moment | What is decided | Page |
|---|---|---|
| Start | Goal, scope, owners; baseline survey if work already exists. | Project cycle |
| Plan | What work, in what order, when it is ready and when it is done. | Work and cadence |
| Organise | Which crew does what and with what capacity. | Crews |
| Build | Zones, batches and handoffs. | This page and the requirements |
| Integrate and deliver | Branches, integration requests, environments, deployment and releases. | Branches, environments and releases |
| Operate and learn | Indicators, incidents and improvement. | Project cycle |
The templates show each format with a fictional example.
Applying it in stages¶
| Stage | Reviewable output |
|---|---|
| Write the charter or the survey | Versioned project charter; baseline survey if the project already exists. |
| Record the work | Work list with items, definition of done and cadence. |
| Declare zones | Zones file with an owner per path, shared and restricted paths. |
| Pass work with notes | Notes with state and a link to the batch. |
| Record batches | One batch per unit of work, with result and cost or "unknown". |
| Keep synchrony | Contract, architecture map and code with version and check. |
| Order branches and deliveries | Branching model, declared environments, deployment record and releases. |
| Separate what is deployed | Exclusion list checked on the built artefact. |
| Coordinate several repositories | Root declaration and reading by manifest. |
The stages are not maturity levels nor a mandatory order. Each team adopts what it needs (adopting in parts).
Next: project cycle, edition 0.1 requirements and vocabulary.
One person with one assistant can apply SCAFFOLD¶
A person asks an AI assistant to fix a function. They declare permitted paths, open a fix batch, prepare context for that task, and record the result and checks before integration. They hold all the roles: their charter fits in a paragraph and their work list in a file. They do not need to create other agents to apply the method. A handoff note is required when the assistant changes within a batch; coordination across owners and batch dependencies apply when those situations exist.
ASILO bounds data, permissions and effects according to its requirements; MILPA preserves provenance and authority. SCAFFOLD organises construction. See AI scope.
Engineering and artifact evidence¶
Proposed engineering profile and artifact verification guide: agnostic application, criteria, evidence and limits; no new universal requirements.