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.

ASILO: capabilities and points of effect

Current ASILO 0.1 guide; informative translation. A capability bounds an action over a resource. Its representation and mechanism belong to the profile; no signature, storage or language is required here.

The contract declares the authorised subject, resource, operation, context, validity, revocation, permitted delegation and relevant conditions of use. If an action is single-use, the profile defines how consumption is decided and recorded, including concurrent requests.

flowchart TD
  accTitle: ASILO: authorisation at the effect point
  accDescr: A request passes four checks in order: identity verified according to the profile, input conforming to the contract, authorisation of resource, operation and context, and required additional controls. Any negative answer rejects it without the requested effect; if all pass it is executed at the point of effect, and in both cases the result and observed effects are recorded.
  P["Request"] --> I{"Identity verified according to the profile?"}
  I -->|"Yes"| V{"Input conforms to the contract?"}
  I -->|"No"| R["Reject without the requested effect"]
  V -->|"Yes"| A{"Authorised resource, operation and context?"}
  V -->|"No"| R
  A -->|"No"| R
  A -->|"Yes"| H{"Required additional controls satisfied?"}
  H -->|"No"| R
  H -->|"Yes"| E["Execute at the point of effect"]
  E --> L["Record result and observed effects"]
  R --> L

SVG diagram: ASILO: authorisation at the effect point · Editable Mermaid source. Arrows show an illustrative sequence, not an implementation. The profile defines checks, errors and records. Invalid identity, out-of-contract input or unmet additional controls also lead to rejection.

The analogy is presenting a key at the door being opened. A reception check is insufficient if another entrance bypasses it. The key also does not authorise other rooms. Queues, retries and cached responses need to respect the applicable authorisation.

The profile answers who verifies identity, how current permissions apply to cached or queued work, what happens when authority expires or is revoked between check and effect, how single-use effects avoid duplication, and what is recorded if an operation succeeds but its response fails.

Valid permission does not replace human review required by a profile. Where ASILO-R-005 applies, preserve its conditions and evidence of approval for the critical effect. Do not execute while that condition is missing.

A later error does not demonstrate rollback. Revocation and concurrency require explicit semantics and tests of the real mechanism; an interface alone does not establish them. Records exclude secrets and retain only data required for their declared purpose.

Back to ASILO · Boundary tests.