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.

Editorial axioms: clarity and methodological independence

These axioms govern the writing in this revision. They are editorial rules; they add no requirements to ASILO 0.1, MILPA 0.1 or SCAFFOLD 0.1. An explanation and an accepted rule have different authority.

DOC-AX-001 — Accessible, neutral and precise voice

Documentation MUST use an accessible, neutral voice, remain professional and define necessary technical terms. Each instruction identifies the actor, action, object and condition. Clear language helps compare translations and reduces ambiguity; it does not guarantee equivalence.

  • Start with the purpose, then an example, then technical detail.
  • Use one stable term per concept. Explain an acronym on first use; expand it only when an identified source establishes the expansion.
  • Avoid idioms, local humour, unexplained metaphors, judgements about people and absolute promises.
  • Preserve IDs, units, numbers, negations, exceptions and normative force in translation.
  • Retain necessary terms such as authorisation, capability, contract and residual risk. Define them in the glossary without replacing them with less precise words.
  • Record and review discrepancies. A translation is informative unless another authority is declared.
Ambiguous wording Verifiable wording
“The system controls everything.” “The control checks permission before writing the file.”
“The owner must approve it.” “The responsible person approves deletion of the listed records before execution.”
“This ring is secure.” “This layer imports no external adapters; the dependency check tests that rule.”

The second example is explanatory. If it states a normative obligation, cite the applicable requirement and preserve its condition and exception.

DOC-AX-002 — Agnostic and self-contained method

Public documentation MUST explain the method without depending on an organisation, product, private repository, provider, language or internal practice. Examples are fictional and portable. Authorship and licensing remain visible; attribution does not require adopting an ecosystem.

  • The method explains purpose, concepts, rules and limits.
  • A profile declares decisions for a specific context and its own status.
  • An implementation documents installation, API, operation, tests and version separately.
  • Product inventories, package diagnoses, local paths and private decisions stay outside public pages, diagrams, downloads and translations.
  • Selecting site pages does not establish access permissions for a repository or its history.

Analogies and diagrams

Every analogy states what it explains and where it stops being useful. Every diagram has a text explanation so the process can be understood without seeing it. Its legend identifies whether arrows mean dependency, sequence or transfer; arrows do not prove implemented controls.

Translation review

flowchart LR
  accTitle: Translation review
  accDescr: A left-to-right sequence: from the source text with actor, action and condition, stable terms and IDs are consulted, the text is translated without changing obligations or exceptions, negations, numbers, scope and limits are compared, and language and domain review follows. The result is an identified version or a recorded discrepancy.
  O["Source: actor, action and condition"] --> G["Consult stable terms and IDs"]
  G --> T["Translate without changing obligations or exceptions"]
  T --> C["Compare negations, numbers, scope and limits"]
  C --> R["Language and domain review"]
  R --> V["Identified version or recorded discrepancy"]

SVG diagram: Translation review · Editable Mermaid source.

Compare the translation with the identified original version and record material discrepancies. Do not change an accepted term merely to make it sound more natural. If there is no direct equivalent, retain the original term and add a definition.

DOC-AX-003 — Spanish first and traceable translation

Axioms, concepts, examples and decisions are written and reviewed in Spanish first. Each translation starts from an identified revision of the source and preserves IDs, figures, negations, conditions, exceptions and normative force. A change in meaning returns to the Spanish source for a decision before it is propagated to translations.

The acronyms ASILO, MILPA and SCAFFOLD use uppercase. Technical paths retain their lowercase convention. Expanding an acronym requires an identified source.

DOC-AX-004 — Technical usefulness and verifiable communication

Each entry explains the problem, who needs to solve it, the first step, the records it produces and how to check the result. Examples use fictional data. Claims about adoption, savings, security or compliance require dated evidence. Titles and descriptions represent the page's actual content with consistent terminology.

DOC-AX-005 — Explained analogies and descriptive names

Each methodology MUST introduce its acronym with a descriptive name stating its purpose. This name does not expand the acronym or change the edition’s scope.

Acronym Descriptive name
ASILO Boundaries and security of systems built with AI. Here “with AI” means with artificial intelligence assistance.
MILPA Knowledge and provenance.
SCAFFOLD Software projects with people and AI assistants.

Each analogy MUST explain its reference, necessary terms, the concept it helps readers understand, chosen correspondences and where it stops being useful. Editorial correspondences are labelled as such: they create no requirements, agent classes or permissions. Claims about cultural or scientific references use identified sources.

Each diagram MUST have a title, a legend for its arrows and an equivalent text explanation. When an SVG accompanies Mermaid, both retain terms, relationships and limits; the editable source, asset and provenance are recorded. Colour is never the only signal. An illustration proves neither controls nor results. Write in Spanish first, then translate.

A technical term is defined on first use or linked to its definition. Distinguish method, profile, implementation and example. The milpa shows this axiom in practice; the visual guide collects the diagrams.

The common map identifies the main references: shelter for ASILO, polyculture for MILPA and scaffolding for SCAFFOLD. ASILO retains its name; translations explain that it draws on Spanish asilo, meaning shelter, refuge or protection. Supporting images explain a specific decision without changing that main reference.

DOC-AX-006 — AI scope and explicit conditions

Documentation MUST distinguish AI, model interactions, assistance and multi-agent coordination. ASILO addresses systems built with AI assistance and relevant model use; SCAFFOLD addresses software projects built with AI, with one assistant or several. Neither requires several agents as a general condition. Each requirement retains its accepted scope, condition, exception and normative force. Failures between agents are evaluated when there is more than one.

Architecture and security are explained within ASILO. Ring models are illustrative; software implementations are identified at the software boundary.