Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
Identity and manifest¶
Current application guide based on MILPA 0.1. It explains accepted rules; it does not define a new format.
A manifest lets you know what a project is, who is responsible for it, and where its scope ends, without deducing it from its folders. It is not a prompt or an access credential.
Start with seven questions¶
| Question | Manifest content |
|---|---|
| What project is it? | Identifier. |
| What role does it have? | Node role: function within its relationship with other projects. |
| Who is responsible? | Human owner. |
| What does it include and exclude? | Scope. |
| What structure does it declare? | Profile and its status. |
| Which node does it organizationally depend on? | Parent, or none. |
| What is restricted? | Restricted zones. |
These contents come from MILPA-R-004. The requirement asks for a machine-readable manifest at the root of the project. The table in this guide helps prepare the content, but it does not replace that representation or its validation.
The method does not fix JSON, YAML, a file name, or an SDK schema. Those details are specified in a profile. Since there are no accepted profiles in edition 0.1, record a proposal; do not announce a nonexistent accepted profile. If the project is in transition, the exception in MILPA-R-006 asks you to declare a target profile and date, with the owner's acceptance.
Illustrative example¶
Fictional project: review of a library catalog with synthetic data.
- Identifier:
ejemplo-catalogo. - Role: document review project, with no operation on production.
- Owner: person responsible designated by the project, still to be identified.
- Scope: detect possible duplicate records and propose corrections; no deletion.
- Profile: local proposal under review, not an accepted MILPA profile.
- Parent: none in this example.
- Restricted zones: accounts, credentials, user data, and any production system.
The example is not a manifest ready to operate: the real identity of the owner, the chosen representation, and the validation are missing. It is not a declaration of conformance.
Do not mix identity, authority, and permissions¶
“Node role” does not mean an agent's role or a person's permission. A manifest does not grant access. If there are agents, their scopes are described separately according to ASILO-R-004.
A node's depth is also not document authority or claim certainty. MILPA-R-004 prevents using a
homonymous name such as level for it. Effective inheritance of manifests is outside edition
0.1: declaring a parent does not inherit rules or permissions.
What to keep¶
Keep the manifest revision, the declared profile, its status, and the result of its validation. Check whether it still describes the project when scope or relationships change. A correct manifest can become outdated and does not by itself block a restricted read.
Next: structure and names · See the manifest record
A card before opening the file¶
Like a library card, a manifest identifies purpose and responsibility before reading all the material. The card grants no access and proves no content quality.