APEGS Competency Assessment Examples: Strong vs Weak Evidence, Sample PDFs and Mistakes to Avoid

A strong APEGS competency example makes eight things visible: competency fit, an engineering or geoscience context, a specific and verifiable situation, personal action, professional judgement, a credible outcome, evidence for the claimed level and a validator who directly knows the work. A weak example usually describes duties, team activity or a successful project without proving what the applicant personally decided and why that decision demonstrates the named competency.

Applicants often review APEGS competency assessment examples because seeing evidence in context makes the framework easier to understand. The challenge is learning the right lesson from a sample. A polished PDF may show report architecture, yet its project facts, discipline, responsibility, validator arrangement and rating belong to one applicant and one point in time.

This evidence-quality clinic explains how to interpret the official applicant-view sample, diagnose strong and weak patterns and review a complete draft before validation. Every comparison fragment is fictionalized and intentionally brief. The finished submission must remain an accurate, applicant-authored record that the selected validator can confirm.

Quick Answer: What Makes an APEGS Competency Example Strong?

A strong APEGS competency example presents one specific work event, connects it directly to the competency and shows what the applicant personally analysed, decided, communicated or managed. It includes enough technical or professional detail to reveal judgement, closes with a credible outcome and supports the selected rating through scope, complexity, responsibility and supervision.

• One identifiable and verifiable situation
• Direct alignment with the competency and interpretation statement
• A genuine engineering or geoscience practice context
• First-person actions that separate individual work from team activity
• Relevant principles, codes, constraints, risks, stakeholders or trade-offs
• An outcome connected to the applicant’s action
• Scope and responsibility consistent with the self-rating
• A validator with firsthand knowledge of the work

Is There an Official APEGS Competency Report Sample PDF?

Yes. The official APEGS applicant-view competency report sample is a 29-page example of how a completed report is organised. It is most useful as a structural reference: it shows category summaries, employment history, competency entries, Situation-Action-Outcome fields, self-ratings and validator information in one applicant view.

What the Official Applicant-View Sample Shows

• How employment records and competency examples appear in the same report
• How each competency entry identifies an employer, position, validator and date
• How Situation, Action and Outcome are separated
• How self-ratings appear beside category requirements
• How a full engineering report progresses across the competency categories

What the Sample Cannot Establish for Your Submission

The sample cannot establish that its wording is the strongest possible wording today, that its field presentation reflects every current portal detail, or that the same example would support another applicant’s discipline and rating. It also cannot establish approval for copied or lightly paraphrased content. Current requirements are controlled by the live system, the current guide and the facts of the applicant’s own experience.

A Safe Way to Use Any APEGS CBA Report Sample PDF

Official	Is the file hosted by APEGS or clearly traceable to an authoritative source?
Current	Does it agree with the latest guide, FAQ and portal fields?
Relevant	Does its discipline, role and competency context help with the issue being reviewed?
Verifiable	Can every fact in the final submission be confirmed from the applicant’s own work?

Study from samples: report architecture, field separation, the level of context used and the relationship among employment history, validators and ratings.

Keep applicant-owned: project facts, calculations, decisions, outcomes, first-person claims, confidentiality choices and self-ratings.

Strong vs Weak APEGS Evidence: The Eight-Part Test

The same diagnostic test can be applied to technical, behavioural and professional competencies. The type of detail changes by category, but the evidence chain remains consistent.

1. Alignment	Answers the competency and its interpretation.	Mentions a keyword but proves another skill.	Why does this event belong here?
2. Context	Shows authentic engineering or geoscience practice.	Could describe almost any occupation.	Where is the professional-practice context?
3. Specificity	Identifies a bounded problem, role and evidence trail.	Summarises routine duties or an entire career.	Could the event be verified?
4. Ownership	Uses accurate first-person actions and reasoning.	Relies on ‘we,’ passive wording or involvement claims.	What did the applicant personally do?
5. Judgement	Explains alternatives, constraints, standards or trade-offs.	Lists tools, codes or procedures without application.	Why was the action selected?
6. Outcome	Connects the action to a relevant result.	Ends with vague success or client satisfaction.	What changed because of the action?
7. Rating	Scope, complexity, risk and supervision support the level.	The rating exceeds the responsibility shown.	Would the facts support this level?
8. Consistency	Validator, dates, role and employment history agree.	The validator cannot confirm the action or chronology conflicts.	Can the report be independently confirmed?

