What experience do I have working in government or enterprise environments?

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.

# 12. What experience do I have working in government or enterprise environments?

**Author:** Mustafa Siddiqui
**Source type:** First-person authored response
**Canonical recruiter question:** What experience does Mustafa have working in government or enterprise environments?

> 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
I have worked across a broad range of Australian government and enterprise environments through roles at Unisys, Nova Systems, Xaana.AI and DXC.

My experience includes work supporting or contributing to environments associated with the Department of Home Affairs, ASD, DFAT, the Australian Space Agency, Canberra Hospital, Services Australia and the Department of Defence. Across these environments, I have worked on engineering, enterprise IT, endpoint management, security, AI, automation and systems integration.

The important point is not simply that I have been exposed to government organisations. I have worked in environments where security, operational reliability, approvals, identity, access, change control and stakeholder impact all matter.

## Evidence
### Department of Home Affairs through Unisys

At Unisys, I supported a government endpoint environment associated with the Department of Home Affairs.

My work included areas such as:

* managed operating environment deployment
* endpoint engineering
* SCCM
* application and endpoint controls
* SQL reporting
* PowerShell automation
* system hardening
* whitelisting
* antivirus and endpoint security
* troubleshooting
* rollout support
* experimentation with newer Microsoft capabilities

I also contributed technical advice around early Microsoft Copilot testing and worked on proof of concept activity involving Intune and existing SCCM managed clients.

This environment gave me practical experience with the reality of introducing new technology into an established government environment.

A solution had to fit existing controls, infrastructure and operational requirements.

### ASD through Unisys

I also participated in work associated with ASD environments through Unisys.

This contributed to my understanding of working in high assurance environments where security, access control, technical discipline and operational risk are especially important.

My experience in these environments reinforced that engineering decisions cannot be separated from security and governance.

I should not be represented as having authority over ASD systems or as independently designing ASD security architecture.

### DFAT through Unisys

I also participated in projects supporting DFAT environments.

My work in this context formed part of my broader enterprise IT experience, where systems needed to be supportable, secure and appropriate for government users.

This added to my exposure to different departmental operating environments rather than limiting my experience to a single government customer.

### Canberra Hospital through Unisys

I contributed to work at Canberra Hospital involving multifactor authentication.

The project included supporting an authentication approach where nurses could use badge based interactions as part of accessing systems.

This exposed me to a very different kind of user environment.

In a hospital, security controls have to coexist with usability and speed.

A technically secure authentication process that significantly slows clinical staff or interferes with their workflow can itself become an operational problem.

This experience reinforced my belief that enterprise security needs to be designed around real users rather than considered only from a technical perspective.

### Australian Space Agency through Nova Systems

During my Systems Engineering internship at Nova Systems, I was exposed to work associated with the Australian Space Agency.

My Nova experience included multidisciplinary engineering involving robotics, sensors, embedded systems, communications, telemetry, mechanical integration and autonomous navigation.

This environment strengthened my systems engineering mindset and my ability to think across software, hardware, communications and operational requirements rather than treating systems as isolated technical components.

### Services Australia through Xaana.AI

At Xaana.AI, I contributed to AI and automation work in contexts associated with Services Australia.

My broader work at Xaana included AI engineering, OCR, document processing and automation.

This exposed me to the challenges of applying AI and document intelligence in environments where information handling, reliability and trust are important.

I should not be represented as having designed Services Australia's AI strategy or as having unrestricted access to Services Australia systems.

### Department of Defence through DXC

I currently work as a Technical Consultant at DXC and have undertaken forward deployed engineering work in Defence environments.

This requires me to operate in a context where security, stakeholder requirements, existing infrastructure and operational consequences all need to be taken seriously.

My work at DXC also includes internal consulting and automation initiatives, where I look for opportunities to improve workflows through conventional automation or AI where appropriate.

This combination is useful because it gives me experience both inside controlled client environments and in identifying opportunities for technical improvement.

## Breadth of government and enterprise exposure
My experience spans environments with very different requirements.

**National security and Defence**

ASD and Department of Defence related work exposed me to environments where security and controlled access are fundamental.

**Border and government administration**

Home Affairs exposed me to large scale enterprise endpoint management, secured infrastructure and government technology operations.

**Foreign affairs**

DFAT related work gave me further exposure to government enterprise environments with distinct operational requirements.

**Healthcare**

Canberra Hospital demonstrated the importance of balancing security with usability in environments where staff need fast and reliable access to systems.

**Space and engineering**

Nova Systems and Australian Space Agency related work strengthened my multidisciplinary systems engineering experience.

**Citizen services**

Services Australia related work exposed me to AI and document processing in a context where information may ultimately affect large scale public services.

**Defence consulting**

DXC has given me experience working as a technical consultant and forward deployed engineer in secured enterprise environments.

