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.

Applying jurisdictional profiles

This guide helps people adapt a project to a legal context. It explains an application technique for ASILO, MILPA and SCAFFOLD 0.1; it creates no requirements, accepts no profiles and does not determine the laws applicable to a real operation. The principles retain their statements, and application profiles declare their own status.

First step: describe the entity, operation, data and event date. From those facts, prepare an applicability record before selecting rules or tools. The privacy proposal for Mexico illustrates a first, limited case.

Separate the context dimensions

“Zone” can mean different things. The following separation is a suggested technique; it is neither an accepted manifest schema nor a new classification in edition 0.1.

Dimension Fictional example What remains to be checked
Language and formatting es-MX or a preference for English Presentation preference; it does not select legislation.
Currency MXN Unit, precision and calculation rule for the operation.
Time zone America/Mexico_City The clock relevant to the event; a country can have several zones.
Jurisdiction Mexico and, where relevant, a state or municipality Applicable scope, without inferring it from language or IP address.
Entity and operation A fictional private library preparing an inventory Who determines the processing, activity and proposed effect.
Sector and people involved General service; population not yet determined Additional rules, data categories and limits of the analysis.
Data locations and transfers Processing, backups, logs and recipients Actual flows; hosting one part in a country does not prove complete residency.
Dates Event date and source consultation date Publication, effective dates, amendments and relevant transitional provisions.

Language and formatting identifiers can follow Unicode CLDR; time zones can follow IANA. These sources address technical dimensions distinct from legal applicability. A path an assistant may edit is a file work zone, with no territorial meaning by itself.

Preserve the core and specify the profile

The base method retains its requirements and conditions. The profile identifies what it specifies for its scope. The matrix summarizes principles for explanation; the authoritative statements are in the Spanish source. The English translation is informative. Each contextual decision below is a work proposal.

Principle Related requirements Proposed specification and evidence
MILPA-P-01 MILPA-R-001/003 Identify the authority, status and revision of each source and scheme used.
MILPA-P-02 MILPA-R-002 Separate verified text, interpretation and project decision.
MILPA-P-03 MILPA-R-005/006 Declare the profile and version; preserve the common core.
MILPA-P-04 MILPA-R-004 Record entity, operation, data and coverage before exploring.
MILPA-P-05 MILPA-R-007 Declare both ends, contract and version of each relationship.
MILPA-P-06 MILPA-R-008 Preserve conflicting sources and record their resolution.
ASILO-P-01 ASILO-R-001/002 Validate the proposal and authorize the effect separately.
ASILO-P-02 ASILO-R-004 Profile content does not expand the agent's permissions.
ASILO-P-03 ASILO-R-003/006 Bound context, classification, purpose and retention for the case.
ASILO-P-04 ASILO-R-005 Identify human review relevant to the effect or ambiguity.
ASILO-P-05 ASILO-R-007 Bound queries, actions and time; preserve evidence when stopping.
ASILO-P-06 ASILO-R-008 Evaluate failures by context and record results and residual risk.

A structural profile describes how a project is organized. A jurisdictional profile addresses a legal context. An application may need both, with their scopes and statuses declared; a country need not become another project type.

How the three methodologies contribute

The methods answer different questions about the same change. This correspondence explains already accepted requirements, subject to their conditions; it creates no parallel profiles. SCAFFOLD 0.1 has no principles of its own: its contribution relates to its requirements.

Method Work on a jurisdictional context Suggested record or check Related requirements
ASILO Bound context and data; distinguish technical compatibility, legal applicability, authorization and effect. Allowed sources, exclusions, technical coverage and pending questions; evidence of control and review of the object where required. R-001, R-003, R-005, R-006, R-008.
MILPA Identify authority, provenance and status of the profile and content; pin references and preserve conflicts. Source, owner, revision, version and digest; relationships declared at both ends where R-007 applies. R-001, R-002, R-003, R-004, R-007, R-008.
SCAFFOLD Plan, check and integrate the change; relate it to its release and delivery. Work item, acceptance criteria, affected contracts, tests, review and delivery and rollback history where relevant. R-006, R-010, R-021, R-023, R-025, R-027, R-028, R-029.