1. Competency Alignment

Strong evidence: isolates the capability being assessed and follows the current APEGS interpretation statement.

Weak evidence: contains vocabulary from the competency while the underlying action proves a different skill.

Review question: Would the relationship between this event and the competency remain obvious if the competency title were hidden?

2. Engineering or Geoscience Context

Technical elements need engineering or geoscience substance. Communication, management and team examples also need a credible professional-practice setting rather than a generic workplace story. Context can come from a design decision, investigation, risk, standard, professional obligation, public impact or technically informed stakeholder decision.

3. Specificity and Verifiability

Strong evidence: defines the project stage, problem, constraint, role and records or people that can confirm the event.

Weak evidence: uses recurring-duty language such as ‘I always ensured quality’ or compresses several years into one claim.

4. Personal Action and Ownership

First-person verbs make ownership visible: I analysed, I selected, I verified, I recommended. Team context remains important, but it should lead to the applicant’s contribution. Accurate collaboration is stronger than exaggerated sole ownership.

5. Judgement and Competency-Specific Detail

Strong evidence explains why an action was taken. Depending on the element, that may require assumptions, calculations, codes, alternatives, audience needs, cost trade-offs, safety consequences, ethical duties or learning gaps. A list of software or meetings records activity, not judgement.

6. Outcome and Impact

Strong evidence: shows a technical, safety, compliance, financial, environmental, stakeholder or learning result connected to the action.

Weak evidence: states that the project succeeded or the client was happy without showing the relevant consequence.

7. Rating Support

The current APEGS Competency Assessment Guide links ratings to demonstrated competence. Scope, complexity, responsibility, risk and supervision should be visible in the example. Evidence drives the rating; a desired rating should never drive embellished evidence.

8. Validator and Employment-History Consistency

The validator should have personal knowledge of the work being confirmed. Employer, position and dates should align with the employment history, and the claimed authority should fit the applicant’s actual role. Validator feedback is independent; the applicant should not construct or influence that assessment.

Strong vs Weak Example 1: Applying Codes and Standards

Weak pattern: I followed all relevant codes and completed the design.

Why it is weak: The requirement is unnamed, the applicant’s interpretation is absent, and no design decision, check or outcome is visible.

Stronger evidence direction: Identify the applicable code, standard or regulatory constraint; explain the requirement that governed the issue; show how you interpreted it; and connect it to a calculation, review, compliance decision or safety outcome.

Review question: Can the reader see how the requirement changed the engineering work?

Naming several standards without explaining their technical effect adds terminology, not evidence.

Strong vs Weak Example 2: Analysis, Design or Risk

Weak pattern: I used engineering software to analyse the system and reduce risk.

Why it is weak: The tool replaces the reasoning, the risk is undefined, and the inputs, assumptions, checks and recommendation are missing.

Stronger evidence direction: Define the technical problem and failure mode, state the governing inputs and assumptions, explain why the selected model was suitable, describe the check performed and connect the result to your recommendation.

Review question: Would the evidence remain credible if the software name were removed?

Strong vs Weak Example 3: Communication or Stakeholder Work

Weak pattern: I communicated with the client and prepared reports.

Why it is weak: There is no audience need, technical message, communication challenge, adaptation, feedback or resulting decision.

Stronger evidence direction: Identify who needed the information, what decision they faced, how you adapted technical content to that audience, how you handled questions or disagreement and what decision or risk response followed.

Review question: Does the evidence prove effective communication in context rather than document production alone?

