Core takeaway: these projects help a hiring conversation only when they de-risk the candidate. They do that by showing technical judgment and claim discipline, not by pretending to be a commercial AI product.
My foundation is enterprise technology operations and service delivery at TMX Group, BMO, and BlackBerry. The independent projects featured here are Nexus Code and Homelab AI. Both are open source (FOSS), solo-maintained, and not commercial products as they stand. A commercial offering may be built on them later. That is not claimed here.
Broader AI Syndicate product directions beyond these two projects are under re-evaluation. aisyndicate.io is not live right now, so it is not linked and not used as evidence.
High-agency call: leaving a vanity surface offline and unpublished is the correct hiring signal. Inflating "AI portfolio" while the public site is down is how candidates create diligence debt for the hiring manager.
Why these projects appear in an ops leadership narrative
A senior operations or service delivery hire is often tested on a simple question: can you still judge systems when automation enters the picture?
These projects are adjacent evidence for that question. They are not a substitute for the employment record, and they are not a business-case substitute for TMX, BMO, or BlackBerry.
They show operational habits I already use at work:
- controls before convenience
- validation before trust
- recovery paths written down
- limits stated in public
For staff engineers: look at the control and recovery detail. For non-technical stakeholders: look at what is explicitly not claimed. Both audiences should leave with the same boundary.
Nexus Code
Operational question: how can an agentic coding tool make its actions reviewable instead of hiding them behind a single permission switch?
Public repository evidence includes:
- local coding client and harness (TypeScript agent/sidecar, Rust workspace tools, terminal UI)
- approval postures, workspace trust, and path controls (with documented limits)
- optional sandboxing and egress approval patterns described in docs
- Linux x86-64 installer with checksum verification
Useful for: conversations about reviewability, constrained execution, and inspectable agent behaviour when an ops leader evaluates AI tooling vendors or internal agent pilots.
Not proof of: a commercial product, multi-tenant hosting, enterprise deployment, paying customers, or reduced incident volume.
Homelab AI
Operational question: how do you treat self-hosted inference like an operable system when you are the only operator?
Verified shape of the work:
- Ansible configuration-as-code for a commissioned Dell Precision 5820 with dual Intel Arc GPUs
- Git as desired state
- authenticated gateway in front of per-GPU llama.cpp workers
- HashiCorp Vault for secrets
- validation evidence bundles
- upgrade tracks for current, candidate, and previous_known_good with rollback runbooks
Scar tissue: a second node profile remains uncommissioned. Desired-state docs are cheap. Commissioning, evidence, and rollback discipline are the expensive parts. aisyndicate.io being offline is another reminder: if the only public surface for a project is down, you do not have an operable evidence path.
Useful for: conversations about desired state, evidence, and recovery around a small inference lab, including how I would pressure-test a vendor's "self-hosted AI" claims.
Not proof of: a commercial product, managed service, multi-tenant production offering, or cost savings versus cloud inference.
How this should affect a hiring conversation
Bring these projects in if you want a senior ops or service delivery leader who stays close enough to technical work to judge automation responsibly, and who will not launder FOSS side projects into enterprise product outcomes.
Leave them out of any argument that requires a commercial AI offering, enterprise AI delivery proof, revenue impact, or customer retention evidence. That is not what they provide. The employment record is where business-critical operations evidence lives.
Primary objective: a senior technology operations or service delivery leadership role in Canada. Consulting remains secondary. Project notes and repositories are linked from the Projects section.