Fictional example: a library adds a content package to prepare its processing inventory. MILPA helps identify the source, version and status of the content. ASILO distinguishes a technical match between package and context from legal review of the case and permission to act. SCAFFOLD organizes the addition as work with acceptance criteria, tests and an identified delivery. Whether starting from scratch or from existing work, the project lifecycle explains the charter and baseline survey.

A favorable technical match does not determine legal applicability. If that question was not evaluated, it remains pending even when the package matches language, declared jurisdiction or date. A digest identifies the bytes compared; it does not prove authority, legal accuracy or trust in the publisher. Those checks are recorded separately.

When planning tests, consider an altered package, incompatible reference, uncovered scope, changed context, a source not in force on the event date and pending review. These are suggested cases; each repository declares its required checks under its requirements. Delivering regional changes explains what to retain when updating or rolling back a package without confusing the product with its engineering layer.

Prepare an applicability record

For a first draft, collect the following fields. They form a suggested template, not a mandatory method format or an available API:

  1. Entity and operation identity, purpose, data and event date.
  2. Jurisdictions and activities considered, exclusions and facts still unknown.
  3. Method edition and proposed or accepted profile, with their own revision and status.
  4. Official source, provision or section, publication, effective dates and relevant transitional provisions; consultation date and revision or digest of the retrieved content.
  5. Verified text, interpretation and technical decision in separate fields.
  6. Related requirement, planned control, evidence, assigned owner where one exists and competent review still pending.

The record can distinguish “applies”, “does not apply” and “undetermined”, with reasons and sources. These labels only describe this template; they are neither permission nor an accepted methodological classification. An unknown fact does not become “does not apply”.

Fictional example: a private library requests a review of a synthetic inventory and uses an es-MX interface. That language does not determine jurisdiction. The inventory's synthetic origin is recorded separately from its exposure classification. If personal records are later proposed for use or transmission to a provider, the context changes and the affected decision is reviewed.

Sources, conflicts and versions

An agent skill, provider guide or interpretation may guide research; its format gives it no legal authority. Retrieve the primary source and open the article's context, including exceptions and transitional provisions. Consultations for this guide and the Mexican proposal are identified in the source register.

Technical composition of files does not resolve a legal contradiction. Country, state, municipality and sector do not form an automatic override cascade. Preserve incompatible sources and their consequences; the affected decision remains pending competent resolution. MILPA-R-008 preserves that traceability.

Distinguish method edition, profile revision, content package version, legal effective period and implementation version/configuration. Manifest inheritance remains outside MILPA 0.1 (MILPA-R-004). Reconstructing a decision also needs its context, sources and relevant external responses, subject to applicable minimization and retention conditions.

From a profile to an implementation

The profile documents context and specifications. A package can distribute versioned content; a skill teaches a procedure and a plugin groups its installation in an assistant. MCP can connect tools or resources where needed. None of those distribution forms alone demonstrates authorization, human review or compliance.

Installation, API, contracts and tests belong to each implementation, following the method–software boundary. Evidence relates to the context, sources and artifact reviewed; changing any of them may require another review, even when the output text is identical.

Evaluation cases can check language different from the operation's country, sources not in force on the event date, uncovered scope, incompatible rules and context changes after review. A well-formed document does not prove its content's applicability.

Propose, review and maintain

The profile card identifies scope, requirements it specifies, sources, alternatives, pending decisions and planned evidence. Publishing an explanation or integrating a contribution does not accept the profile: that decision follows governance. Expansion to another sector or jurisdiction retains its own analysis and review.

Back to profiles · Privacy in Mexico: proposal