Skip to content

Translation

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

SCAFFOLD — Project cycle

In brief. This page walks through a software project from beginning to end in seven moments: starting up, planning, organising people and agents, building, integrating, delivering, and operating and learning. For each moment it says what is done, what remains as a reviewable output, which SCAFFOLD 0.1 requirements apply and who decides. It also explains where to enter if the project does not start from scratch. The page explains; the rule is in the requirements.

Certainty level (MILPA): what each requirement describes is an accepted rule; the order of the moments, the examples and the analogy are editorial presentation. There is no measured evidence that this route reduces errors or lead times (hypothesis, no source).

Who it is for and first step

For whoever coordinates a software project in which people, AI assistants or both work (see AI scope). First step: decide where to enter (section "Where to start") and read the moment that applies. The terms batch, handoff note and write zone are in the SCAFFOLD overview and in the vocabulary.

The construction-site analogy

SCAFFOLD is already explained with a scaffold. This cycle extends that image to the whole building site; it is an editorial correspondence.

Construction-site image Editorial correspondence Observable practice
Work order: what is built, for whom, who answers for it. Project charter. Document with goal, scope, owners and success criterion.
Survey of what is built: measuring what exists before intervening. Baseline survey of the existing project. Dated inventory, each item marked as a fact with a source or as a hypothesis.
Crews, each with a crew lead. Crews of people, of agents or mixed, with a responsible person. Crew record with members, zones and the supervisor of each agent.
Section of scaffold assigned to each crew. Write zone. Map of paths with owner.
Handover inspection: whoever commissioned the work checks and accepts what was built. Acceptance of what is done and authorisation of delivery. Record of the person who accepted and of the checks made.
Removing the scaffold before handing over the building. Exclusion of the engineering layer from the deployed artefact. Check on the built artefact (R-011).

Limit (DOC-AX-005). A civil construction site has permits, safety rules and legal responsibilities that this analogy neither describes nor replaces. A crew of agents is not a crew of workers: an agent holds no accountable role and the responsible person still answers (R-030). The image does not show that a control works, that time is saved or that the project is secure; those results need their own measurement.

Diagram

flowchart LR
  accTitle: Project cycle in SCAFFOLD
  accDescr: Seven moments in sequence, from starting up to operating and learning. Three dashed arrows send work back: from integrating to building, from operating and learning to planning, and from operating and learning to the charter.
  M1["1 Start up: charter or baseline survey"] --> M2["2 Plan: work list"]
  M2 --> M3["3 Organise: crews and assignment"]
  M3 --> M4["4 Build: batches and handoffs"]
  M4 --> M5["5 Integrate: branches and requests"]
  M5 --> M6["6 Deliver: environments and releases"]
  M6 --> M7["7 Operate and learn: measurement and incidents"]
  M5 -.->|"failed check or requested change"| M4
  M7 -.->|"actions as work items"| M2
  M7 -.->|"change of goal or scope"| M1

Editable Mermaid source.

How to read it. Each box is a moment. A solid arrow shows the usual sequence: what comes out of one moment is the input of the next. A dashed arrow shows a return: the work goes back to an earlier moment for the cause written on the arrow. Moments can overlap and repeat: while one item is delivered, another is built. The diagram does not impose a mandatory order and does not represent an implemented control. There is no colour legend: the information is in the text of the boxes and arrows.

The seven moments

1. Start up

  • What is done. What is built and who answers for it are agreed in writing. From scratch, the project charter is drafted. Over existing work, the baseline survey is made first. The start-up context that assistants will read is declared and, if there are several repositories, so is the root that coordinates them.
  • Reviewable output. Project charter with version and date, or dated baseline survey with facts and hypotheses separated; catalogue of critical effects; start-up context with references that exist.
  • Requirements. R-019 charter, R-020 baseline survey, R-004 start-up context, R-014 and R-015 composite projects.
  • Who decides. The product owner decides the charter and its changes; the technical owner answers for the baseline survey.

2. Plan

  • What is done. Work is recorded as work items in an ordered list, with acceptance criteria. The definition of ready, the definition of done and the cadence are declared. The details are in Work and cadence.
  • Reviewable output. Work list with complete items; versioned definitions; declared cadence.
  • Requirements. R-021, R-022, R-023, R-024.
  • Who decides. The product owner orders, accepts and discards; the coordination owner declares ready, done and cadence. An assistant may propose; it does not decide.

3. Organise people and agents

  • What is done. Crews are formed, the write zones of each are declared and each item is assigned to a responsible person, even if an agent executes it. The capacity of people is distinguished from that of agents. The detail on crews is in Crews.
  • Reviewable output. Record of each crew; zone map; assignments with an owner; capacity declared by type.
  • Requirements. R-030, R-031, R-001, R-003.
  • Who decides. The coordination owner.

