Digital Engineering Foundations · Module 2 of 8
Engineering Information and Configuration
Turn "controlled artifact" from Module 1 into something real: identifiers, metadata, versions, revisions, baselines and provenance, so a reviewer can tell what an artifact is, whether it is current, and whether a result can be rebuilt.
Readiness check
Building on Module 1. Tick only what you can do closed-notes.
- Read a CSV or JSON table and identify owner, date and status.
- Explain the difference between editing a file and releasing it.
- Name one artifact that depends on another (a mesh on a CAD revision).
- Spot a stale simulation input file.
- Rerun a simple Python script with fixed input files.
The core idea
Engineering information becomes controlled data when its identity, meaning, owner, status, configuration and provenance are explicit.
A register does not make a project bureaucratic by itself. Used well, it lets a reviewer see which artifact is current, what it describes, where it came from and whether it is ready to support a decision. The recurring mechanical failure is a mismatched set: an analysis, drawing, test plan and requirement that do not belong to the same configuration.
The skills, taught in order
Four steps take an artifact from "a file exists" to "a reviewer can trust it": describe it as controlled data, control its versions and configuration, capture it in a baseline, and record its provenance so the result is reproducible.
2.1 Engineering information as controlled data
Assign stable identifiers to artifacts, add metadata fields that answer real review questions, and separate draft, review and released status. Validate records before trusting the register: invalid rows give false confidence and break traceability. A register row such as BRK-CAD-001 identifies the released bracket CAD model with owner, revision, status and requirement links; a file name alone cannot carry that structured meaning.
Lab connection. Lab 1 (artifact register) builds and validates this register for the bracket project.
2.2 Version, revision and configuration
A version records change history. A revision usually marks an approved release state under a defined control process. A configuration is the compatible set of artifacts that describe the product or analysis at a chosen time. Record working versions separately from released revisions, name the configuration items that need control, and write change notes that state what changed and why. A mesh generated from bracket revision A must not support a release decision for revision B without review.
2.3 Baselines and release states
A baseline is an approved reference set used for review, release or controlled change. It is not a claim that the design is perfect; it is a clear statement of what information was accepted at that point, what evidence supported it, and what future changes must compare against. Include only compatible, reviewed artifacts, record unresolved issues beside the baseline rather than hiding them, and use the baseline as the comparison point for change impact. A concept baseline (needs, boundary, early requirements) differs from an analysis baseline (geometry revision, material data, load cases, assumptions, script version, results).
2.4 Provenance, ownership and reproducibility
Provenance answers who or what produced an artifact, from which inputs, by which method and when. Ownership answers who maintains it and approves changes (creator and accountable owner may differ). Reproducibility answers whether another engineer can rebuild the result from controlled inputs and instructions. Keep raw and processed data separate, and write reproduction steps someone else can follow. A stress result is inspectable evidence only when it names its CAD revision, load case, material dataset and script version.
Engineering connection: this controlled information is what Module 3 traces and what Module 6 connects into a thread.
Worked example 1: is this analysis on the right configuration?
A reviewer must decide whether a stress analysis may support the bracket's baseline B0 release, given the register below.
- ProblemDecide whether BRK-ANA-001 is admissible evidence for the B0 release decision.
- Given / findRegister: BRK-CAD-001 (CAD, released, baseline B0); BRK-ANA-001 (analysis, status "review", source "CAD B0"); load requirement REQ-LOAD at 600 N. Find whether the analysis is on-configuration and release-ready.
- ModelAdmissible evidence must be (i) on the same configuration as the decision, (ii) at an approved status, and (iii) traceable to the requirement it verifies.
- SolveConfiguration: BRK-ANA-001 source = "CAD B0", which matches the released CAD revision → on-configuration. Status: "review", not "released" → not yet approved. Traceability: it must link to REQ-LOAD to count as verification evidence.
- CheckCompatible configuration and correct requirement link are necessary but not sufficient: the analysis status must reach an approved state, and its own provenance (load case, material, script version) must be recorded, before it supports a release.
- ConclusionThe analysis is on the right configuration but is not yet release-ready. The reviewer requests approval and the provenance record before B0 cites it.
Worked example 2: a revision arrives late
The load requirement is revised from 500 N to 650 N after baseline B0. Decide what this does to the configuration and the evidence.
- ProblemA requirement revision lands after B0. Decide whether existing evidence still belongs to a valid configuration.
- Given / findREQ-LOAD revised 500 N → 650 N. Existing evidence: stress check and test criteria built against 500 N, both citing baseline B0. Find the new configuration state.
- ModelA revision creates a new configuration. Evidence built against the old value belongs to the old baseline; it is a review candidate, not automatically valid for the new one.
- SolveOpen baseline B1 for the 650 N requirement. The 500 N stress check and test criteria remain part of B0's history (kept, not deleted) but are marked as superseded for the load claim. Re-run stress and re-state acceptance criteria at 650 N to populate B1.
- Check"Higher revision means better" is false unless approved for the same purpose: the 650 N requirement is only authoritative once its evidence is rebuilt and reviewed. Open issues from B0 carry forward visibly.
- ConclusionConfiguration control scales down to a student bracket: the fix is a new baseline with refreshed evidence, not an in-place edit that silently breaks compatibility.
Misconceptions and diagnostics
| Mistake | Diagnostic question | Correction |
|---|---|---|
| Metadata is decoration | "Can a reviewer decide whether the artifact is usable without it?" | Metadata carries engineering control information: status, owner, revision, source. |
| Higher revision means better | "Was the revision approved for the same purpose?" | A later revision may be incompatible with older evidence; approval defines authority. |
| Configuration is only for complex products | "Can a small bracket have mismatched requirements, CAD and test data?" | Configuration control scales down to student projects. |
| Baseline means final | "Is the baseline for concept review, test planning or release?" | A baseline is a reference state, not always the final state; open issues stay visible. |
| A clean result is enough | "Can the reviewer rebuild it from controlled inputs?" | A result without provenance is hard to trust; record inputs, method and version. |
Practice ladder
Create five register rows for the bracket project, marking one as draft and one as released, and add a source field for one derived result. Run the Lab 1 validator and fix each warning.
Show answer
Good rows carry a stable ID, type, owner, status and source (e.g. BRK-CAD-001 / CAD / Design / released / B0). The derived result (a stress file) must name its source inputs. The validator typically flags a missing owner, an undefined status, or a derived artifact with no source.
Choose four configuration items for the bracket package, define a revision-label rule, and find one possible incompatible artifact pair. Write a release note for baseline B0.
Show answer
Configuration items might be CAD, requirements register, stress analysis and test plan. A revision rule fixes when the letter or number increments (approved release only). An incompatible pair is a mesh from CAD rev A used with CAD rev B. The B0 note lists included artifacts, their revisions, and known open issues.
Write provenance for one final-project calculation, separate raw and processed data in the register, and produce a five-step reproduction checklist.
Show answer
Provenance names inputs (CAD rev, load case, material dataset), method (script version), environment and date. Raw and processed rows link parent-to-child. The reproduction checklist lets another engineer rebuild the number and hit the same check values.
Build a validated artifact register for one real project of your own, with at least one baseline defined and one fully reproducible derived result.
What good work looks like
Every row has identity, owner and status; one baseline lists its compatible artifacts and open issues; and one derived result can be rebuilt from its recorded inputs. This register is the spine that Module 8 connects into the capstone digital thread.
Working with AI, and proving it yourself
Use AI as an examiner, not a solver
Portfolio task
Ask AI to suggest metadata fields, then keep only the fields that answer a real review or reproducibility question, and validate the register with the Lab 1 script.
Retrieval and spaced review
Closed notes. Answer out loud, then reveal.
1. What does an artifact register control?
Identity, ownership, status, source, revision and relationships of each artifact.
2. What is the difference between a version, a revision and a configuration?
A version records change history; a revision is an approved release state under control; a configuration is the compatible set of artifacts for a defined state.
3. What is a baseline, and what should it include?
An approved reference set for review, release or controlled change, including compatible artifacts, status, purpose, approvals and known limitations.
4. What are provenance, ownership and reproducibility?
Provenance is the origin and production history; ownership is who maintains and approves it; reproducibility is whether another engineer can rebuild the result from controlled inputs.
5. Why are "latest" and "authoritative" different?
The newest file is not authoritative until approved for the relevant baseline and purpose.