Civil Engineering Design Report

Proof required

Submit: (1) a design basis statement (300–400 words) specifying the loading, standards, materials, and site constraints; (2) a design drawing with annotated dimensions, material grades, and a title block (project name, drawn by, date, scale); (3) a note confirming which design standard (Eurocode, AASHTO, BS 8110, or equivalent) governs the design.

What gets checked

• Loading conditions are specified with numerical values and load combinations — 'dead load 5 kN/m² + imposed load 3 kN/m²; ULS combination = 1.35G + 1.5Q per Eurocode 1' not 'standard loads'
• Design drawing includes dimensions with units, material grades, and is at a consistent scale — a sketch without scale or dimensions is not an engineering drawing
• Design standard is cited by document number or edition — 'Eurocode 2: EN 1992-1-1:2004' not 'Eurocode' or 'British Standards'

Common mistakes

• Selecting a scenario too complex to complete a proper design analysis in M2 — a multi-storey frame with dynamic loads is not appropriate for an undergraduate design report; a simply supported beam, a pad foundation, or a single-story retaining wall is correctly scoped
• Producing a pictorial sketch rather than an engineering drawing — an engineering drawing has a scale, dimensions, material specifications, and a title block; a perspective sketch has none of these

Resources

What a verifier looks for

• Engineering Design Triad: M1 produces a design artifact (drawing with design basis) — this is the first of the three artifact types required across M1–M3.
• Loading specification must be quantitative and cite the applicable load combination from the design standard — 'standard loads' is not a design basis.
• Drawing must include dimensions, scale, and material specifications — a pictorial sketch does not meet the engineering drawing standard.
• Design standard must be cited by document number — the reviewer needs to know which edition governs the design to check code compliance.
• Reviewer should have civil or structural engineering background — general engineering review is insufficient for code-based structural design.

You'll sign in first, then come straight back here.

Proof required

Submit your full calculation set showing: the design action effects calculation; the element sizing or capacity check; the code compliance verification (ULS capacity ≥ ULS demand, with utilisation ratio); and a summary table of all results. All intermediate values must carry units. If using a spreadsheet, the formula bar must be visible in screenshots or formulae must be printed.

What gets checked

• Code compliance is checked as a utilisation ratio — (design demand / design resistance) ≤ 1.0; a utilisation of 0.87 is shown, not just 'passes the check'
• All calculation steps carry units through to the final result — a moment in kN·m used in a section modulus calculation in mm³ must include explicit unit conversion
• Design action effects are calculated from first principles or cited design aids — not assumed from a textbook example value without checking against the actual design basis

Common mistakes

• Checking only the ULS condition and omitting the SLS check (deflection, crack width, settlement) — both limit states are required by Eurocodes and AASHTO; an incomplete limit state check is a code non-compliance
• Calculating without referencing the specific code clause that justifies the calculation method — design calculations must be traceable to the standard; a calculation without a code reference cannot be checked for compliance

Resources

What a verifier looks for

• Engineering Design Triad: M2 produces the analysis artifact (design calculations + code compliance check) — the utilisation ratio and unit-consistent calculation set are the core verification evidence.
• Both ULS and SLS checks must be present for structural scenarios — a submission with only ULS is code-incomplete.
• Code clause references must appear in the calculation — check that each calculation method cites the standard clause that justifies it.
• Units must be carried throughout — reject submissions with unit-less intermediate values; this is a fundamental engineering documentation standard.
• Reviewer must be a civil or structural engineer who can evaluate code compliance — the utilisation ratio and limit state checks require discipline-specific expertise to verify.

You'll sign in first, then come straight back here.

Proof required

Submit: (1) your complete civil engineering design report (all sections above); (2) a code compliance summary table (limit state, demand, resistance, utilisation ratio, pass/fail); (3) a written record of the reviewer's technical challenge and your response (200 words minimum, attributing reviewer by professional role).

What gets checked

• Code compliance summary table is complete for all applicable limit states — ULS bending, ULS shear, SLS deflection minimum for an RC element; each row must show demand, resistance, and utilisation ratio
• Design alternative discussion names a specific alternative and gives a specific technical reason it was rejected — 'a steel section was considered but rejected because the beam depth would exceed the architectural constraint of 400mm' not 'other options were considered'
• Reviewer challenge record shows a substantive engineering exchange — the reviewer questioned a specific assumption (e.g. soil bearing capacity assumed, load combination used, material partial factor applied) and the student's response addressed the technical rationale

Common mistakes

• Omitting the design alternative discussion — this is the section that demonstrates engineering judgment, not just calculation execution; a report without it is incomplete
• Code compliance table that lists only 'pass' without the numerical utilisation ratios — a table of pass/fail without numbers is not engineering documentation

Resources

What a verifier looks for

• Engineering Design Triad check: M1–M3 together produce a design artifact (dimensioned drawing), an analysis artifact (code-compliant calculations with utilisation ratios), and a documentation artifact (full design report with compliance summary) — confirm all three are present.
• Code compliance summary table must include numerical utilisation ratios — not just pass/fail.
• Design alternative section must name a specific alternative and give a specific technical rejection reason.
• Reviewer challenge record must show a genuine technical exchange — not just an overall assessment or approval.
• Reviewer must be a civil or structural engineer with design experience — the code compliance check and design alternative evaluation require discipline-specific expertise.
• The Proof Accessibility Rule applies — draw.io, FreeCAD, Python, and free Eurocode worked examples are all free.

You'll sign in first, then come straight back here.