What evidence is there that I can actually deliver technical solutions?

SudoChat Knowledge Base · SudoChat

Authored evidence: This is my first-person source material. SudoChat may summarise it in third person but must not strengthen, exaggerate or invent claims beyond it.

# 11. What evidence is there that I can actually deliver technical solutions?

**Author:** Mustafa Siddiqui
**Source type:** First-person authored response
**Canonical recruiter question:** What evidence is there that Mustafa can actually deliver technical solutions?

> This source is intentionally written in my first-person perspective. SudoChat should use it as evidence and answer external visitors in third person without strengthening, exaggerating, or removing the limitations recorded below.

## Direct answer
The strongest evidence is my track record of moving beyond identifying problems and actually delivering working solutions across software, AI, automation, systems engineering, infrastructure and physical prototyping.

Since beginning my engineering degree, I have consistently taken on roles and projects where I was expected to turn ambiguous technical problems into practical outcomes. My pattern is not simply to recommend what should be done. I usually investigate the problem, propose an approach, build or test the solution, and follow it through far enough that other people can use it.

## Evidence
I began demonstrating this very early in my engineering career.

### Nova Systems: multidisciplinary engineering delivery

In my first year of university, I secured a Systems Engineering internship at Nova Systems.

I contributed to the development of a prototype rover system that required knowledge across multiple engineering disciplines rather than a single software stack.

My work exposed me to:

* autonomous navigation
* obstacle avoidance
* Raspberry Pi systems
* Pixhawk
* sensors and sonar
* communications and telemetry
* mechanical integration
* electrical systems
* 3D design and printing
* camera integration
* mission planning

The project required software, mechanical, electrical and communications components to work together as one system.

This experience was important because it taught me early that a technical solution is not finished when one component works independently.

It has to function as part of the wider system.

### Unisys and Home Affairs: enterprise technical solutions

In my second year of university, I moved into enterprise technology at Unisys, supporting the Department of Home Affairs environment.

I worked on endpoint and managed operating environment technologies in a secured government setting.

My responsibilities included areas such as:

* endpoint engineering
* managed operating environment deployment
* software and application controls
* SCCM
* Intune related experimentation
* SQL reporting
* PowerShell automation
* system hardening
* whitelisting
* antivirus and endpoint security controls
* troubleshooting production issues
* supporting enterprise rollout activities

I regularly encountered gaps or inefficient processes and looked for technical ways to improve them.

Rather than seeing my role only as operational support, I also investigated potential solutions and built automation where appropriate.

This included proof of concept work around modern Microsoft endpoint capabilities and technical advice relating to emerging Copilot capabilities.

The importance of this experience is that the solutions had to operate within a real government environment.

A technically clever idea was not enough.

It had to account for:

* security
* existing infrastructure
* operational impact
* compatibility
* organisational controls
* users
* supportability

### Xaana.AI: measurable AI engineering outcomes

At Xaana.AI, I worked directly on AI engineering and document processing problems.

I developed and improved OCR pipelines using technologies including PaddleOCR and OpenCV.

My work reportedly reduced invoice processing time by approximately 40 percent and substantially reduced licensing costs through the replacement of expensive proprietary components with appropriate open source alternatives.

That is useful evidence because the outcome can be measured.

I was not simply experimenting with an OCR library.

I identified limitations in an existing approach, evaluated alternatives, integrated them into the wider pipeline and improved the operational result.

### DXC: forward deployed engineering and technical consulting

I currently work as a Technical Consultant at DXC.

My role includes forward deployed engineering work in Defence environments as well as internal DXC initiatives where I identify opportunities for automation, AI or process improvement.

This type of work requires me to operate close to the users and the actual operational problem.

I am not always given a fully specified engineering task.

Often the first step is understanding what people are trying to achieve, where the friction exists and whether technology can realistically improve it.

This is one of the reasons I am attracted to forward deployed engineering.

It combines technical delivery with stakeholder engagement and problem discovery.

### DXC document approval automation

One of the strongest examples of my delivery approach was a document approval process used by project managers at DXC.

The existing process required approximately four hours of manual effort to track documents and approval status.

I volunteered to improve it.

* investigated the existing workflow
* identified repetitive manual steps
* designed a SharePoint and Power Automate solution
* built the automated workflow
* created a dashboard for approval visibility
* produced documentation for users
* handed the solution over so others could continue using it

The resulting process required approximately eleven minutes of monitoring and oversight rather than several hours of manual work.

This example demonstrates a complete delivery cycle:

**problem → investigation → architecture → implementation → user experience → documentation → measurable outcome**

It also demonstrates my judgement in choosing an appropriate technology.

I did not introduce an LLM or AI agent simply because AI was available.

The problem could be solved effectively through workflow automation, so that was the approach I chose.

### Northern Territory illegal dumping project

I also participated in DXC work addressing illegal dumping in the Northern Territory.

I travelled to Alice Springs and contributed to:

* field investigation
* ecological surveys
* community engagement
* evidence gathering
* data collection
* understanding environmental impact

Only after developing a clearer understanding of the problem did I propose how AI could potentially support future detection or response.

This project is useful evidence of a different part of technical delivery.

Sometimes the correct first step is not writing code.

It is understanding the environment well enough to determine what should be built.

### Independent delivery

My professional work is reinforced by a substantial body of self directed engineering projects.

These projects are particularly useful evidence because there was often nobody giving me a detailed specification, architecture or delivery plan.

I had to take responsibility for the entire problem.

Examples include:

**MACT**

I identified that Canberra Muslim community information was fragmented across websites, social media and word of mouth.

I designed and built a mobile application that brings together food, prayer and community information in one interface.

