Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
Apply the methods to your first project¶
Current application guide for the first 0.1 editions. Accepted requirements retain their conditions. This guide explains the accepted requirements; it does not accept a profile or add obligations.
Start with a small task: review one part of a project and propose an improvement. You can use a coding assistant, a local model, or an API (application programming interface) service. The methods do not require a specific SDK (software development kit), framework, or provider.
MILPA helps you locate the rules, sources, and decisions. ASILO helps you define what data the assistant receives and what actions it can perform. To assess whether a project applies edition 0.1, consult all the requirements; this walkthrough is an entry point to the method, not a declaration of full coverage.
1. Explain the project before asking for work¶
Prepare a record with its identity, owner, purpose, scope, and restricted zones. Declare the profile you use and its status. If it is still a proposal, say so: the profiles on this site declare their approval state separately.
For example, for a library catalog: “We want to detect duplicate records in a test inventory. The responsible person will review the proposal. User data, the production database, and any deletion are out of scope.”
See MILPA-R-004 for the manifest fields and MILPA-R-006 for the seven functions of the core: manifest, entry point for readers, sources and links, instructions for agents when they operate, index, decisions, and separate temporary material. The specific names and folders belong to the profile.
If you need the detail, open Identity and manifest and Files, folders, and names.
If the operation depends on a jurisdiction, first prepare its context with Applying jurisdictional profiles. Choosing a language or hosting country does not determine the applicable rules by itself.
2. Leave a short path to the sources¶
The project's entry point should let people find the index, the applicable rules, and the
decisions without walking the whole tree. Record the method edition and the revision of the
sources you use; a published page or a canon label does not replace that identification.
A short instruction for any assistant can point to those paths. The full text lives in one owning place; each tool's entry point links to it. Copying all the rules into several files creates versions that can diverge.
See MILPA-R-001 and MILPA-R-007. Sharing a folder or reading the same text does not automatically connect two systems or demonstrate compatibility.
3. Scope a task¶
Before sending it to the model, identify its objective, the sources needed, the excluded paths, the data classification, the maximum context size, and its expiry. Also declare who acts, which operations are allowed, and the limits on actions and delegation.
In the library example, a first task can read a synthetic inventory and return a list of possible duplicates with references to the original record. It needs no access to accounts, credentials, or other projects. A written budget requires checking afterward what the tool actually received.
The reference is in ASILO-R-003, ASILO-R-004, and ASILO-R-006. Instructions guide the model; the effective permissions and restrictions depend on verifiable controls in the tool and the system.
The Context and handoffs guide helps you prepare that budget.
4. Review the proposal before the effect¶
Ask that each finding distinguish a cited fact, an inference, and a hypothesis. Review the result against its sources: another agent agreeing does not verify its truthfulness or its independence.
If the proposal moves on to execute an action, identify the contract and the authorization needed. A list of duplicates can be well formed and still include records that must not be deleted. For critical effects, the authorized person reviews the specific object before confirming it. The minimum catalog and the conditions are in ASILO-R-005.
See also MILPA-R-002, ASILO-R-001, and ASILO-R-008. Controls are tested against concrete failures; they do not turn a result into truth by consensus.
Open Architecture and security to separate controls and Evaluation and review to check the applicable failures.
5. Keep what you learned for the next task¶
Save the decision, the sources reviewed, the tests performed, and what remains pending. A contradiction keeps both of its sources until the responsible person decides how to resolve it (MILPA-R-008).
If you change assistant or provider, prepare a handoff with the objective, the revisions of documents and artifacts, the limits in force, the results, and the next pending action. It is a suggested working technique: it does not synchronize the tools' private memories or automatically authorize the new recipient to receive the data. Review their access and the processing conditions before continuing. For budgets, stop mechanism, and state preservation, see ASILO-R-007.
Open the detail step by step¶
Use the artifact records to prepare records, or compare your task with the use cases. Choose tools after defining the limits and the evidence you need, not as a condition for learning the method.
A Markdown file or a site build does not by itself prove application. Evidence is recorded against the requirement, the edition, and the project evaluated. Installing and using the software is outside this walkthrough (portal responsibilities).