## Relevance to the Federal Courts
This experience is directly relevant to the Court AI Technologist role because the Federal Courts are also a high trust government environment.

An AI solution inside the Courts cannot be evaluated purely on whether it works technically.

I already understand that enterprise technology has to fit into a wider environment involving:

* identity
* authentication
* permissions
* security controls
* network boundaries
* endpoint management
* information handling
* deployment processes
* change management
* user needs
* operational support
* auditability
* governance
* existing infrastructure

My government experience also means I am familiar with the fact that introducing new technology can require compromise.

The newest or most technically impressive solution may not always be the most appropriate one.

Sometimes the correct solution must integrate with older systems.

Sometimes cloud capabilities may be restricted.

Sometimes data cannot leave a particular environment.

Sometimes security requirements change the architecture.

Sometimes a workflow must remain partially manual because the consequence of automation is too high.

I have worked in environments where those constraints are normal rather than exceptional.

That is important for Court AI.

For example, a Copilot Studio agent may be technically capable of connecting to several information sources.

I would still ask:

* Is the user authorised to access those sources?
* Should those sources be combined?
* Where is the information processed?
* Can sensitive information leave the environment?
* What permissions does the agent inherit?
* What happens if the agent retrieves information the user should not see?
* What is logged?
* Who supports the integration?
* How is access removed when a user changes role?
* What happens if the service is unavailable?

Those are enterprise questions as much as AI questions.

## Government user experience
Another useful part of my background is that I have seen how different government users interact with technology.

A nurse in a hospital has very different requirements from an endpoint engineer.

A Defence user may operate under different constraints from a project manager.

A public facing government service may have very different accessibility and privacy considerations from an internal enterprise system.

This has reinforced my view that there is no single correct user experience for government technology.

The solution has to fit the people, environment and consequence of the work.

That mindset would transfer well to the Federal Courts, where judges, registrars, associates, administrative staff, technical teams, lawyers and members of the public may all interact with technology differently.

## What this experience has taught me
Across these environments, I have learned several principles that would influence how I approach AI within the Courts.

**Security is part of the architecture.**

It should not be added after a system has already been designed.

**The user matters.**

A control that is technically correct but unusable can create its own operational risks.

**Existing systems matter.**

Enterprise environments rarely allow an engineer to design from a blank page.

**Governance matters.**

Being technically capable of implementing something does not mean it should automatically be implemented.

**Supportability matters.**

Someone needs to operate, monitor, update and troubleshoot a solution after the prototype is finished.

**Data boundaries matter.**

Particularly with AI, where information can move through models, connectors and external services.

These are lessons I would bring directly into the Court AI Technologist role.

## Limitations or gaps
I should not be represented as having been directly employed by every government organisation listed.

Much of this experience was gained while working for consulting or technology companies supporting government clients.

The distinction should remain clear.

I should not be represented as:

* an employee of ASD
* an employee of Home Affairs
* an employee of DFAT
* an employee of the Australian Space Agency
* an employee of Canberra Hospital
* an employee of Services Australia
* an employee of the Department of Defence

unless employment evidence specifically supports such a claim.

My level of access and responsibility also varied between projects.

I should not be represented as having unrestricted access to sensitive government systems or data.

Some engagements may have involved supporting a particular technical component rather than understanding the entire departmental environment.

I also have not yet worked inside the Federal Courts, so there will still be Court specific systems, policies and operational practices that I need to learn.

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

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

GitHub:
https://github.com/sudoqui

Unisys employment evidence

Department of Home Affairs project evidence

ASD related Unisys project evidence

DFAT related Unisys project evidence

Canberra Hospital MFA project evidence

Nova Systems internship evidence

Australian Space Agency related project evidence

Xaana.AI employment evidence

Services Australia related project evidence

DXC employment evidence

Department of Defence related project evidence

## Do not claim
Do not claim I was directly employed by every government department or agency I supported.

Do not claim I worked for ASD as an ASD employee.

Do not claim I worked for Home Affairs as a departmental employee.

Do not claim I worked for DFAT as a departmental employee.

Do not claim I was an Australian Space Agency employee.

Do not claim I was employed by Canberra Hospital.

Do not claim I was a Services Australia employee.

Do not claim I am a Department of Defence employee unless that is factually correct.

Do not claim I had unrestricted access to classified, protected or sensitive government systems.

Do not disclose sensitive architectural details from government environments.

Do not claim I designed the complete security architecture of any of these organisations.

Do not claim participation in a client project means ownership of the entire solution.

The accurate representation is that I have accumulated unusually broad government and enterprise exposure through consulting and engineering roles, working across national security, Defence, border operations, healthcare, foreign affairs, citizen services and space related environments, and have learned how technical delivery changes when security, governance, users and operational reliability genuinely matter.