Strong vs Weak Example 4: Project, Financial or Team Competence

Project and Financial Management

Weak pattern: I attended schedule meetings and monitored the budget.

Why it is weak: This states recurring duties without a planning decision, variance, trade-off or corrective action.

Stronger evidence direction: Show the scope or resource constraint, the estimate or monitoring method, the variance identified, the decision within your authority and the effect on delivery. Represent budget authority honestly.

Team Effectiveness

Weak pattern: Our multidisciplinary team collaborated successfully.

Why it is weak: The applicant’s interaction and the issue requiring teamwork are invisible.

Stronger evidence direction: Identify the coordination or conflict issue, your role, the response you took and the effect on team performance. Distinguish leading, contributing and observing.

Strong vs Weak Example 5: Accountability, Sustainability or CPD

Professional Accountability

Weak pattern: I understand and follow the code of ethics.

Why it is weak: Awareness is asserted without a limitation, duty, conflict, public-interest issue or professional response.

Stronger evidence direction: Describe the real obligation or limitation, the competing consideration, the action taken and how professional responsibility or public protection was preserved.

Social, Environmental and Sustainability

Weak pattern: The project used sustainable engineering practices.

Why it is weak: The affected people, environmental consequence, lifecycle issue and decision trade-off are undefined.

Stronger evidence direction: Connect an engineering decision to a social, economic, environmental, regulatory or lifecycle effect, then identify the safeguard, mitigation or balanced recommendation.

Continuing Professional Development

Weak pattern: I completed several courses and maintained memberships.

Why it is weak: Activity is listed without showing the competence gap, application of learning or future plan.

Stronger evidence direction: Identify the learning need, the development action, how the learning changed practice and the next step in the development plan.

Why an APEGS Competency Example May Receive Zero or Be Reopened

APEGS’s current work experience reporting requirements state that a competency example receives zero when it does not clearly show engineering or geoscience context, how it addresses the competency, or sufficient specific detail to demonstrate professional work under the Act.

• The professional-practice context is missing or impossible to identify.
• The event does not demonstrate the competency being assessed.
• The information is too generic to evaluate the nature and level of the work.
• The applicant’s involvement, responsibility or decision is unclear.
• The narrative does not support the selected rating.
• Required Canadian or equivalent context is absent from the relevant evidence.
• The validator cannot confirm the claimed work from personal knowledge.
• Dates, employers, roles, examples or validators conflict across the report.
• Grammar, unexplained acronyms or unclear sequencing prevents meaningful assessment.

Two risks should be separated. An assessor can assign a low rating, including zero where the published basic tests are not met. Separately, the submission quality-check process can identify shortcomings before formal assessment and require the self-assessment and validations to be completed again. Neither outcome can be predicted from one sentence in isolation; the complete evidence and assessment process matter.

12 Common Mistakes to Avoid in APEGS Competency Examples

• Turning a job description into a competency example
• Writing mainly about the company, project or team
• Repeating competency wording instead of supplying evidence
• Naming codes, calculations or software without explaining their application
• Omitting alternatives, constraints, decisions or verification
• Using vague outcomes disconnected from the applicant’s action
• Selecting a rating beyond the scope, complexity or independence shown
• Reusing the same paragraph under several elements
• Assigning a validator who did not observe the relevant work
• Creating inconsistencies among dates, positions and claimed responsibility
• Borrowing wording from a sample or relying on outdated requirements
• Disclosing confidential details or removing so much context that the evidence cannot be assessed

Can You Use the Same Project for Multiple APEGS Examples?

Yes. One project may support several competencies when each entry isolates different evidence. Reusing project context is efficient; duplicating the narrative is not. The applicant should select a separate decision, action and outcome for each element.

Technical	A load case, calculation, code application, option comparison or design verification.
Communication	Adaptation of technical findings for a client, contractor, regulator or community decision.
Project management	A scope, schedule, cost, resource or change-control decision within the applicant’s role.
Sustainability	A lifecycle, environmental, public-impact or mitigation trade-off considered in the design.

