How to Write APEGS Competency Examples Using the STAR Method and First-Person Evidence

An APEGS competency example must turn one real work event into assessable evidence within three fields: Situation, Action and Outcome. Situation frames the engineering or geoscience problem, Action proves what you personally analysed, decided and did, and Outcome shows the effect. The live system allows 300 characters for Situation, 1,200 for Action and 300 for Outcome, so every sentence must perform a clear evidentiary job.

The STAR method remains useful at the planning stage, but it should not control the final portal entry. APEGS does not provide a separate Task field. The task belongs in the end of the Situation or the opening of the Action, while STAR’s Result becomes the APEGS Outcome. This distinction prevents a common drafting failure: spending too much space on project background and too little on the applicant’s own engineering judgement.

This guide provides a repeatable writing process, first-person techniques, character-budget guidance and an ethical review standard so applicants can present genuine project facts clearly, accurately and in a form their selected validators can verify.

Quick Answer: How Do You Write an APEGS Competency Example?

Choose one specific, recent and verifiable work event that directly demonstrates the competency. State the problem briefly, explain your personal engineering or geoscience decisions in the Action field, and close with the result or professional consequence. Use STAR to organise the raw facts, then convert them into APEGS’s three-field format.

1. Read the competency, indicators and APEGS interpretation statement before selecting a project.
2. Identify one event with enough technical context, personal responsibility and a validator who observed the work.
3. Draft the Action first because it carries the largest character allowance and most of the assessment value.
4. Add a concise Situation that establishes the problem and your responsibility without retelling the project history.
5. Finish with a specific Outcome, then remove unsupported claims, generic team language and repeated background.

STAR Method vs the APEGS Situation-Action-Outcome Format

STAR is a memory and planning tool. APEGS’s assessment interface is the submission structure. The strongest approach uses STAR to collect the facts and SAO to present them efficiently.

Situation	Situation – 300 characters	Identify the project context, specific problem and relevant constraint.
Task	End of Situation or start of Action	Clarify your assigned responsibility or the decision you had to make.
Action	Action – 1,200 characters	Show your analysis, judgement, decisions, communication, controls and implementation.
Result	Outcome – 300 characters	State the effect, verification result, learning or professional consequence.

Use STAR for: brainstorming the event, separating your responsibility from the wider project, and locating an outcome before drafting.

Avoid: copying four STAR headings into the portal, inventing a separate Task narrative, or treating the structure as a substitute for technical evidence.

Before Writing: Build an Evidence Map

The quality of an example is usually decided before the first sentence. A polished paragraph cannot rescue a weak match between the work event and the competency. Start by mapping each requirement to evidence that is both relevant and verifiable.

1. Read the Competency and Its Interpretation Statement

A competency title is broad. The indicators and APEGS interpretation statement narrow the evidence expected. Under application of theory, for example, naming a discipline is not enough; the example should reveal the theory, calculation, model or engineering principle used and how it affected the decision.

Evidence direction: Underline the capability, context and level implied by the requirement, then write a one-sentence test for the example.

Avoid: choosing a project because it sounds impressive when the applicant’s role does not prove the competency.

2. Create a Project Inventory

List projects from the employment history and record the problem, technical discipline, decisions made, tools or codes used, outcome, dates and possible validator. A single project may support more than one competency when different evidence is isolated for each, but repeated entries should not recycle the same paragraph.

Problem	The specific technical, operational, safety, communication or management issue.
Personal contribution	Calculations, alternatives, decisions, recommendations, reviews or controls completed by you.
Evidence detail	Codes, equations, software, data, constraints, risks and verification methods.
Outcome	Measured performance, approval, risk reduction, cost or schedule effect, learning or implemented change.
Validator	A person with direct knowledge who can confirm the example and the role described.

3. Select the Strongest Verifiable Event

Prefer an event where your involvement is clear, the engineering or geoscience context is visible and the result can be confirmed. Recent work is often easier to describe accurately, but relevance and proof matter more than novelty. The chosen validator should have firsthand knowledge of the work and enough context to judge the claimed competence.

Strong selection: one bounded event with a clear decision point, personal responsibility and a confirmable outcome.

Weak selection: a broad multi-year project summary in which the applicant’s individual work cannot be separated from the team’s work.

How to Write the Situation in 300 Characters

The Situation should orient the assessor, not narrate the full project. Identify the asset, system or deliverable; the specific problem or constraint; and, where necessary, your responsibility. Project value, client history and team size belong only when they change the technical meaning of the example.

Include: the engineering context, the triggering problem, one material constraint and the decision or responsibility assigned to you.

