1.1
Digital engineering as decision support across a lifecycle
Why this lesson matters
Mechanical products outlive individual analyses, software versions, and project teams. Decisions remain defensible only when their requirements, models, data, assumptions, and approvals remain connected.
Learning objectives
- Define and distinguish Lifecycle and Engineering evidence.
- Apply the lesson method to the worked digital engineering as decision support across a lifecycle case.
- Evaluate evidence, uncertainty, and AI-assisted output before making a claim.
Readiness check
Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.
Check your response
A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.
Core idea
Digital engineering is the disciplined use and integration of digital models and their underlying data to support development, test, operation, and sustainment. The center of gravity is not software adoption. It is reliable engineering communication and decision evidence across time.
Key concepts
| Lifecycle | The connected stages from stakeholder need through retirement or disposal. |
|---|
| Engineering evidence | A result plus enough provenance, uncertainty, and relevance to support a claim. |
|---|
| Decision record | The option chosen, alternatives considered, criteria, evidence, approver, and date. |
|---|
| Digital engineering | An integrated technical practice, not a synonym for CAD, AI, or paperless work. |
|---|
Step-by-step explanation
- Start with a decision such as whether a bracket design may proceed to prototype.
- Identify claims required for that decision: load capacity, stiffness, mass, manufacturability, cost, and risk.
- Name the artifacts that can support each claim: requirements, CAD, calculations, simulations, drawings, test data, and review records.
- Connect each artifact to its inputs, version, owner, status, and uncertainty so a reviewer can reconstruct the reasoning.
- Preserve the decision and its evidence links so a future requirement change can trigger a focused impact analysis.
Worked example
A team must select one of two aluminum mounting brackets. Design A is 8% lighter. Design B has measured stiffness data and a verified drawing. The only evidence for A is an unversioned screenshot of peak FEA stress.
- 1
Define the decision: release one concept for prototype manufacture.
- 2
Set minimum evidence: approved load requirement, controlled geometry, mesh and boundary-condition record, solution-verification check, and drawing review.
- 3
Grade the available evidence. A's screenshot cannot establish geometry, inputs, numerical adequacy, or reviewer status. B has traceable test and drawing evidence.
- 4
Do not claim B is globally superior. State that B is currently better supported for this decision, while A needs specified evidence before comparison.
Result. Select B for the present gate, or hold the gate until A's missing evidence is supplied. The evidence state, not the attractive 8% claim, controls the defensible decision.
Independent check. Ask whether another engineer can reproduce the comparison without interviewing the original analyst. If not, the record is incomplete.
Common misconceptions
| Misconception | Correction |
|---|
| Digital means trustworthy | A file can be digital and still be obsolete, ambiguous, or wrong. Trust comes from controlled evidence. |
|---|
| More data means a better decision | Volume does not replace relevance, quality, or uncertainty. |
|---|
Diagnostic questions
Is a PDF test report a digital artifact?
Yes. It is digital, but it may still be weakly connected or hard to query.
What makes a result evidence?
A stated claim, traceable inputs and method, quality checks, relevance to the decision, and uncertainty or limitations.
Practice ladder
BasicList five artifacts used to approve a pressure vessel component and identify the claim each supports.
IntermediateTurn a screenshot-only FEA result into a minimum evidence package.
AdvancedDesign a gate review that rejects both missing evidence and irrelevant evidence without demanding every possible analysis.
AI-assisted engineering task
Give an AI assistant a deliberately incomplete design summary and ask it to list missing evidence, separated into requirements, model credibility, test, manufacturing, and decision records. Do not ask it to approve the design.
How to prove the AI output yourself
- Check every suggested evidence item against the actual decision and discard generic checklist padding.
- Verify that claimed artifacts exist, are current, and refer to the same configuration.
- Have a responsible engineer accept or reject the final evidence plan.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
Define digital engineering in one sentence.
Integrated use of digital models and underlying data to support lifecycle engineering activities and decisions.
Why is a model screenshot weak evidence?
It hides inputs, configuration, method, checks, and reproducibility.
What is the first object in an evidence workflow?
The engineering decision or claim that the evidence must support.
End-of-lesson summary
Digital engineering is the disciplined use and integration of digital models and their underlying data to support development, test, operation, and sustainment. The center of gravity is not software adoption. It is reliable engineering communication and decision evidence across time.
Student notes
Write one sentence each for decision, claim, evidence, uncertainty, and limitation. These five lines become the spine of your course notebook.
Recommended readings
Instructor notes
Open with a familiar release decision. Require students to name the decision before naming tools. This prevents a software-centered interpretation.
1.2
Document-based, model-based, and authoritative information
Why this lesson matters
Teams often mistake the newest file, the prettiest dashboard, or the PLM copy for truth. Students need a more precise model of authority and consistency.
Learning objectives
- Define and distinguish Document-based and Model-based.
- Apply the lesson method to the worked document-based, model-based, and authoritative information case.
- Evaluate evidence, uncertainty, and AI-assisted output before making a claim.
Readiness check
Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.
Check your response
A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.
Core idea
A model-based workflow makes structured models and their data central to communication. An authoritative source of truth is governed for a defined scope; it is not infallible, universal, or necessarily stored in one system.
Key concepts
| Document-based | Meaning is primarily carried in human-readable documents, often with manual cross-checking. |
|---|
| Model-based | Structured models and data carry relationships that tools and people can query and check. |
|---|
| Authoritative source | The approved source to use for a stated data class, configuration, and time. |
|---|
| Consistency rule | A check that two artifacts agree on shared facts such as mass, revision, material, or interface location. |
|---|
Step-by-step explanation
- Separate representation from authority: a drawing, CAD model, and database can represent the same part but have different controlled roles.
- Assign authority by data class. The requirements tool may own approved requirement text, PLM may own released part revision, and the test repository may own calibrated raw data.
- Define synchronization or transformation rules between sources instead of copying values silently.
- Record effective date and configuration because authority can change after a release or change order.
- Use automated consistency checks where possible, followed by human resolution of discrepancies.
Worked example
A CAD model lists alloy 6061-T6, an old drawing lists 7075-T6, and an analyst typed E = 70 GPa into a spreadsheet. The part revision in PLM is C.
- 1
Ask which artifact is released for revision C and which system governs material specification.
- 2
Do not average or select a convenient value. Flag a configuration inconsistency.
- 3
Trace the analyst's modulus to the intended material and temperature range.
- 4
Resolve the discrepancy through the responsible design authority and update dependent analyses.
Result. The immediate output is a controlled discrepancy, not a material guess. Once revision C's authority is confirmed, all dependent models receive a traceable update.
Independent check. The corrected value must propagate to CAD metadata, drawing, analysis input, and decision record without erasing the history of the mismatch.
Common misconceptions
| Misconception | Correction |
|---|
| One database must contain everything | Federated authoritative sources can be safer and more practical when ownership and links are explicit. |
|---|
| Model-based means no documents | Contracts, procedures, reports, and approvals may remain documents; the key is controlled connection to model data. |
|---|
Diagnostic questions
Can two systems both be authoritative?
Yes, for different data classes or lifecycle states, but not ambiguously for the same fact.
Does authority prove correctness?
No. It establishes the approved source and governance, not physical truth.
Practice ladder
BasicClassify a drawing, CAD file, requirement row, and test CSV as documents, models, or data artifacts.
IntermediateAssign an authoritative owner to material, geometry, test calibration, and released configuration.
AdvancedDesign a federated authority map for a supplier, OEM, and test laboratory that prevents silent overwrites.
AI-assisted engineering task
Ask AI to compare two short artifact extracts and propose possible contradictions. Require output as candidate conflicts with exact field references, never as automatic corrections.
How to prove the AI output yourself
- Open both authoritative artifacts and verify each cited field.
- Check revision and effective date before treating different values as a conflict.
- Route unresolved differences to the named data owner.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
What makes a source authoritative?
Defined scope, ownership, approval, configuration control, and governance.
Why can a model-based workflow still fail?
Its models may be inconsistent, stale, weakly governed, or disconnected from decisions.
What should happen when two controlled artifacts disagree?
Open a discrepancy and resolve it through authority, not convenience.
End-of-lesson summary
A model-based workflow makes structured models and their data central to communication. An authoritative source of truth is governed for a defined scope; it is not infallible, universal, or necessarily stored in one system.
Student notes
For every number you reuse, note source, revision, unit, owner, and date. This habit is more important than any particular database tool.
Recommended readings
Instructor notes
Create a three-artifact contradiction and let students experience the discomfort of not choosing a value until authority is established.
1.3
Digital artifacts, provenance, configuration, and evidence quality
Why this lesson matters
A numerical result without lineage cannot be safely reused. Provenance and configuration turn isolated files into inspectable evidence.
Learning objectives
- Define and distinguish Provenance and Configuration.
- Apply the lesson method to the worked digital artifacts, provenance, configuration, and evidence quality case.
- Evaluate evidence, uncertainty, and AI-assisted output before making a claim.
Readiness check
Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.
Check your response
A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.
Core idea
Every consequential artifact needs identity, provenance, configuration, status, and relationships. Evidence quality is multidimensional: correctness alone is insufficient if relevance, coverage, or reproducibility is poor.
Key concepts
| Provenance | Who or what produced an artifact, from which inputs, by which method, and when. |
|---|
| Configuration | The exact product, model, software, parameter, and requirement versions represented. |
|---|
| Status | Draft, reviewed, approved, superseded, rejected, or archived. |
|---|
| Evidence grade | A transparent judgment of relevance, quality, coverage, uncertainty, and independence. |
|---|
Step-by-step explanation
- Give each artifact a stable identifier that does not depend on a filename alone.
- Record upstream inputs and downstream claims so change impact can traverse both directions.
- Capture software and environment only to the fidelity needed for reproduction and risk.
- Separate raw observations from cleaned data and derived results. Preserve transformations as executable or reviewable steps.
- Grade evidence against the decision, documenting weaknesses rather than hiding them in a single confidence score.
Worked example
Three stress results are available: 112 MPa from model v7 with a mesh study, 105 MPa from model v8 with no recorded load, and 118 MPa from an independent hand calculation using a conservative section modulus.
- 1
Check configuration relevance: only results matching current geometry and load can directly support the decision.
- 2
Check method quality: v7 has numerical evidence; v8 lacks a reconstructable input; the hand calculation has lower fidelity but useful independence.
- 3
Do not combine the values statistically because they are not repeated observations of one controlled process.
- 4
Use v7 and the hand check as complementary evidence if v7 matches the current configuration; quarantine v8 until its provenance is restored.
Result. Evidence strength comes from complementary, traceable checks, not from selecting the most favorable number or averaging incomparable results.
Independent check. A reviewer must be able to state exactly which result supports which claim and why excluded artifacts were excluded.
Common misconceptions
| Misconception | Correction |
|---|
| Filename equals identity | Files are renamed and copied. Stable identifiers and metadata are required. |
|---|
| A confidence score is objective | Scores hide assumptions unless dimensions and rationale are recorded. |
|---|
Diagnostic questions
Is cleaned data the same artifact as raw data?
No. It is a derived artifact with a transformation relationship.
Should superseded evidence be deleted?
Normally no. Preserve it with status so decisions and changes remain auditable.
Practice ladder
BasicWrite the minimum provenance record for a Python beam calculation.
IntermediateGrade a test report for relevance, uncertainty, coverage, and independence.
AdvancedDesign a configuration key that joins requirements, CAD, simulation, and test without relying on folder location.
AI-assisted engineering task
Ask AI to extract candidate provenance fields from a short analysis memo. Require null for missing fields and prohibit guessed versions, dates, or owners.
How to prove the AI output yourself
- Compare extracted fields against the original memo line by line.
- Mark inferred fields as unverified and obtain owner confirmation.
- Test whether the record can reconstruct the analysis on a clean machine or by an independent student.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
Name five provenance fields.
Creator, time, inputs, method or software, and configuration or version.
Why retain superseded artifacts?
They explain prior decisions and support change history and audit.
Why not average independent analysis results automatically?
Different models and assumptions are not exchangeable samples.
End-of-lesson summary
Every consequential artifact needs identity, provenance, configuration, status, and relationships. Evidence quality is multidimensional: correctness alone is insufficient if relevance, coverage, or reproducibility is poor.
Student notes
Before accepting an artifact, answer: what is it, what configuration is it about, where did it come from, what claim does it support, and what remains uncertain?
Recommended readings
Instructor notes
Have students audit one of their own prior assignments. The missing metadata will make the lesson concrete without requiring enterprise software.
1.4
AI as an engineering assistant, not an authority
Why this lesson matters
Generative systems can produce fluent but unsupported engineering statements. Students need operational controls, not a slogan about being careful.
Learning objectives
- Define and distinguish Candidate output and Grounding.
- Apply the lesson method to the worked ai as an engineering assistant, not an authority case.
- Evaluate evidence, uncertainty, and AI-assisted output before making a claim.
Readiness check
Before continuing, explain what decision this topic supports and name one upstream source that must be controlled.
Check your response
A sound answer names a specific engineering decision, its configuration, and a controlled requirement, model, dataset, interface, or standard that constrains the work.
Core idea
AI may help search, structure, compare, draft, and flag. It does not own requirements, certify evidence, establish physical truth, or accept risk. Every consequential output needs a verification route and a responsible human decision owner.
Key concepts
| Candidate output | An AI suggestion awaiting verification, not an approved artifact. |
|---|
| Grounding | Providing controlled sources and requiring evidence-linked output. |
|---|
| Human oversight | Named responsibility for reviewing, correcting, approving, and monitoring AI-assisted work. |
|---|
| Audit trail | Prompt or task, model or tool version, sources, output, checks, edits, reviewer, and disposition. |
|---|
Step-by-step explanation
- Classify the task by consequence. Brainstorming test names is different from sizing a safety-critical joint.
- Constrain the source set and output schema. Ask for citations to specific artifact identifiers, not free-form confidence.
- Design verification before running the tool: calculation, source inspection, test, independent model, or expert review.
- Record both accepted and rejected suggestions when they influence the work.
- Monitor downstream use because a correct summary can become unsafe when applied to another configuration or context.
Worked example
An AI assistant reads a bracket requirement and says: 'The design meets the 2.0 kN load requirement with a factor of safety of 2.1.' The supplied packet contains a 1.5 kN FEA result and no allowable-stress basis.
- 1
Treat the statement as an unsupported candidate claim.
- 2
Trace every number: 2.0 kN appears in the requirement, 1.5 kN appears in the analysis, and 2.1 has no source.
- 3
Reject the compliance conclusion because the evidence configuration and load do not match and allowable basis is absent.
- 4
Record the failure mode and revise the prompt or retrieval controls, but do not rely on prompt improvement as the only safeguard.
Result. Disposition: rejected. Required follow-up: analysis at the controlled load, material allowable and failure criterion, verified calculation, and engineering approval.
Independent check. A verification record must stand without asking the same AI whether its earlier answer was correct.
Common misconceptions
| Misconception | Correction |
|---|
| Citations guarantee correctness | A citation can be irrelevant, misread, or attached to a fabricated claim. |
|---|
| Human in the loop means someone clicked approve | Oversight requires competence, time, evidence access, and authority to reject. |
|---|
Diagnostic questions
May AI draft a requirement?
Yes as a candidate, followed by engineering review, source trace, quality checks, and approval.
Who owns an AI-assisted decision?
The accountable human or organization, never the model.
Practice ladder
BasicSeparate five AI tasks into low, medium, and high consequence.
IntermediateWrite a verification plan for AI-extracted test results.
AdvancedDesign an AI audit record that supports later incident investigation and model-version change.
AI-assisted engineering task
Ask AI to propose trace links between five requirements and five evidence artifacts. Require candidate link, rationale, quoted identifiers, and uncertainty. Include one deliberately misleading artifact.
How to prove the AI output yourself
- Open each source and verify identifiers and semantics.
- Check direction and link type: verifies, satisfies, derives, or merely relates.
- Reject links that depend only on word overlap or omit configuration and scope.
Retrieval and spaced review
Answer closed-notes today, then again after 1, 3, 7, and 30 days.
What status should an AI output have initially?
Candidate or unverified.
What must exist before using AI on a consequential task?
A defined verification route and accountable reviewer.
Why preserve rejected suggestions?
They reveal influence, failure modes, and the basis of later controls.
End-of-lesson summary
AI may help search, structure, compare, draft, and flag. It does not own requirements, certify evidence, establish physical truth, or accept risk. Every consequential output needs a verification route and a responsible human decision owner.
Student notes
For each AI use, record purpose, permitted sources, output status, verification method, reviewer, and final disposition.
Recommended readings
Instructor notes
Do not let the discussion become pro-AI versus anti-AI. Grade students on task definition, evidence controls, verification, and accountability.
LAB 1
Lab 1: Build a controlled requirements table in Python
Lab objective
Create a small, validated requirements register with stable identifiers, owners, verification methods, and status.
Engineering context
A mounting bracket project has four requirements arriving from design, test, and manufacturing stakeholders. The team needs one structured register before analysis begins.
Input data
- Four requirement dictionaries
- Allowed verification methods
- A required-field list
Step-by-step task
- Create the records with ID, text, rationale, source, owner, verification method, status, and revision.
- Check stable ID uniqueness and required fields.
- Check that verification methods use a controlled vocabulary.
- Print a review-ready table and a list of defects.
Python code
from pprint import pprint
requirements = [
{"id": "BRK-REQ-001", "text": "The bracket shall carry a 2.0 kN static load.",
"source": "NEED-01", "owner": "structures", "method": "analysis+test",
"status": "approved", "revision": "A"},
{"id": "BRK-REQ-002", "text": "Bracket mass shall not exceed 0.50 kg.",
"source": "ALLOC-04", "owner": "design", "method": "inspection",
"status": "draft", "revision": "A"},
{"id": "BRK-REQ-003", "text": "First mode shall exceed 120 Hz.",
"source": "DYN-02", "owner": "dynamics", "method": "analysis",
"status": "approved", "revision": "B"},
{"id": "BRK-REQ-004", "text": "The bracket shall be manufacturable by 3-axis milling.",
"source": "MFG-01", "owner": "manufacturing", "method": "demonstration",
"status": "draft", "revision": "A"},
]
required = {"id", "text", "source", "owner", "method", "status", "revision"}
allowed_methods = {"analysis", "test", "inspection", "demonstration", "analysis+test"}
defects = []
ids = [row["id"] for row in requirements]
if len(ids) != len(set(ids)):
defects.append("duplicate requirement ID")
for row in requirements:
missing = required - row.keys()
if missing:
defects.append(f'{row.get("id", "UNKNOWN")}: missing {sorted(missing)}')
if row.get("method") not in allowed_methods:
defects.append(f'{row["id"]}: uncontrolled verification method')
pprint(requirements, sort_dicts=False)
print("Defects:", defects or "none")
Explanation of code
Step 1 create the records with ID, text, rationale, source, owner, verification method, status, and revision. Step 2 check stable ID uniqueness and required fields. Step 3 check that verification methods use a controlled vocabulary. Step 4 print a review-ready table and a list of defects.
Expected output
Four structured records followed by `Defects: none`.
Interpretation
The table is not yet proof that the requirements are correct. It is a controlled starting point that exposes ownership, status, and intended verification.
Common errors
- Using requirement text as the identifier
- Mixing status with verification outcome
- Allowing free-form method names that cannot be queried
Extension tasks
- Export to JSON with a schema version
- Add change history and approval fields
- Reject vague words such as adequate or lightweight with a quality-rule function
Reflection questions
- Which fields establish authority?
- Which quality checks require engineering judgment rather than code?
- How would the records change after a requirement revision?