A person does not need the job title “Architect” to encounter architecture. Developers make service-boundary choices. Business analysts model system interactions. DevOps engineers design deployment topology. Database specialists make decisions about resilience, recovery and access. The RPL question is not whether architecture vocabulary is allowed. It is whether the decisions described were genuinely part of the applicant’s work. When describing architecture in an ACS RPL project report, explain a decision you personally made—such as a trade-off between resilience and cost—and the evidence that shows its effect on the project.
ACS requires two RPL project reports to demonstrate ICT knowledge acquired through professional experience. One report must cover a project completed within the last two years and the other a project within the last four years. ACS also states that the reports must be exclusively the applicant’s own work and must not be outsourced to a writing or editing agency.
Once the projects are chosen, the next task is showing technical depth without technical theatre while keeping each report focused on a concrete project episode rather than repeating a job description.
Architecture is context until it becomes your decision
A project can have an architecture that matters to your work even when another person owns the final design. The safest way to describe it is to separate the architecture around you from the architectural decisions you personally made or influenced.
| Your real role | Defensible focus | What to avoid |
|---|---|---|
| Decision owner | Constraints, alternatives, trade-offs and the decision you made. | Claiming organisation-wide authority you did not have. |
| Analyst / recommender | What you analysed, modelled, compared or recommended and how it affected the design. | Writing as though your recommendation was automatically the final architecture. |
| Implementer | How you interpreted, configured, integrated or tested an architecture chosen by others. | Turning implementation into design ownership. |
| Workshop participant | Your specific contribution, questions, validation or documentation. | Using “we designed” when your individual contribution is not visible. |
Trade-offs reveal more knowledge than buzzwords
A paragraph that says a solution used microservices, Kubernetes, zero trust and event-driven architecture may sound technical without demonstrating any personal knowledge. A stronger explanation identifies a real constraint and a decision boundary: latency versus consistency, managed service versus operational control, centralisation versus autonomy, resilience versus cost, or security control versus user friction.
The point is not to include every trade-off. It is to make the technical reasoning visible where it genuinely occurred.
Examples of legitimate non-architect contribution
- A business analyst maps current interfaces, identifies integration constraints and recommends a phased API migration while the solution architect owns the target architecture.
- A developer evaluates two persistence patterns for one service and implements the selected approach without claiming to have designed the enterprise platform.
- A DevOps engineer designs environment separation, deployment automation and rollback behaviour inside an architecture whose application boundaries were defined by another team.
- A database administrator recommends replication and recovery settings within a wider system design owned by an infrastructure architect.
Keep the project report aligned with employment evidence
Architecture claims should make sense for the role held at the time. If a promotion later gave the applicant design authority, do not backdate that authority into an earlier project phase. If an employer reference describes implementation work only, an RPL report suddenly claiming enterprise architecture ownership creates a credibility gap that should be resolved before submission.
A responsibility-boundary check
- Who had formal responsibility for the architecture or design decision?
- What information or constraints did you personally analyse?
- What did you personally recommend, decide, configure, code, test or validate?
- Which result can you attribute to your work without taking credit for the team?
- Could you defend every strong verb in the report against your employment history and available evidence?
Do not turn guidance into ghostwriting
ACS’s authorship rule is unusually important here because architecture language is easy to inflate. Professional support can explain requirements, help an applicant identify evidence gaps and challenge unsupported claims. The substantive project narrative, technical decisions and wording that represents the applicant’s experience must remain the applicant’s own work.
The right amount is the amount you can defend
If you owned architecture, discuss the decisions in depth. If you influenced the design, explain the analysis and recommendation. If you implemented someone else’s architecture, go deep on the implementation problems you actually solved. Technical depth does not require borrowed seniority.
Treat this as evidence-quality guidance, not a project-report template. If you are still deciding whether the ACS RPL pathway is actually the right route, resolve that first. Applicants who proceed should use the current ACS RPL form and write their own project reports.
Architecture belongs in the report only where your judgment mattered
A software developer contributing to an enterprise platform may understand the wider architecture without having designed the whole system. That difference should remain visible in an ACS RPL narrative. Describe the constraints you personally evaluated, the components you owned, and the consequences of your decisions. For example, choosing idempotent message handling and explaining failure recovery is strong evidence of applied knowledge. Claiming to have set the organization’s microservices strategy when the architect supplied the design is not. Review the current ACS RPL project-report criteria before determining the depth and scope of the discussion.
Use trade-offs to reveal applied knowledge
A credible project report does not need a fashionable technology stack. It should explain why a certain design was appropriate in its operating context. If a batch process used a relational database, discuss transaction requirements, data integrity and operational limits. If a cloud service was selected, identify who made the decision, which options were considered and what your implementation contributed. Technical details are persuasive when attached to decisions: performance targets, failure modes, access controls, testing methods and release constraints. Abstract statements that the system was ‘scalable, secure and robust’ tell an assessor very little about the applicant’s contribution.
How to draw the ownership boundary
Imagine a backend engineer who wrote integration logic within a solution designed by a lead architect. The report could legitimately describe the data contract, error handling, observability and tests built by the engineer. It might reference the wider architecture for context without claiming authorship. If the project involved a team, mention the interfaces between roles and the escalation process. The report is not weakened by a truthful description of collaboration. On the contrary, showing precisely where your judgment started and ended makes the technical narrative more defensible. The ACS rules also emphasize that submitted project reports must be the applicant’s own work.
Match technical claims to historical evidence
A project report describing extensive cloud architecture should not conflict with an employment reference stating that the applicant worked solely on first-line support during the same period. Reconcile any difference using dates, internal transfers or project assignments, but never retrofit an employer letter to the story after the fact. Technical evidence may include sanitized diagrams, issue histories or deployment notes where confidentiality obligations allow. Remove client secrets and personally identifiable information; a persuasive assessment does not require exposure of production credentials. The goal is an authentic account that a knowledgeable supervisor could recognize and that the applicant can explain unaided.
RPL applicants should begin with RPL assessment pathway rather than general writing advice. The ACS assessment information hub hub identifies the authority’s current requirements, IT professional knowledge framework sets out the project-report framework, and acceptable employment documentation explains why work-history claims require separately reliable references.