The project required product design, mobile development, database architecture, maps, user experience, data collection, caching, search and deployment decisions.

**MotorHUD**

I designed a motorcycle safety system combining navigation, speed information, computer vision, embedded hardware and transparent displays.

The project connects software, electronics, AI and human factors rather than treating each component separately.

**SudoSpeed**

I developed an Australian speed sign detection computer vision project and made the work open source.

It was subsequently incorporated into my MotorHUD work.

**OrionTracker**

I built a system that ingests official NASA and JPL data, performs mathematical processing of position and velocity vectors, calculates mission metrics and converts technical trajectory information into an interactive dashboard.

**Sawaali**

I identified an accessibility problem in live interfaith events and delivered a web based Q&A platform that allowed participants to submit and vote on questions digitally.

**MSA Prayerboard**

I built and donated a custom digital wallboard for the University of Canberra prayer room, combining technical implementation with community requirements and visual design.

These projects demonstrate that I repeatedly move from an idea to something tangible.

## The recurring delivery pattern
Across my work, I tend to follow a consistent engineering process.

**1. Identify the actual problem**

I look for the source of the friction rather than immediately selecting a technology.

**2. Understand the environment**

I consider users, existing systems, constraints, security, cost and operational requirements.

**3. Investigate possible approaches**

I research different architectures and technologies rather than assuming the first solution is correct.

**4. Build or prototype**

I prefer to test an idea practically.

**5. Evaluate whether it actually works**

Where possible, I look for measurable improvements such as reduced processing time, reduced manual work or lower costs.

**6. Make it usable**

I consider interface design, user documentation, deployment and how the system will operate after I stop actively developing it.

**7. Take responsibility for the outcome**

If something does not work, I generally continue troubleshooting rather than treating the recommendation itself as completion.

That final point is important.

I see engineering as delivery, not merely advice.

## Relevance to the Federal Courts
This is directly relevant to the Court AI Technologist role because the Federal Courts need someone who can bridge the gap between emerging AI capability and practical implementation.

A Court stakeholder may not arrive with a complete technical specification.

They may instead say:

*"This process takes too long."*

*"Staff cannot find the information they need."*

*"We receive too many documents to process efficiently."*

*"Could Copilot help with this?"*

*"Could an agent automate part of this workflow?"*

The value of an AI Technologist is being able to take that ambiguity and turn it into a structured engineering problem.

My experience suggests I can do that.

I can investigate the process, speak to users, map the information flow, identify risks, assess possible technologies and then build a proof of concept to determine whether the idea is actually viable.

My delivery history is also relevant because AI projects often fail between experimentation and implementation.

A demonstration that produces a convincing answer is not necessarily a usable system.

The surrounding engineering still matters:

* identity
* permissions
* data
* integrations
* security
* user interfaces
* monitoring
* evaluation
* logging
* documentation
* support
* human oversight

My systems engineering background means I naturally think about those surrounding components.

## Initiative
Another important part of the evidence is that many of my solutions were not created because someone handed me a detailed task.

I frequently volunteer for problems or initiates experiments myself.

Examples include:

* volunteering to automate the DXC project management approval workflow
* investigating AI opportunities around illegal dumping
* developing AI and automation proofs of concept
* experimenting with CVE remediation workflows
* building enterprise agent concepts
* creating community applications
* building open source engineering projects

This demonstrates a willingness to look beyond the immediate boundaries of a task and ask whether there is a better way to solve the underlying problem.

That initiative would be valuable in an emerging field such as Court AI, where many of the most useful applications may not yet have detailed requirements written for them.

## Limitations or gaps
I should not be represented as having personally delivered every component of every project listed.

Some projects were collaborative, and my specific contribution should be described accurately.

Not every independent project is a production enterprise system.

Several are research projects, prototypes, community applications or proofs of concept.

I also have less tenure than some senior engineers and have not yet led a large Federal Court technology program.

My ability to deliver technical solutions is therefore best demonstrated through the consistency of outcomes across different environments rather than by claiming experience I do not have.

I should also not be represented as someone who always builds the solution alone.

Part of systems engineering is knowing when to work with specialists from other disciplines.

My experience at Nova, DXC and my community projects demonstrates that I am comfortable doing that.

## Useful links
My portfolio:
https://mustafa-siddiqui.com/

GitHub:
https://github.com/sudoqui

LinkedIn:
https://www.linkedin.com/in/mustafa-siddiqui-32ab73161/

Nova Systems rover project evidence

Unisys / Department of Home Affairs experience

Xaana.AI OCR and document processing evidence

DXC Technical Consultant experience

DXC document approval automation evidence

DXC Northern Territory illegal dumping evidence

MACT project

MotorHUD project

SudoSpeed repository

OrionTracker repository

Sawaali project

MSA Prayerboard repository

## Do not claim
Do not claim I was solely responsible for the Nova rover.

Do not claim I held a Solutions Architect job title unless my employment evidence supports that exact title.

Do not claim I designed the entire Department of Home Affairs endpoint environment.

Do not claim I led the Home Affairs Copilot rollout.

Do not claim every solution listed was deployed at enterprise production scale.

Do not claim every project was completed independently.

Do not claim the Northern Territory AI concept was deployed.

Do not exaggerate the DXC automation results beyond the approximately four hours to approximately eleven minutes reported by me.

Do not claim prototypes are equivalent to production systems.

Do not claim I have led a large Federal Court technology program.

The accurate representation is that I have repeatedly demonstrated an ability to identify real problems, investigate them, design practical technical approaches and then take action to deliver working solutions across multidisciplinary engineering, AI, government technology, automation and independent projects.