Translation

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

Preparing artifact verification

This guide applies SCAFFOLD 0.1. It does not require a particular tool, serialization, architecture, user story or diagram. The engineering profile proposes optional commitments; its executable contracts and acceptance remain pending.

Start with a checkable scope

Declare a charter, baseline survey, work item and acceptance criteria. A library without UI can explain why screen checks do not apply; a web application selects relevant flows, states and environments. Equivalent formats are acceptable when they preserve required fields and relationships. SCAFFOLD 0.1 has 31 accepted requirements; R-017 remains a pending amendment.

Artifact or evidence	Existing basis	Suggested check and limitation
Charter and survey	R-019, R-020	Objective, exclusions, owners, critical effects and sources; existence does not prove acceptance.
Story, feature or initiative	R-021 to R-024	ID, objective, criteria, state, dependencies, parent and acceptance; stories are an optional format.
Batch, zones, crew and handoff	R-001 to R-005, R-009, R-016, R-030, R-031	Owners, turns, limits, immutability and acyclic dependencies; declarations do not prevent external writes.
Architecture, contract and code	R-006, R-007, R-018	Corresponding versions, allowed dependencies and adapter substitution; no universal pattern is imposed.
Documentation and diagrams	R-006, R-010, R-023	Links, editable sources, compilation and correspondence; rendering does not establish architectural correctness.
UI where applicable	R-010, R-021, R-023	Declared flows, states, resolutions, accessibility and visual review; a screenshot or automated test does not prove usability or complete accessibility.
Git and review	R-003, R-008, R-025, R-026	Work/batch/change/version traceability in both directions and queried protection or local rule; names do not prove protection.
Integration and delivery	R-010, R-011, R-027 to R-029	Results bound to revision, built artifact, same promoted digest, separate configuration and rollback; green CI does not accept a critical effect.
Evaluation and learning	R-024, R-032	Indicator sources, incidents and before/after measurements; simulation is not actual model evaluation.

IDs refer to the requirements, including conditions and exceptions. Regional content needed at runtime is not excluded merely for being “context”: regional delivery.

Four distinct observations

1. Shape: fields, types, versions and limits.
2. Consistency: references, dependencies, states and corresponding revisions.
3. Execution: identified evidence of actual artifact, environment, tool and result.
4. Decision: who accepted which object, with what scope and verified authority where relevant.

A structurally valid record can lie. Absent evidence or unavailable tools are recorded as not evaluated, not successful. “Not applicable” identifies a condition and reason; it does not replace a failed check. A “human reviewed” checkbox does not authenticate a person. A technical result does not close a work item by itself (R-022, R-023).

Source of truth, traceability and change impact

There is no single document that is the source of truth for an entire project. Each claim needs an identifiable authority: the requirements register for needs, the contract for interfaces, the code for executable behavior, and the decision record for approved decisions. A README or diagram can be a derived view when it identifies its source and regeneration method. Duplicating the same decision across files without an owner creates competing sources.

The taxonomy for application shape, structure, repository, deployment and regional profiles is in the software architecture profile. The graph references canonical sources by ID; it does not duplicate their content.

The project maintains an artifact graph with stable IDs, paths, kind, revision or digest, owner, applicability and typed relations. At minimum, the project profile declares the relations required for each kind of work. A suggested chain is:

requirement → work item/story/use case → verifiable criteria → contract and architecture decision → components/code → tests/evaluations → documentation/diagrams → delivery/operation.

A relation expresses declared dependency or coverage; by itself it does not prove that an artifact satisfies a requirement. Coverage claims need checkable evidence and human review where the project requires it. An acyclic graph simplifies impact analysis; reference or grouping relations that allow cycles must be declared as such and excluded from dependency calculations.

When an artifact changes, the repository identifies the changed node, computes its transitive dependents through declared relations, and marks evidence tied to the previous revision as pending review. A generated file is regenerated from its source; it is not edited manually to silence a divergence. A hand-written artifact needs content review: a digest or successful render cannot establish that its meaning remains current. Incomplete checks, missing references and conflicting sources are reported as such; they are not resolved by “last change wins” or by regenerating accepted decisions.

The register may live in YAML, JSON, a database or work-tracking system if it preserves IDs, revisions, relations, provenance and verifiable export. The repository should provide a read-only CI mode that reports affected nodes and invalid sources without installing extensions or executing instructions found in artifacts. CI may block integration under the declared profile; its result does not become human acceptance.

For AI assistants, each task receives relevant requirements and contracts with exact IDs and revisions, authorized write zones, and positive and negative criteria. Factual claims carried into an artifact link to their evidence. The assistant proposes changes in a limited zone; the linter detects technical impact and stale evidence, but does not decide meaning, authority or acceptance. The responsible person resolves conflicts and accepts the result.

Suggested baseline crew

The profile may assemble crews according to risks and changes instead of activating every role for every batch. A minimum crew for a software feature is product/coordination, architecture, implementation and QA. Security joins design early when data, permissions, network, models or sensitive effects are involved. UI/UX joins when user flows exist. Documentation/DevEx and delivery join when the change affects usage contracts, builds, CI or publication. In a small project one person may cover several responsibilities; the implementer alone does not provide independent review or product or delivery acceptance.

Each batch declares one writer per file, reviewers, handoff interfaces and evidence. Parallel work is limited to zones without overlapping writes; cross-cutting changes require a coordinated batch and serialized integration. Agent count does not replace human accountability.

Skills, plugins and MCP

A skill distributes instructions and procedures; a plugin packages installable functions for a host product; MCP standardizes how a client accesses tools or resources. These are distinct layers and their names do not establish trust. The host client retains identity, per-action authorization, allowlists, limits, provenance, logging and revocation. Repository content does not automatically install skills/plugins or enable MCP servers.

SCAFFOLD-R-006 · R-018 · R-022 · R-023

Agnostic, bounded implementation

The checking core can receive normalized artifacts and return findings without network, Git, browser, models or writes. Optional adapters supply evidence from these tools under explicit permissions. Reading a document does not execute its commands or install plugins. CI/CD integration retains inputs, configuration and digests; providers can change without changing the meaning of a check.

Test a fictional library and web application with valid, inconsistent and missing-evidence or missing-decision cases. A changed revision invalidates evidence dependent on it. API, configuration and distribution belong to the implementation. The method prescribes neither a product nor an agent tool. A product's template generator does not demonstrate implementation of the entire SCAFFOLD lifecycle. Spanish remains the normative source; this translation awaits human review.

Back to SCAFFOLD · Engineering profile

SCAFFOLD 0.2 adds R-033–R-037: 36 requirements including the 0.1 base. This guide does not replace those records or demonstrate implemented controls.