Avoid: generic openings such as ‘I worked on a large project’ or background that consumes space without establishing the competency.

A useful internal test is: could a technically informed reader understand what had to be resolved and why it mattered? If yes, stop. The Action field should carry the explanation of how you resolved it.

How to Write the Action in 1,200 Characters

The Action is the evidentiary core. It should show a sequence of professional reasoning rather than a list of duties. Explain what information you examined, what alternatives or risks you considered, why you selected an approach, what you personally produced or communicated, and how you checked the work.

Use First-Person Evidence

Assessors need to distinguish the applicant’s competence from the team’s output. Use ‘I’ for your contribution and reserve ‘we’ for context that genuinely belongs to the team. First-person writing is not self-promotion; it is attribution.

We reviewed the design.	I checked the governing load cases, identified the controlling case and documented the required revision.
The team selected the option.	I compared three options against capacity, constructability and maintenance criteria, then recommended the preferred option.
Calculations were completed.	I developed the calculation model, tested the assumptions and independently checked the critical output.
The issue was resolved.	I traced the discrepancy to the input data, corrected the dataset and verified the revised result against field measurements.

Useful action verbs: analysed, calculated, compared, designed, checked, challenged, selected, recommended, coordinated, verified, documented and implemented.

Avoid: passive constructions that conceal ownership, or repeatedly replacing ‘we’ with ‘I’ without adding the actual reasoning and action.

Show Judgement, Not Just Activity

Competence is demonstrated by the reason behind the action. A sentence such as ‘I used finite-element software’ identifies a tool; it does not establish what was modelled, which assumptions governed, how the results were checked or why the output supported a decision.

Evidence direction: connect the input, method, comparison or risk to a decision and a verification step.

Avoid: listing software, codes, meetings or documents as if their presence automatically proves competence.

Match the Action to the Competency Category

Technical competence	Theory, calculations, codes, constraints, options, assumptions, risk, checks and technical documentation.
Communication	Audience, purpose, information translated, medium used, feedback addressed and decision enabled.
Project and financial management	Scope, estimate, schedule, change, resources, trade-offs, controls and monitored variance.
Team effectiveness	Your role, coordination, conflict or contribution issue, intervention and team outcome.
Professional accountability	Ethical duty, limits of competence, quality control, public safety, professional obligations and escalation.
Social, environmental and sustainability	Stakeholder effects, lifecycle considerations, mitigation, public consequences and balanced decisions.
Continuing professional development	Gap identified, learning action, application to practice and improvement achieved.

How to Write the Outcome in 300 Characters

The Outcome closes the evidence chain. State what changed because of the action and, where possible, how the result was verified. A strong outcome may report improved performance, an approved design, a controlled risk, avoided rework, a decision reached, an implemented procedure or a lesson applied to later practice.

Quantify when supported: use a percentage, capacity, tolerance, cost, time, error reduction or other measure that exists in the project record.

Avoid: inventing precision, claiming team-wide results as personal achievements, or ending with ‘the project was successful’ without a relevant consequence.

Demonstrate Competency Level Through Facts

Do not write the self-rating into the story or use adjectives such as ‘complex’ and ‘independent’ as proof. Let the facts show level: the scope of responsibility, technical difficulty, uncertainty, consequences, supervision received, alternatives evaluated and judgement exercised.

The problem was complex.	Multiple interacting constraints, uncertain inputs, competing options and material consequences are identified.
I worked independently.	The example explains the decision authority held, checks performed and points at which review or approval occurred.
I reduced risk.	The hazard, likelihood or consequence, selected control and post-control condition are described.
I communicated effectively.	The audience, misunderstanding or decision need, communication method and resulting action are shown.

Use Technical Specificity Without Overloading the Example

Specificity makes evidence credible, but detail should serve the competency. Include the governing code clause, calculation method, software model, design criterion, data source or measured result when it explains the judgement. Remove facts that merely demonstrate familiarity with project terminology.

For codes and standards: name the applicable requirement and explain how it changed the design, review or decision.

For calculations and software: state the method, critical assumptions, interpretation and independent check rather than presenting the tool as the action.

For metrics: use only figures that are accurate, permitted for disclosure and relevant to the outcome.

Protect Confidential Information Without Making the Evidence Generic

Confidentiality does not require an empty description. Replace client, site or proprietary identifiers with consistent surrogate names such as Project X, Facility A or City Q. Retain the permitted engineering context: the type of asset, nature of the problem, decision process and non-sensitive outcome. If a detail cannot be disclosed, state that limitation plainly and provide enough surrounding evidence for the validator and assessor to understand the work.

