Digital Engineering Foundations · Module 8 of 8
Integrated Mechanical Engineering Application
One bounded case, end to end. Take the bolted bracket you have built across the course and connect its stakeholder need, requirements, architecture, models, evidence, configuration, change impact, decision records and review into a single, inspectable digital thread.
Readiness check
This module assembles Modules 1–7. Tick only what you can already produce.
- An artifact register with identifiers, status and baselines (Module 2).
- Verifiable requirements and a lightweight architecture with allocations (Module 3).
- A model register with purpose, scope and assumptions (Module 4).
- Evidence records with methods, criteria and credibility (Module 5).
- A typed digital thread and an AI audit record (Modules 6–7).
The core idea
Digital engineering is proven not by any single artifact but by whether the whole chain, need, requirement, architecture, model, evidence, configuration, decision and review, connects for one real case.
The bolted bracket is that case: a compact clamp/mount subsystem that carries a payload load into a fixed frame through two M6 fasteners. Every earlier module produced one layer of its evidence. Here you assemble them so another engineer can start from the release decision and walk back through the decision record, the verification evidence, the model and its configuration, to the requirement and the stakeholder need, and can see exactly what a proposed change would touch.
The skills, taught in order
Four moves assemble the capstone from the deliverables you already have.
8.1 Frame the case: need, requirements, architecture
State the stakeholder need in one sentence (a payload must be held to a fixed frame within an envelope, safely and affordably). Bring in the 6–10 verifiable requirements from Module 3 with their methods, and the lightweight logical/physical architecture with allocations. Confirm every requirement is measurable and every function is allocated to a component or interface, the anchor points for everything downstream.
8.2 Model, assumptions and evidence
Attach the Module 4 model register (purpose, scope, assumptions, owner) and the Module 5 evidence records (method, acceptance criterion, applicability, credibility). For each requirement, name the verification method and the evidence item that closes it, and mark any requirement still open. Keep each model result tied to its configuration so a reviewer can judge admissibility, not just read a number.
8.3 Configuration, baselines and provenance
Pin the package to a baseline (B0 concept, then B1 after any requirement revision) using the Module 2 register: only compatible, reviewed artifacts, with open issues visible and each derived result reproducible from recorded inputs. The baseline is the comparison point that makes the next step, change impact, meaningful.
8.4 Change impact, decision records and the digital thread
Assemble the Module 6 typed thread so the artifacts are navigable, then run one real change (for example, the load requirement rising to 650 N) through it: traverse to candidates, disposition each with a reason, refresh the affected evidence, and record the outcome. Write the decision note that cites controlled evidence and states that any AI suggestions were verified (Module 7 audit record). The finished thread lets anyone walk from the decision back to the need, and forward from a change to its review list.
Labs used here. The capstone reuses all six: artifact register, requirements, traceability, model register, thread graph and AI trace evaluation, plus the final-project template.
Worked example 1: walking the thread back from a decision
A reviewer challenges the bracket's B1 release. Show the thread supports it by walking from the decision back to the need.
- ProblemDemonstrate that the release decision is defensible by tracing it to controlled evidence and the original need.
- Given / findDEC-B1 (release) cites RESULT-STRESS-02 and TEST-FATIGUE-01. Find whether the chain is complete, current and on-configuration.
- ModelWalk each cited evidence item to its model/method, to the requirement it verifies, to the function and need, checking configuration and credibility at each hop.
- SolveRESULT-STRESS-02 ← MOD-STRESS (purpose: release-level, geometry B1, convergence recorded) → verifies REQ-LOAD (600→650 N) → allocated to function "transfer load" → need "hold payload safely." TEST-FATIGUE-01 → verifies the fatigue requirement → same function. Both cite baseline B1; the mass and interface requirements close by inspection. No open safety-relevant issue remains.
- CheckEvery hop is on B1, each result has recorded credibility, and no requirement is orphaned, the coverage check passes.
- ConclusionThe decision is defensible because the thread is complete and on one baseline. If any hop were off-configuration or uncredited, the reviewer would have found the gap immediately.
Worked example 2: pushing a change through the whole thread
Late in the project the payload grows, raising the load requirement to 650 N. Run it through the capstone.
- ProblemProcess a requirement change end to end and produce a defensible, updated release.
- Given / findREQ-LOAD 600 → 650 N after B0. Existing evidence built at 600 N. Find the new baseline, the review list and the decision.
- ModelOpen a new baseline; traverse the thread for candidates; disposition, refresh and re-verify; record the decision with credibility and any AI audit.
- SolveOpen B1. Candidates from REQ-LOAD: MOD-STRESS/RESULT (update-required, re-run at 650 N on B1 geometry with a convergence check), TEST-FATIGUE (update-required, new load), DEC (review). Mass and interface requirements: no-impact but revision-controlled. AI proposed the candidate list; it was scored and human-approved (Module 7). Refresh evidence, confirm peak stress ≤ 0.6·yield at 650 N, re-run fatigue, then issue DEC-B1 citing the refreshed evidence.
- CheckOld 600 N evidence stays in B0 history as superseded, not deleted; the small stress margin is backed by a recorded credibility statement, not assumed.
- ConclusionA change is not a crisis when the thread exists: it is a bounded review list, a refreshed baseline and a recorded decision, exactly the capability the course set out to build.
Misconceptions and diagnostics
| Mistake | Diagnostic question | Correction |
|---|---|---|
| The capstone is a new document to write | "Which earlier deliverable does this restate?" | It connects the deliverables you already built; it does not duplicate them. |
| A full package means a defensible one | "Is every claim on one baseline and credible?" | Completeness plus configuration and credibility make it defensible. |
| A change requires rebuilding everything | "What does the thread traversal actually list?" | Only the downstream candidates need review; disposition each. |
| The digital thread proves the design is correct | "Is the linked evidence itself credible?" | The thread makes evidence inspectable; it does not make weak evidence strong. |
| AI can close the loop | "Who signed the decision note?" | An accountable engineer signs; AI output is verified assistance only. |
Build the capstone
Collect your Module 2–7 deliverables for one real subsystem into a single package: register, requirements, architecture, model register, evidence records, digital thread and AI audit record.
What good work looks like
Every layer present, cross-referenced by stable identifiers, and pinned to one baseline. Missing layers are named as open items, not hidden.
Walk from your release decision back to the stakeholder need. Fix any orphan requirement, orphan evidence, or off-configuration hop you find.
What good work looks like
A complete decision-to-need path, a coverage statement, and every result on the current baseline with recorded credibility.
Introduce one realistic change, traverse the thread, disposition candidates, refresh evidence, and issue an updated decision note.
What good work looks like
A new baseline, a short human-dispositioned review list, refreshed evidence, superseded (not deleted) prior evidence, and a signed decision note.
Produce the final connected package and a one-page decision note that cites controlled evidence and states what a human verified, including any AI-assisted step.
What good work looks like
A package another engineer can inspect end to end, and a decision note whose every claim is traceable to current, credible evidence on one baseline. This is the evidence that you can do digital engineering, not just use digital tools.
Working with AI, and proving it yourself
Use AI as an examiner, not a solver
Portfolio task
Use AI only inside bounded checks on your capstone (coverage, candidate impact), record each use in the audit trail, and sign the final decision note yourself.
Retrieval and spaced review
Closed notes. Answer out loud, then reveal.
1. What proves digital engineering capability?
A complete, connected chain, need to decision, that another engineer can inspect and reproduce for one real case.
2. What makes a full package defensible, not just complete?
Every claim on one baseline, current, and backed by recorded credibility.
3. How does a mature thread turn a late change from a crisis into routine?
Traversal yields a bounded candidate list; the team dispositions, refreshes evidence and records an updated decision.
4. What happens to superseded evidence after a baseline change?
It stays visible in the prior baseline's history as superseded, not deleted.
5. Who signs the decision note, and what does AI contribute?
An accountable engineer signs; AI contributes verified, audited assistance only.