Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
Architecture and security¶
Current application guide based on ASILO 0.1. It fixes no technology, number of rings, or security guarantee.
Document where an action is proposed, where it is authorized, and where it produces an effect. A rule in Markdown guides; effective control needs evidence in the system that executes.
Draw the boundaries before the rings¶
Identify untrusted inputs, internal logic, permissions, data, and effect points. Declare which module depends on which and who owns each boundary. Then choose the appropriate layer model, with its profile of origin.
ASILO-R-002 asks you to declare that model and its dependency direction; it does not require a universal number or numbering. Automatic checking of the dependency rule is, according to ASILO-R-002, a recommendation when the profile allows it. The ASILO for TypeScript profile is still in preparation and its ring numbering remains open. Do not turn it into the only architecture model.
Distinguish four questions¶
| Question | What is checked | Rule |
|---|---|---|
| Does the proposal have a valid form? | Versioned input/output contract. | ASILO-R-001. |
| Is that action allowed? | Authorization at the effect point. | ASILO-R-001 and ASILO-R-004. |
| Who can stop it or revoke the agent? | Scope, revocation, and tested stop mechanism. | ASILO-R-004 and ASILO-R-007. |
| Does it require prior human decision? | Catalog of critical effects and specific approval. | ASILO-R-005. |
A valid output does not prove truthfulness or authorization. An identifier does not demonstrate verified identity. A diagram does not demonstrate that the control drawn exists.
Declare each agent's scope¶
Record identity, allowed operations and data, action limit, and delegation depth before operating. The scope does not exceed that of whoever invokes it and is not widened during execution. ASILO-R-004 requires the ability to revoke and recommends checking revocation before each action. Harm can still occur within a legitimate scope.
Human identity, their application permissions, and an agent's identity are not the same thing. The methodology does not prescribe accounts, directories, signing protocols, or cryptographic algorithms. Document which person has authority over the specific object; the verification mechanism belongs to the profile and the implementation being evaluated.
Human review where it matters¶
The minimum catalog in ASILO-R-005 covers payments, deletions, permission changes, publication or sending to third parties, and decisions that affect people. The review shows the exact object before the effect and records identity, date, and a non-reusable approval. It does not imply asking for confirmation for every read or every response. The emergency exception needs a prior definition by the owner and a recorded later review.
When the rules do not decide, ASILO-R-005 recommends that the case go to human review rather than be resolved with a default value. It does not turn all uncertainty into a universal pause independent of the requirement's scope.
Limits and continuity¶
ASILO-R-007 asks for limits on cost or tokens, actions, and time, and a stop mechanism with a defined owner, tested in the environment where it is claimed to work. The test applies to the mechanism, not to the person. Exhausting a limit leads to stopping or reviewing, not to continuing silently. According to ASILO-R-007, on stopping, the record of what was executed is preserved; allowing resumption without repeating effects already applied is a recommendation.
Changing provider, restarting, or retrying does not remove the limit or prove that an action did not occur. The edition prescribes no automatic fallback or kill switch format. Describe those mechanisms when they exist and evaluate their failures; do not attribute their implementation to the method.
Next: evaluation and review · Control artifacts
A plan and its locks¶
A plan explains how areas relate; locks control access. Software architecture and authorisation likewise need separate checks. The layered security guide develops this distinction.