Some competencies in the P.Eng. Competency‑Based Assessment (CBA) licensing steps are more difficult to pass than others. Competency 1.5: Solution Techniques is one of the most commonly rejected.
On the 0 to 5 rating scale, assessors want clear evidence that you selected an appropriate solution technique for an engineering problem and independently verified that the results were correct.
This article explains why Competency 1.5 is often rejected and how to rewrite your example to meet what assessors are actually looking for.
If you want an overview of all 34 competencies and how 1.5 fits into the bigger picture, visit the CBA competencies guide.
Why Competency 1.5 gets rejected
Assessors repeatedly flag 1.5 responses for issues like:
- No independent verification of results. The applicant describes doing work in a team or following standard procedures, but never shows how they personally checked that the solution or model was correct.
- Only comparing to code limits or safety factors. Candidates say “settlements were within code” or “stresses were below allowable” but do not show how they confirmed the underlying analysis or model was valid.
- Not actually an engineering solution technique. Examples are about budget reviews, schedule tracking, or running a compliance test to a standard, rather than applying an engineering solution technique and verifying its results.
- Too generic or list‑based. Responses give a checklist of things “engineers should do” instead of one specific situation with step‑by‑step evidence of what the applicant did.
- Unclear English. In some cases assessors cannot tell whether the candidate performed their own calculations or which technique was used because the writing is unclear.
What assessors expect to see for 1.5 – Solution Techniques
For a strong 1.5 example, assessors are looking for three things:
- A specific solution technique. For example, finite element analysis (FEA), a pipe‑network model, a custom spreadsheet, or another engineering analysis method that required you to make technical choices.
- Evidence that you used the technique on a real engineering problem. Show the project, input data, assumptions, and constraints you worked with.
- Independent verification of the results. Demonstrate how you checked that the technique and the results were correct, not just within code limits.
The “independent verification” piece is where most applicants lose marks. You need to show how you:
- Did hand calculations or simplified checks to confirm that software results made sense.
- Ran alternative methods (for example, two different design approaches or two different load cases) and compared the outcomes.
- Used field measurements, test results, or monitoring data to validate model predictions.
- Checked sensitivity to key parameters (e.g., soil stiffness, load combinations, temperature, flow rate) and confirmed the design was still acceptable.
Examples that usually do not work for 1.5
Assessors have rejected 1.5 examples when they were mainly about:
- Budget reviews or cost comparisons. Comparing your budget to a colleague’s or updating cost estimates is project management, not solution‑technique verification.
- Only running a test to a standard. Simply running a lab test or inspection to confirm compliance with a code or specification, without describing any analysis or checking of the underlying model or calculations.
- Risk framed as “losing a client”. The main risk in your example should be technical or public‑safety related, not just business or relationship risk.
- High‑level descriptions. Saying “we verified all calculations” or “we followed QA/QC procedures” without explaining what you actually did.
If your current 1.5 example sounds like any of these, it is worth replacing or rewriting it.
How to structure a strong 1.5 example
Use a clear Situation–Action–Outcome (SAO) structure and focus on one specific technical problem.
Situation
- Briefly describe the project and the engineering problem you needed to solve.
- State which solution technique you chose (e.g., FEA, hydraulic model, custom spreadsheet) and why it was appropriate.
Action
This is where you show independent verification. Include details like:
- How you set up the model or calculations (key assumptions, boundary conditions, load cases, material properties).
- How you checked the model itself (mesh density, element types, convergence, units, boundary conditions).
- What hand calculations or simplified checks you used to confirm that the software outputs were reasonable.
- Any alternative methods or sensitivity checks you ran (e.g., varying a parameter and seeing how results changed).
- How you used field data or measurements to compare against predicted values, if available.
Outcome
- Summarise how your verification gave you confidence in the results and led to an engineering decision.
- Note any changes you made because of your checks (for example, refining the mesh, correcting input data, adjusting design dimensions).
- State how this reduced technical or safety risk (not just commercial risk).
Mini example: from weak to stronger 1.5 evidence
Weak: “I built an FEA model of a footing and confirmed that settlements and bearing pressures were within code limits, so the design was acceptable.”
This tells the assessor nothing about whether the model was correct. It only compares results to code limits.
Stronger: “I built an FEA model of the footing using nonlinear soil springs. I first checked the model by hand using a simplified elastic solution to estimate settlement and bearing pressure, and confirmed the FEA results were within 5–10% of the hand values. I then refined the mesh around the footing edge and re‑ran the model to confirm the results were mesh‑independent. Finally, I compared predicted settlements against monitoring data from a similar footing on the same site to confirm that the order of magnitude matched field behaviour before finalizing the design.”
This second version clearly shows a solution technique, how it was applied, and how the applicant independently verified the results.
Language and clarity for international applicants
If English is not your first language, keep your writing simple:
- Use short sentences and the first person: “I calculated…”, “I verified…”, “I checked…”.
- Avoid long lists of tasks. Focus on one example and walk the assessor through what you did in order.
- Ask a colleague to read your example and confirm they can tell exactly which solution technique you used and how you verified it.
Next step: get help with Competency 1.5 (and the rest of your CBA)
If you are unsure whether your Competency 1.5 example shows enough independent verification, you are not alone. It is one of the most frequently rejected competencies across Canada.
Inside the CBA Blueprint course you will find:
- Accepted 1.5 examples you can model your own writing on.
- Guidance on common rejection reasons for each competency, including 1.5.
- AI tools that score your draft and highlight where you need more detail.
Start the CBA Blueprint to reduce the risk of resubmissions and keep your P.Eng. timeline moving.