Translation

Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.

Software architecture profile

Status: proposed. This profile extends the optional agnostic engineering profile. It does not change accepted ASILO, MILPA or SCAFFOLD axioms or requirements, and it prescribes no universal architecture. Record each system's choices against verifiable requirements and quality attributes; naming a style does not prove its implementation conforms.

Declare independent dimensions

Application shape, repository structure, integration style, runtime topology and regional context are related but distinct decisions. A system can be a modular monolith in a monorepo, deployed as a container on a VPS in a selected region. Never infer one dimension from another.

Dimension	Illustrative values	Decision to record
Application shape	library/SDK, CLI, batch/worker, API, web, mobile, desktop, embedded/edge, multi-agent system	entry points, consumers, boundaries and effects
Structural style	modular monolith, layers, ports and adapters, functional core, microservices, event-driven, pipeline, plugins	modules, boundaries, dependencies and composition; combinations require an explicit relationship
Repository	monorepo, multirepo, hybrid	ownership, package boundaries, tests, versions and coordinated changes
Integration	synchronous request/response, events, queues, streams, files/batches, local calls	contracts, delivery, ordering, idempotency, retries and failures
Runtime	single process, VM/VPS, container, orchestrator, PaaS, managed functions, edge, on-premises, hybrid or multi-cloud	deployment unit, operations, availability, recovery and portability needs
Data architecture	relational/transactional, document, key-value, graph, analytical, events/streams; no persistence	data owners, consistency, retention, migration, recovery and evidence
Residency	declared provider/region, local storage, replication, transfers	classification, effective location, backups, keys and jurisdictions for competent review

Relational, document, key-value, graph, analytical and event data models are options selected against queries, consistency, retention and operations; no database is a universal default. Declare ownership, migration, recovery and residency with relevant evidence. A project without persistent storage records that condition and its reason.

Terms are descriptors, not a closed catalogue. Preserve an unknown descriptor as a project extension with an explanation; never silently equate it with another type.

Select a style and topology

Start with the simplest design that meets testable requirements and keeps change boundaries clear. A modular monolith is an option, not a rule. Consider microservices when stable domain boundaries, truly independent deployment or scaling, clear operational ownership and the capacity to handle distributed observability, networking, consistency, service-to-service security and partial failures are present. Do not choose them because they are fashionable, there are many teams, or the repository has many packages.

Use event-driven integration when temporal decoupling, load or integration needs justify it and delivery, duplicates, ordering, idempotency, retention and recovery can be declared. A plugin system needs trust boundaries, versioned contracts, provenance, compatibility, capability permissions and a loading policy; discovering a plugin does not authorize or execute it. Layers and ports/adapters make dependencies visible; they do not guarantee security.

Monorepo and microservices are orthogonal. A monorepo can contain several deployable units; multiple repositories can produce one monolith. A monorepo needs module ownership, reproducible selective tests/builds, dependency rules and explicit interface versioning. Multirepo needs published contracts, compatibility, coordinated changes and version traceability. Avoid either fragmentation when its cost exceeds demonstrated benefit.

Cloud, VPS and operations

“Cloud” describes a service/operating model; “VPS” describes a rented virtual machine. Neither determines application shape, security or jurisdiction. For a VPS, declare ownership of patching, hardening, administrative access, firewall, tested backups, monitoring, recovery, capacity, certificates and incident response. For managed services, declare provider, selected region, backup regions, relevant subprocessors, export and exit procedure. Declare equivalent owners for on-premises systems.

Every deployment identifies components, network and trust boundaries, data flows, stores, secrets, effect points, external dependencies, observability, degradation, recovery and rollback. Keep secrets outside artifacts and grant workload identities least privilege. Context, container and deployment diagrams must map to identifiable source revisions and feed the impact graph.

Region and jurisdiction

Software regionalization is an extensible data and operations profile: locale and formats, language, time zone, currency, units, calendars, address and identifier formats, and declared technical requirements. It should compose with an international core and versioned packs. Regional values are validated configuration/data, not executable code loaded from a pack.

