CBA Competency 1.1 – Regulations, Codes and Standards (Often Rejected)
Some competencies in the P.Eng. Competency‑Based Assessment (CBA) licensing steps are more complex than others to meet the minimum score on the 0 to 5 rating system.
Competency 1.1 – Regulations, Codes and Standards is one of the 10 most frequently rejected. Assessors want to see that you understand which engineering regulations and standards apply to your work and how you used them to make design or technical decisions.
If you want an overview of all 34 competencies and how 1.1 fits into the full framework, visit the CBA competencies guide.
Why 1.1 gets rejected
From real assessor comments, Competency 1.1 has been rejected because:
- No Canadian‑environment example is given. Assessors note that the applicant’s knowledge of Canadian codes and standards is not clear, or the example is entirely outside Canada with no comparison to Canadian requirements.
- Codes are only mentioned in general terms. Responses say “I had to follow all regulations” but provide no specific regulation or standard names, clauses, or authorities.
- Management standards are used instead of engineering codes. Applicants focus on ISO or management‑system certifications that say little about engineering design requirements.
- Ethics replaces technical codes. Some candidates talk mainly about the Code of Ethics, which is covered under other competencies; 1.1 is looking for technical regulations, codes, and standards.
- Activities are not really engineering. Examples such as “running an error checker” or clicking a software tool, without explaining how design was changed to comply with a standard, do not meet the competency.
- Improper “approval” of work. Applicants describe approving drawings for submission even though they are not a P.Eng. or did not supervise the work directly, which raises separate professionalism concerns.
- Only a single test method is cited. Citing one performance test standard with no explanation of how the broader regulatory framework affected the design misses the intent of 1.1.
What assessors really want to see for 1.1
A strong 1.1 example shows that you can:
- Identify the main regulations, codes, and standards that apply to your project (for example, building codes, safety codes, CSA / ASTM / IEEE / IEC standards, municipal bylaws).
- Explain why those specific documents were relevant to your design or analysis.
- Apply clauses in context – show how particular requirements (loads, clearances, materials, testing, documentation) shaped your calculations or drawings.
- Demonstrate engineering judgement – for example, when two standards could apply, explain which one you followed and why.
- Respect professional limits – describe what you did as an EIT / MIT, and avoid implying you sealed or approved work you were not permitted to.
- Connect international work to Canada – if you use non‑Canadian examples, compare the regulations you followed to their Canadian equivalents or show how they meet or exceed Canadian expectations.
How to structure a strong 1.1 example
Choose one project and write in first person (“I + verb”). A clear 1.1 example usually covers:
- Project context: Briefly describe the project, your role, and the main regulatory framework (for example, provincial building code, electrical code, pipeline code, municipal standards).
- Specific regulations, codes, and standards: Name the main documents you used and, where appropriate, refer to specific sections or parts that were key to your work.
- Design decisions driven by those documents: Explain how particular clauses affected your sizing, layout, materials, protection systems, testing, documentation, or acceptance criteria.
- How you checked compliance: Describe calculations, design checks, model settings, or inspections you performed to confirm the work met the required codes.
- Outcome: Summarise how following the regulations, codes, and standards reduced technical or safety risk and led to an accepted design or installation.
Applicants should provide an example of applying engineering theory to solve a problem or design a system, clearly anchored in the relevant regulations and standards.
Mini example: weak vs stronger 1.1 evidence
Weak: “I had to follow all relevant regulations for vehicle software, so I ran an automatic error checker on the code and fixed the warnings it showed.”
This does not tell the assessor which standard applied or how it affected your design.
Stronger: “On an embedded control project, I was responsible for implementing safety‑related functions according to the MISRA C guidelines. I reviewed the MISRA rules applicable to our codebase and configured the static analysis tool to check for those violations. When the tool flagged rule breaches (for example, use of non‑constant pointers in safety‑critical functions), I refactored the code to comply with the guideline and documented the changes in our design description. I also added peer review steps focused on MISRA compliance for high‑risk modules.”
This second version names the standard, shows how it influenced design decisions, and demonstrates active application of the code.
Next step: get help with Competency 1.1 (and the rest of your CBA)
If you are not sure whether your Competency 1.1 example shows enough specific, engineering‑focused use of regulations, codes, and standards, it is worth revisiting before you submit.
Inside the CBA Blueprint course, you will find:
- Accepted 1.1 examples from different disciplines that you can model your own writing on.
- Guidance on common rejection reasons for 1.1 and how to avoid them.
- Tools and checklists to help you name the right regulations and explain how they affected your design.
Start the CBA Blueprint to reduce the risk of resubmissions and keep your P.Eng. application moving.