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.

Ecosystem problems and capabilities

This guide helps choose what to apply according to the problem. It explains ASILO 0.1, MILPA 0.1 and SCAFFOLD 0.2, without adding obligations or assessing products.

What each method contributes

Method Value proposition Organizing question
MILPA Knowledge with visible provenance, authority, structure and relationships. What do we know, where does it come from and how is it related?
ASILO Limits on data, context, permissions and effects, with residual-risk evaluation. What is permitted and how is it checked?
SCAFFOLD A software lifecycle with traceable intent, responsibilities, work, verification and delivery. How does intent become a verifiable delivery?

The three can be adopted in parts. An operational AI project may need ASILO and MILPA without agents developing software. SCAFFOLD coordinates engineering; its data and authority controls relate to the other methods without prescribing a specific tool.

Catalogue of major problems

IDs refer to the index of 52 accepted requirements: eight ASILO, eight MILPA and 36 SCAFFOLD. Summaries do not replace a full record's conditions, exceptions or normative force.

Case Problem Related requirements Contribution and limit
P01 Confusing rules with opinions MILPA-R-001/002/008 Visible sources, status, owner and contradictions.
P02 Excessive or stale context ASILO-R-003; SCAFFOLD-R-004/007/015 Bounded context and versioned contracts; a short reference does not establish freshness.
P03 Concurrent changes and unclear ownership SCAFFOLD-R-001/002/003/030/031 Zones, batches and owners; effective isolation depends on the environment.
P04 State lost between assistants SCAFFOLD-R-005/009/016 Stateful handoffs and acyclic work dependencies.
P05 Requirements, code and tests drifting apart SCAFFOLD-R-006/021/023/033 Link revisions and review affected evidence when a source changes.
P06 Hidden coupling between services MILPA-R-007; SCAFFOLD-R-007/014/036 Bilateral links, supplied contracts and checkable structural boundaries.
P07 Incompatible configuration and infrastructure SCAFFOLD-R-027/034 Compare declarations against code, environment and observed results.
P08 Unsafe migrations and recovery SCAFFOLD-R-028/035 Compatibility, coexistence and recovery according to the change and data engine.
P09 Overprivileged tools ASILO-R-001/004/005; SCAFFOLD-R-037 Identify actor and destination, authorize effects and test revocation.
P10 Unreviewed third-party dependencies SCAFFOLD-R-008; ASILO-R-008 Record changes, review and rationale; integrate suitable checkers.
P11 Hallucination, injection and sycophancy ASILO-R-001/008 Validate structure and measure failures with cases and baselines; these are distinct.
P12 Sensitive information exposure ASILO-R-003/006; MILPA-R-001 Classification, purpose, retention and context-specific egress controls.
P13 Work without purpose or acceptance SCAFFOLD-R-019/020/021/022/023 Charter, existing-system survey where applicable, criteria and human decisions.
P14 Overload and misleading progress SCAFFOLD-R-024/030/031/032 Cadence, an additional continuous-flow limit and separate human/agent capacity.
P15 Unbounded spending and retries ASILO-R-007; SCAFFOLD-R-009/032 Budgets, stopping and declared metrics; unknown cost stays unknown.
P16 Untraceable versions or deployments SCAFFOLD-R-025/026/027/028/029 Work-branch-integration-release links and promotion of the checked artifact.
P17 Refactoring that changes behavior SCAFFOLD-R-006/009/023/033/036 Declare invariants and relevant characterization tests; these are application techniques.
P18 Obsolete code and recurring incidents SCAFFOLD-R-013/018/032 Explicit retirement, a predeclared emergency path and post-incident actions.
P19 Localization confused with jurisdiction MILPA-R-001/003/005/007; ASILO-R-006; SCAFFOLD-R-034 Separate language, time zone, formatting, jurisdiction and source versions.
P20 Dashboards disconnected from evidence MILPA-R-007; SCAFFOLD-R-021/025/032/033 A declared source and traceable projections; a percentage alone does not prove delivered value.

From a rule to a checked result

For each problem, consider recording the requirement and edition, source revision, mechanism, environment, positive and negative tests, result, remaining risk and responsible person. Four states are distinct: accepted rule, implemented mechanism, executed verification and published distribution. None automatically implies the next.

For example, declaring DATABASE_URL does not establish that the service starts with deployment configuration. A test can record the code and manifest hashes, check a missing variable and the valid case without publishing its value. Evidence is invalidated or reviewed when its inputs change; the specific format belongs to the profile and software.

A diagram explains relationships, but valid syntax does not prove equivalence with code. A hook detects certain changes but does not itself confine the process. A signature associates bytes with a key; human identity and authority need additional checks.

Organization and adoption

One person may hold several declared responsibilities; several keys held by that person do not create independent reviewers. An agent crew contributes work while people retain the decisions established by SCAFFOLD. An existing management tool can project status from a declared source; replacing boards or meetings is not required.

There is no universal 0–5 scale combining maturity, risk, layers and adoption. Each classification keeps its name, purpose and version; MILPA-R-003 requires keeping them distinct. Plants in the MILPA analogy do not prescribe mandatory agent classes either.

Next steps