4. Build

  • What is done. Each item is executed in one or more batches, with declared zones and assistants. When the assistant changes, a handoff note is left. Contracts and third-party dependencies are reviewed; an obsolete contract is not used in feature batches. Exploration, if enabled, is done separately and is either discarded or enters a formal batch.
  • Reviewable output. Batches with goal, owner, zones, interval, state, result and measured cost or "unknown"; handoff notes with state.
  • Requirements. R-009, R-002, R-005, R-006, R-007, R-008, R-016, R-018, R-012.
  • Who decides. The batch owner within their batch; the technical owner on contracts and dependencies.

5. Integrate

  • What is done. The change reaches the main branch through an integration request that cites the item or the batch, passes the declared checks and is reviewed by a person. An assistant does not write directly to the main branch.
  • Reviewable output. Declared branch convention; branches and requests with a reference to the item or batch; check results; human reviewer.
  • Requirements. R-025, R-026, R-010.
  • Who decides. The technical owner defines the branching model; a person reviews and integrates each request.

6. Deliver

  • What is done. The artefact that passed the checks is promoted between environments without being rebuilt; before production a rollback plan exists; each release carries a tag, notes and authorisation. Whatever serves only engineering stays out of the artefact. An urgency path, if one exists, was defined in advance. The detail is in Delivery.
  • Reviewable output. Declaration of environments; deployment record; rollback plan; tag and release note; exclusion check on the artefact.
  • Requirements. R-027, R-028, R-029, R-011, R-013.
  • Who decides. The delivery owner. Deploying to production is treated as a critical effect: a person authorises it, not an assistant (ASILO-R-005).

7. Operate and learn

  • What is done. The declared delivery indicators are measured. Each production incident and each rollback is reviewed with facts, probable causes as hypotheses and actions. The periodic review of finished work and the process improvement session are held.
  • Reviewable output. Indicators with a source; incident reviews; minutes of reviews and improvement sessions; work items created from the actions.
  • Requirements. R-032, R-024.
  • Who decides. The coordination owner, with the delivery owner for incidents.

Where to start

The cycle does not require starting at the first moment. The entry point depends on what already exists. The stages are not maturity levels; see adopting in parts.

Situation First step What follows
From scratch Draft the project charter (R-019) before opening the first feature batch. Work list, crews, first cycle.
From an existing repository Record the baseline survey (R-020): repositories, environments, checks, versions, owners, debt and work in progress. Project charter with what the survey shows; work items from the survey.
Midway through a project with work in progress Make the baseline survey and turn each piece of work in progress into a work item, or discard it with a reason. Order the list, declare cadence and definition of done; what is already integrated is not redone.
One person with one assistant (minimum viable) A short file with: short project charter (R-019), minimal work list (R-021), definition of done (R-023), declared cadence (R-024), simple branching model (R-026) and checks before integrating (R-010). One batch per task with declared zones, and result and checks recorded before integrating.

Notes by situation:

  • From scratch. The charter fixes goal, scope, exclusions, owners, catalogue of critical effects, data restrictions and an observable success criterion. A complete charter can describe the wrong goal (residual risk of R-019).
  • Existing repository. The baseline survey separates what was checked from what is assumed. What nobody remembers does not appear (residual risk of R-020): it is advisable to treat it as a hypothesis until verified.
  • Midway through a project. This is the most frequent case. An item already started enters the list in its real state (for example en_curso, in progress) and is not restarted. See the states in Work and cadence.
  • One person with one assistant. In a one-person project, that person holds all the roles in the records. A single assistant does not require creating crews (R-030 applies when the project works with crews, and the assistant keeps identity and scope under ASILO-R-004) or handoff notes: the note applies when the assistant changes within a batch. Everything fits in a single file. This minimum is an editorial reading of the requirements; each requirement keeps its application condition, and those that apply to every project (for example R-019, R-021, R-023, R-024 and R-026) remain in force. A cut-down version that omits an applicable requirement requires the recorded exception described by the common fields of requirements.en.md.

Continuing fictional example

Ana maintains an online shop with two assistants: one writes in src/ and the other in tests/. For moment 1 she drafts a charter (v1) whose observable success criterion is that the administration team downloads the month's orders. In moment 2 she creates the initiative "exports" and the item TIE-12, "export orders to CSV". In 3 she assigns TIE-12 to Ana as the responsible person even though the assistants execute it. In 4 she opens a feature batch that cites TIE-12. In 5 the branch and the integration request cite TIE-12 and Ana reviews before integrating. In 6 she authorises the deployment after seeing the checks. In 7 the incident of a CSV with the wrong encoding produces a review and a new item, TIE-19. All data are fictional.

Limits

  • This page adds no requirements and does not modify the accepted ones. Closing a batch, finishing an item or deploying records a fact; it does not by itself approve the quality of the result.
  • The moments describe a software project; using AI without building software is outside SCAFFOLD's scope.
  • This page contains no evidence of adoption, savings, security or compliance.
  • Correspondences and differences with other work frameworks (for example Scrum) are in Work and cadence.

Further reading: Work and cadence, Crews, Delivery, Templates. Back to SCAFFOLD.