Review principle: If the Action and Outcome remain nearly identical after the competency title changes, the evidence has probably been duplicated rather than remapped.

APEGS Competency Example Review Checklist

Competency Fit

• Does the event answer the named element and current interpretation statement?
• Is the context genuine engineering or geoscience practice?
• Is Canadian or equivalent context visible where the framework requires it?

Evidence Quality

• Is the situation bounded, concise and verifiable?
• Does the Action show personal decisions and contain the substantive detail?
• Are relevant principles, standards, risks, constraints, stakeholders or trade-offs explained?
• Does the Outcome follow logically from the applicant’s action?

Rating and Consistency

• Do scope, complexity, responsibility, risk and supervision support the rating?
• Do employer, role, dates and project details match the employment history?
• Can the selected validator confirm the work from personal knowledge?

Integrity and Confidentiality

• Is every claim accurate, applicant-authored and defensible?
• Has borrowed sample wording been removed?
• Are surrogate names used consistently without stripping essential evidence?

Submission Readiness

• Do Situation, Action and Outcome fit the current 300, 1,200 and 300 character limits?
• Is the language grammatical, direct and free of unexplained acronyms?
• Do the current guide, FAQ and live system still agree with the report?
• Has the full submission been checked for repetition and contradiction?

When Professional APEGS Competency Report Review Can Help

Professional review is most useful after authentic first-person drafts exist. A reviewer can test competency mapping, identify missing evidence, examine rating support, improve clarity, check validator coverage and flag confidentiality or chronology problems across the complete report.

Appropriate review support: diagnosis, structural feedback, clarity editing, consistency checks, evidence-gap analysis, validator mapping and applicant-approved revisions.

Ethical boundary: project facts, decisions, metrics, professional judgement and final confirmation remain with the applicant; no review can promise a particular rating or assessment result.

Final Takeaway

APEGS competency assessment examples are most valuable when they sharpen evaluation, not when they replace personal evidence. A strong example makes the competency fit, professional context, first-person action, judgement, outcome, rating support and validator knowledge easy to trace. Applying the same eight-part test across the full report exposes weak claims, repeated stories and consistency gaps before validation.

For an independent review of applicant-authored evidence, explore our APEGS competency report review and writing support.

Frequently Asked Questions

1. What is an example of strong APEGS competency evidence?

Strong evidence presents one verifiable event, directly answers the competency, shows the applicant’s personal judgement and action, provides relevant detail, states a credible outcome, supports the self-rating and can be confirmed by a validator.

2. Can I download an official APEGS competency report sample PDF?

Yes. APEGS publishes an applicant-view sample PDF that shows the report’s structure, employment history, competency fields, self-ratings and validator information.

3. Can I copy or paraphrase an APEGS sample report?

No. The final report must describe the applicant’s own accurate and validator-verifiable experience; borrowed wording can misrepresent ownership, context and competence.

4. Why would an APEGS competency example receive a zero?

APEGS identifies three basic failures: missing engineering or geoscience context, failure to address the competency, or insufficient specific detail to demonstrate professional work under the Act.

5. Should APEGS examples use I or we?

Use ‘I’ for the applicant’s actions and reasoning while using ‘we’ only where accurate team context is necessary.

6. Can I use the same project for more than one competency?

Yes. Each entry must isolate different competency-specific actions and outcomes rather than repeat the same paragraph.

7. How technical should an APEGS example be?

It should contain enough technical or professional detail to reveal the judgement relevant to that element while remaining concise, accurate and non-confidential.

8. What happens if APEGS finds insufficient information?

The evidence may receive a low assessment, including zero under the published basic tests, or the quality-check process may require parts of the self-assessment and validation to be completed again.

9. Can a validator help write my competency examples?

A validator may confirm facts and independently evaluate work personally known to them, but the applicant is responsible for recording and submitting the evidence.