For APEGS work experience reporting, this approach protects proprietary information without weakening assessability. The selected validator must still be able to confirm the underlying work.

Can the Same Project Be Used for More Than One Competency?

Yes. A substantial project can contain different evidence for technical analysis, risk, communication, project control and professional accountability. Reuse the project only when each entry isolates a distinct competency-relevant action. The repeated context may be brief, but the reasoning and outcome should not be duplicated.

Acceptable reuse: one entry focuses on the load analysis, another on the design risk control, and another on communication of the change to construction personnel.

Avoid: submitting the same story under several competencies with only the opening or closing sentence changed.

A 10-Step APEGS Competency Writing Workflow

6. Read the competency, indicators and interpretation statement.
7. Choose one specific event and confirm that it belongs to your employment history.
8. Identify a validator with direct knowledge of the event.
9. Record the raw facts using Situation, Task, Action and Result notes.
10. Draft the Action first, concentrating on personal reasoning, decisions and checks.
11. Write the Situation around the exact problem and your responsibility.
12. Write the Outcome around the verified effect or professional consequence.
13. Test the example against the competency instead of against the project generally.
14. Edit to the portal character limits without removing the evidence chain.
15. Complete an ethical, confidentiality and validator-readiness review before submission.

Final Review Checklist

• The example describes genuine engineering or geoscience work and directly addresses the competency.
• Situation, Action and Outcome fit the portal limits of 300, 1,200 and 300 characters.
• The Action uses first-person language and separates personal contribution from team activity.
• The reasoning includes enough technical or professional detail to be assessed.
• The claimed outcome is accurate, relevant and supported by the project record.
• The example does not rely on software, codes, job titles or self-rating adjectives as proof.
• Confidential information is protected without removing essential context.
• The validator had direct knowledge and can confirm the role, action and result.
• The example is distinct from entries used for other competencies.
• Every statement can be defended in an assessment review or professional-practice inquiry.

Ethical Use of Writing Support

Editing support may improve organisation, clarity and alignment, but it must not create experience the applicant did not have or replace professional judgement with a generic model answer. The applicant remains responsible for every technical statement, self-rating and validator assignment. Validators should receive an accurate account of the work they observed, not a polished narrative that changes the facts.

Our review process keeps that boundary explicit. We can identify missing context, weak attribution, repeated evidence and character-limit problems; the applicant supplies and approves the project facts. No responsible reviewer can guarantee an assessment result because APEGS and its assessors determine whether the submitted evidence meets the required standard.

Frequently Asked Questions

1. What structure does APEGS use for competency examples?

APEGS uses Situation, Action and Outcome. STAR is useful for planning, but the Task is integrated into the Situation or Action rather than submitted in a separate field.

2. What are the APEGS character limits?

The current limits are 300 characters for Situation, 1,200 for Action and 300 for Outcome. These are character limits, not suggested word counts.

3. Should APEGS examples be written in first person?

Yes. First-person language makes the applicant’s own analysis, decisions and actions distinguishable from the team’s work. Use ‘we’ only where team context is necessary, then state what you personally did.

4. How long should the Action section be?

There is no mandatory minimum. It should contain enough specific detail to prove the competency while remaining within 1,200 characters. Use the space for reasoning, decisions, implementation and verification rather than background.

5. Can I use bullet points in an APEGS competency example?

Concise point-form drafting can help control characters if the system accepts the formatting, but the evidence must still read as a logical sequence and clearly connect the problem, personal action and outcome.

6. Can I use the same project for several competencies?

Yes, when the project contains different evidence for each competency. Each entry should focus on a distinct action and outcome rather than repeating the same narrative with minor wording changes.

7. What if my work is confidential?

Use surrogate identifiers and omit prohibited proprietary details while retaining the engineering context, decision process and permitted outcome. The validator must still be able to verify the underlying work.

8. Do I need a measurable result in every Outcome?

Use a metric when an accurate and relevant one exists. Other valid outcomes can include an approval, controlled risk, accepted recommendation, resolved discrepancy, improved process or learning applied to later practice.

9. Can AI write my APEGS competency examples?

AI may assist with organisation or editing, but it cannot supply experience, judgement or unverifiable facts. The applicant must own, check and be able to defend every statement, and the validator must be able to confirm it.

10. What causes an APEGS competency example to receive a zero?

An example is at risk when it lacks engineering or geoscience context, does not address the competency, or provides too little specific detail for assessment. Generic duties and unverified claims create the same practical weakness.