Provider region, UI locale, time zone and applicable jurisdiction are separate variables. None determines the others automatically. Data residency, transfers, legal duties, consent and retention require scoped, current sources, explicit context and competent review. Conflicts or missing evidence produce an indeterminate/review-required state; do not select the most permissive or newest rule without authority.

Mexico-specific requirements belong in a versioned jurisdiction pack/profile with sources, authority, scope, review date, exclusions, evidence and owner; they do not belong in the international core. A profile may identify technical dependencies such as location, retention, access controls or export, but it is not legal advice and does not determine applicability. The design should admit other jurisdiction packs without duplicating or silently changing the shared architecture.

Quality attributes, threats and operational readiness

Each architecture declares applicable quality attributes, priority, measurable target, measurement method, owner and evidence. Select relevant attributes such as latency percentiles and load, availability, RTO/RPO, accessibility, data minimization, cost ceiling, portability or maintainability. A value without workload, environment and measurement window is a goal, not verified performance. Record trade-offs and residual risks.

Security starts with requirements and threat modelling, not only a final review. Identify assets, actors, trust boundaries, data flows, abuse cases, dependencies, secrets and effect points. Apply least privilege and verify identity, resource, action and current context at each relevant boundary; network or repository location grants no trust. Missing or invalid required controls fail closed. Architecture and code tests can check declared boundaries but do not prove absence of vulnerabilities.

Each deployment declares an operational owner and applicable runbooks for backup/restore, incident response, patching, key rotation, monitoring, access review, capacity and recovery. Define SLOs and thresholds where needed. VPS, cloud, managed service and on-premises have different operators; do not infer ownership from a target label. Test restoration and rollback; a written plan is not recovery evidence.

AI-first and agent boundaries

AI is an explicit, optional subsystem; projects without AI are valid. When used, declare model/provider and version or limits of that information, purpose, input/output data classes, retention/transfer context, context sources and revisions, retrieval provenance, evaluation set/version, quality and safety criteria, fallback and human-review conditions. Keep untrusted user and retrieved content separate from instructions. Test prompt injection, retrieval poisoning, data leakage, unsupported claims, refusal and tool misuse with representative adversarial cases.

An agent plan or tool call is a request, never authorization. A deterministic enforcement boundary checks actor, capability, target, scope, budget, TTL, risk and applicable human approval immediately before the effect. MCP, plugins and skills are distinct integration layers; their presence, protocol compliance or repository location grants no permission. Evaluation, simulation, operation and human acceptance are separate evidence types tied to exact inputs/configuration/model revision. Model or evidence changes make dependent evaluations stale.

Record and evidence

An architecture decision preserves context and goal; alternatives; chosen dimensions and extensions; prioritized quality attributes and measures; boundaries and threats; operating costs; unresolved regional/jurisdictional impact; evidence, owner, date and review condition. Record material decisions in an ADR. Link requirements and artifacts by IDs and revisions in the SCAFFOLD graph; a change propagates review, not automatic approval.

Automation may validate vocabulary, required fields, links, dependency rules and declared diagram/deployment correspondence. Architecture, contract, threat, recovery, load and AI evaluations produce evidence bounded to their revision and environment. Record exceptions with reason, scope, owner and expiry. This profile prescribes no cloud provider, framework, language, pattern, diagramming tool or number of services.

Relationship to ASILO, MILPA and SCAFFOLD

ASILO guides trust boundaries, identity, permissions, data and effects; MILPA preserves provenance, classification, versions and artifact relationships; SCAFFOLD links requirements, decisions, contracts, code, tests, diagrams and operations. The engineering profile provides optional commitments, and this document a taxonomy of decisions. Horcón may validate structure and report impacts; that does not prove actual architecture, regulatory compliance, security or acceptance.

Engineering profile · Artifact verification · Application profiles