Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
Use cases¶
Application examples for learning ASILO 0.1 and MILPA 0.1. They are not accepted profiles or real cases.
The cases on this page are illustrative. Sanitised real cases are accepted when they have the written consent of the people or organisation involved and a maintainer has reviewed their anonymisation; the consent is not published. See how to contribute.
The methodology does not require a graphical interface, an SDK, or a multi-agent system. The project decides its form; obligations are reviewed by scope and condition in the accepted records.
1. A project that already exists¶
Question: how do you organize its sources without rewriting everything?
Start by identifying the owner and scope, locating the seven functions of the core, and declaring the profile. Prepare an index that points to the owning sources; do not copy rules into each folder. If an adequate accepted profile is missing, record the situation and a proposal.
Artifacts: manifest, index, sources, and decisions. Rules: MILPA-R-001, R-004, R-006. Pending evidence: actual locations, revisions, owner, and manifest validation.
2. Pass a task between assistants¶
Question: how do you continue a review with another tool?
Prepare a handoff with objective, revisions, limits, findings, and next action. Review the data classification and the new recipient. The second assistant consults the sources; it is not assumed to know the first one's private memory or to inherit authorizations.
Artifacts: context budget, report, and suggested handoff. Rules: ASILO-R-003, R-006, MILPA-R-002. Pending evidence: content received, validity, and effective permissions.
3. Process files without a graphical interface¶
Question: how do you review an inventory and produce a proposal file?
Limit the task to synthetic data and a declared destination. Separate the proposal from the effect of writing, replacing, or deleting. Check contract, authorization, limits, and review if the action falls into the critical catalog. Having a local process does not remove risks or all applicability conditions; exceptions are examined in each record.
Artifacts: context, agent scope, effect contract, and execution log. Rules: ASILO-R-001, R-004, R-005, R-007. Pending evidence: what was read/written and applicable rejection and stop tests.
4. An application that consumes an agent layer¶
Question: how do you connect interface, backend, and agents without confusing responsibilities?
Declare the projects and contracts that cross their boundaries, the layers, and their dependency direction. Separate human identity, application permissions, and agent scope. Identify the effect point and the person authorized to review critical actions. Login alone does not demonstrate authority to approve any object.
Artifacts: link, architecture, scopes, and critical catalog. Rules: MILPA-R-007, ASILO-R-002, R-004, R-005. Pending evidence: contract at both ends, authorizations, and observed effects.
5. Change the model or a relevant configuration¶
Question: can we sustain the same claims after the change?
Review data recipients, context, and limits; run the applicable evaluation cases again before claiming fitness. Keep the earlier evidence labeled as earlier. Continuity does not authorize changing limits or repeating an effect whose execution is uncertain.
Artifacts: change decision, evaluation, and execution log. Rules: ASILO-R-003, R-006, R-007, R-008. Pending evidence: new configuration, executed cases, and residual risk.
These walkthroughs do not by themselves cover all obligations. To declare application, review the full set of requirements, their conditions, and exceptions.