Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
Agnostic and verifiable engineering: profile proposal¶
Status: proposed. Context: software built by people and assistants, with or without AI in the product. This proposal neither accepts a profile nor changes principles or adds universal requirements. Its axioms are candidate profile commitments, not new ASILO, MILPA or SCAFFOLD axioms. A planning decision is not evidence of an implemented control.
Purpose and first step¶
Prevent a selected technology, persuasive output or partial check from standing in for architecture, authority or sufficient evidence. Start with the charter and baseline survey (SCAFFOLD-R-019, R-020); identify owners, effects and criteria. The artifact guide explains the process.
Candidate profile axioms¶
| ID | Proposed commitment | Observable check |
|---|---|---|
| ENG-AX-001 | Agnosticism: the core uses explicit contracts; providers, tools, formats and assistants connect through adapters. | Two distinct consumers or adapters exercise the same contract; limits and versions are declared. |
| ENG-AX-002 | Responsibilities and boundaries: each module has an identified reason to change and effects. | Dependency rules and tests show that the core does not import concrete presentation, network or storage. |
| ENG-AX-003 | Substitution: an adapter preserves the port's preconditions, results, errors and effect limits. | Shared behavioral tests, including failures, cancellation and adversarial cases; matching signatures are insufficient. |
| ENG-AX-004 | Minimal extension: abstractions respond to a demonstrated variation or consumer. | A second case and a decision explain the extension; reading data does not install plugins. |
| ENG-AX-005 | Explicit authority: text, packs, AI output and technical results do not grant permissions. | An effect without a subject, scope and current authorization is denied at execution. |
| ENG-AX-006 | Uncertain required controls: missing, invalid or unevaluable controls cannot count as satisfied. | Invalid configuration and absent evidence do not become approval. |
| ENG-AX-007 | Bound review: material changes invalidate evidence dependent on the previous object. | Changes to artifact, context, policy, profile or source require reviewing its use. |
| ENG-AX-008 | Minimal, intact evidence: version, provenance and scope accompany results; data is minimized. | Checked digests, readable references and errors without secrets; a digest does not authenticate a publisher. |
| ENG-AX-009 | Accounted effects: repetition, resumption and failures have explicit outcomes. | Each operation terminates once or remains pending reconciliation; uncertain effects are not retried without a criterion. |
| ENG-AX-010 | AI by design: instructions, context, tools and evaluations have limits and versions. | Simulation, model evaluation and human acceptance are recorded separately; diversity is not invented. |
| ENG-AX-011 | Measured optimization: correctness and baseline precede a compared hypothesis. | Before/after quality, cost and latency measurements; caching preserves invalidation and permissions. |
| ENG-AX-012 | Traceable delivery: the checked artifact, decisions and rollback are identifiable. | The same digest is promoted, configuration is separate and critical effects follow the project's decision process. |
| ENG-AX-013 | Authority per topic: one canonical source exists for each semantic topic; an index points to it and derived views declare provenance. | Duplicate or conflicting authority is detected; source changes identify dependent evidence. |
| ENG-AX-014 | Security by design and zero trust: identity, resource, action and context are checked at every relevant boundary; missing required controls fail closed. | Threat cases and authorization tests cover allowed, denied and failure paths; this reduces risk but does not prove absence of vulnerabilities. |
| ENG-AX-015 | Explicit AI boundaries: context, outputs, evaluations and tools have separate provenance, versions and authority. | Adversarial tests, exact references and deterministic effect mediation; the model grants no permission and does not accept its own output. |
Skills, plugins and tool protocols — profile proposal¶
This distinction makes the profile concrete; it creates no universal requirements and changes no accepted edition. Apply the current conditions of SCAFFOLD, MILPA and ASILO.
| Element | Function | What it does not grant |
|---|---|---|
| Skill | Instructions and resources that guide a task, distributed in a format a host can consume. | It grants no identity, path access or permission to execute tools. Its content is untrusted input. |
| Plugin | Code that extends a specific host and may execute in its lifecycle. | It is not portable by definition or trusted merely because it is installed. |
| MCP | A protocol for a host to connect to servers exposing tools, resources and prompts. | It is not by itself an authorization policy, data classification or human review. |
| Adapter | An optional translation between an external contract and a stable framework port. | It does not expand permissions or change contract authority. |
How the methods complement each other¶
- SCAFFOLD records these integrations as project or work-batch dependencies when used to build software: origin, version, compatibility, purpose, owner, zones, acceptance criteria and evidence. It already covers human and agent crews, planning, delivery and measurement under R-001..R-032; it does not impose Scrum, a specific tracker or a DAG for every task.
- MILPA preserves source, owner, status, version and relationships for manifests and contracts (R-001, R-004..R-008). A federated index references repositories and contracts with revision/digest; it does not imply effective inheritance, automatic cloning or one global source that duplicates every artifact.
- ASILO applies limits according to capability and effect: Skill content, resources and external results are untrusted; identity, resource, action and context are checked at the relevant boundary; permissions are minimal and revocable; secret handling and human review retain their requirements (R-001, R-003..R-008).
The engineering crew builds software; the runtime crew serves product use. They may share a provider or framework, but do not inherit identity, permissions, secrets, data, budgets or credentials. SCAFFOLD organizes construction; ASILO protects any phase meeting its conditions; MILPA preserves provenance and authority through the lifecycle.
Candidate adoption criteria¶
- Declare origin, version or digest, owner, compatibility and status before using a package, Skill, plugin, MCP server or external contract as agent context.
- Separate data reading, instructions and effects. Activating a Skill does not activate its tools; discovering a tool does not authorize it.
- Select direct connection or a gateway based on risk assessment and topology. The profile does not require every call to pass through Horcón; it requires verifiable authorization at the boundary where the action executes.
- For extensible code, record capabilities, permissions, isolation, updates, revocation, compatibility and rollback. Treat a plugin as executable code.
- Test malicious inputs, denied permissions, revocation, replay, time limits and adapter failure. A valid schema does not prove a safe effect.
- Bind usage evidence to the exact digest of the source, authorization profile, contract, model/configuration and artifact. A material change requires review of affected evidence.
These criteria are a profile proposal pending an owner, methodological review and decision. No requirement IDs are assigned, to avoid implying an accepted edition. MCP, Skills and plugin contracts must be pinned to applicable external revisions at implementation time; interoperability does not remove version changes or their specific risks.
SOLID, patterns and zero trust¶
Single responsibility, extension, Liskov substitution, small interfaces and dependency inversion are expressed through contracts and tests, not class counts. Ports/adapters, strategies and a functional core are profile options, not a universal architecture. Zero trust avoids granting trust based on location or ownership: identity, resource, action and conditions must be checked at relevant boundaries.
References: NIST SP 800-207, Liskov and Wing's behavioral subtyping, ports and adapters. These are external antecedents, not certification of this profile.
Relationship to methods and acceptance¶
ASILO supplies scope, boundaries, permissions and effect review (R-001 to R-007); MILPA supplies provenance, classification, versions and relationships (R-001, R-003, R-004, R-007, R-008); SCAFFOLD supplies contracts, work, checks and delivery (R-006, R-010, R-019 to R-032, subject to applicability). SCAFFOLD-R-017 remains outside the accepted edition.
Fictional example: a library and a web application use the same evidence contract; the web application adds UI review and the library explains why that scope does not apply. Human decisions and permissions retain their own controls. API and installation details belong to the implementation, not this profile.
The profile owner, methodological acceptance and independent review remain pending. Changes identify revision, reason, affected evidence and transition; they do not silently change accepted requirements. Spanish remains the normative source; this translation awaits human review.