Many Manitoba P.Eng applicants know they need EGM CBA examples, but they are less sure what strong evidence actually looks like. A strong example is not the longest project story. It is the clearest proof that the applicant demonstrated one specific competency through real engineering work.
This guide explains how to judge the quality of your own EngGeoMB CBA examples before validator or assessor review. It focuses on engineering/P.Eng CBA examples and shows what strong evidence includes, what weak evidence misses, and how to use Situation-Action-Outcome without turning the answer into a generic template.
Every example must come from the applicant’s genuine work experience. Copied, embellished, AI-created or third-party-created workplace examples are not acceptable. Use this article for quality criteria, safe mini-structures and common mistake checks, not copy-ready submission text.
Quick Answer: What Does a Strong EGM CBA Example Look Like?
A strong EGM CBA example is a specific first-person workplace example that shows the engineering problem, the action the applicant personally took, the engineering judgement used and the outcome of that action. Strong EngGeoMB CBA examples normally include Situation, Action and Outcome, relevant calculations or methods, codes or standards where applicable, constraints, risks, verification steps, measurable results and a validator who can directly confirm the work.
Key highlights
- Strong EGM CBA examples prove one specific competency with clear first-person engineering evidence.
- The strongest examples show Situation, Action and Outcome, but the Action must carry the real proof.
- Codes, standards, calculations, models, constraints and verification steps should appear where they affect the engineering decision.
- Validators need direct knowledge of the example, so weak validator linkage can weaken even a well-written draft.
- Use examples to learn structure only; copied, embellished, AI-created or third-party-created workplace examples are not acceptable.
Why Applicants Search for EGM CBA Examples
Applicants usually look for EGM CBA examples when they want to understand structure, detail level and assessor expectations. They are often trying to answer practical questions: how much context is enough, where technical detail belongs, how to write in first person, and how to connect one real project to one competency without sounding generic.
Examples are useful when they teach quality. They become risky when treated as templates. A copied P.Eng CBA example PDF cannot reflect your employer, date range, role, calculation, decision, supervision, risk, outcome or validator knowledge.
For Manitoba applicants, the safest starting point is the EngGeoMB Competency-Based Assessment process itself: applicants demonstrate competencies through descriptions of real work situations that validators can verify. Other-regulator examples from APEGA, APEGS or PEO can help explain Canadian CBA terminology, but they are not Manitoba authority.
Strong vs Weak CBA Evidence at a Glance
| Situation | Specific project, problem, constraint or risk | General job duty or routine responsibility |
| Action | First-person engineering action and judgement | Team-only summary such as ‘we worked on…’ |
| Technical detail | Codes, standards, calculations, models, checks or methods | Vague technical language without proof |
| Engineering judgement | Explains why a method, design, review or decision was used | Lists tasks without reasoning |
| Outcome | Shows result, impact, compliance, savings, risk reduction or lesson learned | Ends without showing what changed |
| Validator fit | Assigned to someone with direct knowledge of the work | Assigned to someone who cannot confirm the example |
| Rating fit | Evidence supports the claimed level | Self-rating is higher than the evidence shown |
The comparison is simple: strong competency-based assessment examples make the applicant’s contribution visible. Weak examples leave the assessor to guess. If the example depends on job title, company reputation or team achievement instead of stated evidence, it needs revision.
Need help writing stronger EGM CBA examples from your real experience?
Get writing support that turns your genuine project details, personal actions, engineering judgement and outcomes into clearer applicant-owned competency examples.
Use the Situation-Action-Outcome Structure Properly
Situation-Action-Outcome works because it keeps the example focused. It separates the project context from the applicant’s decision-making and then shows what changed because of the action.
Situation
The Situation gives enough context for the assessor to understand the engineering setting. Include the project type, employer or role context, constraint, stakeholder, risk, code issue or technical challenge. Keep it concise. The Situation should set up the evidence, not become a resume paragraph.
Action
The Action is the core of the example and should usually be the longest part. Show what you personally calculated, designed, reviewed, verified, decided, communicated, coordinated or improved. Use first-person evidence. Name the method, tool, code, standard, assumption, constraint, alternative or check when it matters to the competency.
Outcome
The Outcome explains the result of your action. Strong outcomes are concrete: compliance achieved, design accepted, risk reduced, safety improved, cost exposure clarified, schedule protected, error corrected, lesson learned or decision made. Tie the outcome back to the competency rather than only celebrating project completion.
The Engineering Applicant Guide uses these fields for competency examples and places the most detailed evidence in the Action section, where applicants explain the actions, engineering judgements or solutions that demonstrate the competency.
What EngGeoMB Assessors Look for in CBA Examples
Assessors are not reading for polished storytelling alone. They review whether each example provides sufficient evidence for the key competency, whether the self-rating fits the evidence, whether the validator rating and comments support the claim, and whether the overall work history shows progression toward professional practice.
Breadth, depth and quality matter. Breadth means the submission covers the framework instead of repeating one narrow project. Depth means the example shows enough technical or professional substance. Quality means the example is specific, coherent, verifiable and aligned with the competency.
Implied evidence is a common problem. Assessors cannot assume an applicant understands a code, risk, calculation or professional obligation because of a job title. If the example does not state the evidence, the assessor cannot reliably use it.
When an example reaches validator and assessor review, the evidence has to stand on its own. The writing should make the self-rating, validator feedback, example depth and professional judgement easy to understand without forcing the assessor to infer missing details.
Write your EGM Manitoba competency report with stronger evidence
We help organize your real work experience into clear CBA wording, flag missing proof, and check whether each example fits the competency and rating level.
What Validators Need to Confirm
Validators need direct personal and professional knowledge of the work they are confirming. For engineering applicants, the CBA submission asks for a minimum of four validators, and each assigned example should be linked to someone who can verify the specific role, action and responsibility described.
Validator risk appears when the example is too vague, claims responsibilities the validator did not observe, assigns too many examples to someone with limited knowledge, or describes work from a team perspective rather than the applicant’s own contribution. A strong draft makes the validator’s job easier because the role, dates, project context and evidence are clear.
Before assigning an example, check whether the validator can confidently answer three questions: did this applicant do this work, was the described level of responsibility accurate, and does the evidence support the rating claimed?
What Strong Evidence Looks Like by Evidence Type
Technical Evidence
Technical evidence identifies the engineering work itself: calculations, design method, modelling approach, assumptions, standards, code sections, peer review, QA/QC steps, safety considerations or field verification. Avoid saying only that you applied engineering principles. Name the principle, show how it shaped the decision and explain how you checked the result.
Management Evidence
Management evidence should stay connected to engineering work. Use planning, scope control, technical requirements, resources, schedule constraints, cost monitoring, feedback and decision-making where they affected engineering quality, risk, compliance or delivery. Generic schedule tracking belongs in a project update, not in a strong CBA example.
Communication Evidence
Communication evidence should involve engineering meaning. Strong examples include technical reports, review memos, design explanations, client presentations, drawings, specifications, field notes or meeting summaries where the applicant translated technical information for a clear audience and purpose.
Professional Accountability Evidence
Professional accountability evidence shows judgement and responsibility boundaries. It can involve an ethical decision, scope limitation, conflict of interest, liability awareness, stamp/seal understanding or escalation of work outside competence. Do not imply professional authority the applicant did not hold.
Canadian Environment Evidence
Canadian environment evidence connects the example to Canadian regulations, codes, standards, quality control, safety awareness, professional accountability or communication. International examples can work when the applicant explains equivalency to the Canadian work context and makes the comparison explicit.
For engineering applicants, Canadian environment competencies cover eight competencies, and international work examples must demonstrate equivalency to the Canadian context.
Safe Mini-Example Format: How to Learn Without Copying
Use the structure below as an illustrative structure only. It is not a submission-ready answer and should not be copied into a live CBA. Replace every field with your own genuine work, dates, role, decisions, calculations, communications, validator and outcome.
| Situation | One specific engineering problem, constraint, stakeholder issue or risk. |
| Action | Your own calculation, design judgement, code use, review, decision, communication or coordination. |
| Outcome | What changed because of your action and how the result supports the competency. |
| Validator | The person who can confirm the specific work and your responsibility. |
| Rating check | Why the evidence supports the claimed competency level. |
A safe P.Eng CBA example structure helps applicants learn what belongs in each field. It does not give anyone permission to borrow content, invent missing project details or polish another person’s work into their own evidence.
12 Mistakes to Avoid in EGM CBA Examples
Mistake 1: Writing Team Duties Instead of Personal Actions
Strong EngGeoMB CBA examples use first-person action. Replace team-only phrasing with the specific work you performed: what you calculated, reviewed, selected, checked, explained, escalated or decided. If the example says only ‘we designed’ or ‘the team completed’, your individual contribution is hidden.
Mistake 2: Giving a Job Description Instead of a Specific Situation
A routine duty does not prove competence by itself. Select a project, problem, constraint, risk, design change, review issue or decision point. The reader should know what happened, why it mattered and where your responsibility began.
Mistake 3: Leaving Out the Engineering Judgement
Do not stop at describing the task. Explain why the method, standard, calculation, design option, review approach or risk control was appropriate. Engineering judgement is often the difference between a work-history note and a competency example.
Mistake 4: Naming Codes or Standards Without Applying Them
Listing CSA, NBC, ASME, IEEE or local regulations is not enough. Show how the code or standard affected a design limit, calculation method, material choice, clearance, safety factor, inspection step, documentation requirement or approval pathway.
Mistake 5: Using Software Output Without Independent Verification
Software output is weak evidence when the applicant does not explain verification. Add the engineering check: hand calculation, alternate method, sensitivity check, peer review, input validation, field comparison or review of assumptions.
Mistake 6: Confusing Project Management With Technical Competence
Budget, schedule and resources can support Project and Financial Management, but they do not automatically prove technical competence. Connect management decisions to engineering requirements, constraints, risks, technical quality or design outcomes.
Mistake 7: Overstating Responsibility or Authority
Be accurate about supervision and authority. Do not imply you sealed drawings, approved final designs or carried professional responsibility beyond your actual role. A supervised decision can still be strong when the applicant explains their real contribution honestly.
Mistake 8: Reusing the Same Story Without Reframing the Evidence
One project can support more than one competency, but each answer must highlight the right evidence. Repeating the same story across unrelated competencies looks like filler unless each version focuses on a distinct decision, action or outcome.
Mistake 9: Ignoring Constraints, Trade-Offs or Negative Results
Strong examples often include limits: budget pressure, field access, safety risk, code conflict, constructability issue, client requirement, environmental condition or failed first approach. Constraints show the judgement behind the decision.
Mistake 10: Writing Checklist-Style Answers
CBA indicators are guidance, not a line-by-line form. A strong answer reads as a coherent evidence narrative. Use indicators to choose the right proof, then write the example around the real situation, action and outcome.
Mistake 11: Weak Validator Linkage
An example should be assigned to someone who can confirm the specific work. If the validator only knows the project generally, the example needs a better validator or clearer evidence. Discuss example fit with validators before submission where appropriate.
Mistake 12: Poor Clarity, Grammar or Structure
Poor writing can hide good engineering evidence. Fix flow, first-person consistency, dates, technical terms, sentence clarity, rating alignment and competency focus. Clear writing helps the assessor see the engineering judgement already present in the work.
The engineering CBA interpretation statements reinforce many of these quality checks: specific codes and standards, engineering constraints, independent verification, engineering-related communication, real accountability decisions and sustainability as environmental sustainable development.
Avoid common EGM CBA writing mistakes before validator review
Strengthen your applicant-written examples for first-person ownership, engineering judgement, Canadian-environment evidence, structure and validator fit.
Special Caution: AI, Third-Party Writing and Copied Samples
Applicants can get writing support with clarity, structure, evidence mapping and wording, but the workplace examples must remain applicant-owned. Safe support organizes real experience, improves grammar, flags missing evidence, checks competency alignment and helps the applicant present genuine work clearly.
Unsafe support creates or embellishes projects, invents calculations, copies another person’s sample, overstates responsibility, changes supervision history, or makes the example sound more independent than the work really was. That kind of help creates credibility, validator and compliance risk.
CDRReportWriter is not affiliated with Engineers Geoscientists Manitoba. We do not submit applications, guarantee registration outcomes or create workplace experience. All competency examples must be based on the applicant’s genuine work, decisions, responsibilities, calculations, communication, supervision and outcomes.
Final Self-Review Checklist Before Sending Examples to Validators
- Did I write in first person?
- Is the situation specific enough to understand the engineering context?
- Is the action mainly about my own work, not the team generally?
- Did I show engineering judgement, not only task completion?
- Did I include technical detail where the competency requires it?
- Did I connect the evidence to the specific competency?
- Is the outcome clear and connected to my action?
- Is the self-rating realistic for the evidence shown?
- Can the validator confirm this exact example?
- Is the example recent enough where possible?
- Did I avoid copied, embellished or third-party-created content?
- Did I check Canadian-environment requirements where relevant?
Ready to prepare your EGM Manitoba competency report?
Get focused writing and review support for P.Eng CBA examples, employment history, ratings and final consistency using your genuine engineering experience.
When Your Example May Need More Evidence
Revise the example before validator review when the draft relies on broad claims instead of visible proof. A strong example should make the project context, personal action, engineering judgement, outcome, self-rating and validator fit easy to understand.
Common warning signs include mostly “we” language, no specific project problem, no technical method, no relevant code or standard where one should apply, no result, no validator fit, routine administration only, training attendance without application, or a self-rating that sounds higher than the written evidence.
The fix is not to make the story longer. The fix is to add the missing proof: the decision, calculation, check, constraint, communication, risk control, result or validator connection that shows why the example supports the competency.
Frequently Asked Questions
1. What does a strong EGM CBA example look like?
A strong example is specific, first-person, engineering-related and verifiable. It explains the situation, the applicant’s action, the engineering judgement used and the outcome created.
2. Should I write “I” or “we” in EngGeoMB CBA examples?
Use “I” for your own actions. You can mention the team for context, but the evidence should show what you personally did and took responsibility for.
3. Can I use the same project for multiple CBA competencies?
Yes, when the same project genuinely contains different evidence. Each competency answer should focus on the specific action and outcome relevant to that competency.
4. Can I copy a P.Eng CBA example PDF?
No. Use examples only to understand structure and evidence quality. Copied or adapted samples can create validator mismatch, credibility problems and weak evidence.
5. What is the Situation-Action-Outcome format?
It is a simple structure: Situation explains the engineering context, Action explains what you personally did, and Outcome explains the impact or result.
6. What do EngGeoMB assessors look for in CBA examples?
Assessors look for clear and specific evidence, rating fit, validator feedback, breadth, depth, quality, progression of responsibility and readiness for professional practice.
7. How specific should CBA examples be?
They should be specific enough that a validator can recognize the work and an assessor can see the competency. Include role, project context, action, technical detail and outcome.
8. Do validators need direct knowledge of each example?
Yes. A validator should be able to confirm the specific work, role and responsibility described in the assigned example.
9. Can international work examples be used?
Yes, international examples can support EngGeoMB CBA when they are genuine, engineering-related and, for Canadian environment competencies, clearly equivalent to Canadian context.
10. Do I need Canadian codes and standards in every CBA example?
No. Use codes and standards where they are relevant to the competency and project. Canadian environment examples need clear connection to Canadian regulations, codes, standards or practice context where applicable.
11. What happens if my validator thinks an example is weak?
The validator can request revision or provide feedback. Treat that as a chance to clarify the evidence before assessor review.
12. Can someone review my CBA examples without writing them for me?
Yes. Writing and review support can improve clarity, structure and evidence alignment as long as the examples remain based on the applicant’s real work and are not invented, copied or embellished by someone else.
