01 · The Problem
The decision is larger than anyone's certainty.
The people closest to an important decision can all be competent and still see different parts of the system. The vendor knows the product. The internal team knows the history. The deal team knows the thesis. Each view is partial, and each carries its own incentives. That does not make anyone wrong. It makes the decision worth testing.
My role is to test the claims, evidence, economics, assumptions, and failure modes independently, then give the person accountable for the decision a conclusion they can challenge and act on.
The question is not who sounds most confident. The question is what the evidence actually supports.
02 · The Work
Four ways I take the difficult problem.
01
Executive Decision Review
Test the recommendation before the commitment becomes expensive to reverse. Architecture, infrastructure, major vendors, AI strategy, build or buy. An independent conclusion you can defend, in days.
Bring me the decision →
02
AI / Technology Technical Due Diligence
Know what you are buying before ownership changes. I test the technology, the security posture, and the technical claims against the investment thesis. The product is independent evidence relevant to the decision to buy.
Discuss the diligence →
03
Special Situations
Determine what actually happened, and resolve the technical question when the normal process has stopped producing clarity. Incidents, investigations, disputes, failures, and strange problems that fit no service catalog.
Discuss the situation →
04
Standing Independent Advisory
A direct line for a small number of leaders who face consequential technical decisions repeatedly. Second opinions, architecture and vendor review, board preparation, incident escalation.
Discuss standing advisory →
03 · Who Calls
I work directly with the person accountable for the decision. This is not staff augmentation.
Executives & boards
The room holds several technically plausible explanations and you need to know which one survives scrutiny.
Investors & private equity
The seller, management, the deal team, and the vendors can all have legitimate reasons to want the transaction to proceed. I test the technical thesis independently before capital moves.
Counsel
Technical reality has to become conclusions that withstand challenge, not advocacy dressed up as engineering.
Founders & technology leaders
Internal teams can be excellent and still be too close to the architecture, the prior decisions, or the implementation history to give you an independent test.
04 · Why Joey
I have spent my career in the difficult part of the problem.
At NCC Group I did acquisition-related security work: testing and examining technology before ownership changed hands. At IBM X-Force IRIS I worked high-severity incident response and investigations, inside technically ambiguous environments where the conclusion had to hold up in front of executives. At Microsoft I consulted inside enterprise-scale systems. Today I build and secure private AI infrastructure as co-founder and VP of Infrastructure & Security at Qompute AI.
The technology changes. The work does not. Enter the system. Separate evidence from assumption. Test the explanation. Tell the decision-maker what is actually true.
You get a conclusion you can test, challenge, and act on.
05 · Independence
Independence is not a disclaimer here. It is the product.
I am not paid by a hardware vendor to recommend more hardware. I do not need an acquisition to close, a prior technical thesis to be correct, or an architecture to become more complex. My economics do not depend on reaching a particular conclusion. That is what lets me disagree with the room when the evidence does.
This is not a claim that anyone else is compromised. Excellent people can still have different incentives, information, and perspectives. Consequential decisions sometimes deserve an independent test.
Any material conflict or commercial affiliation, including my role at Qompute AI, is disclosed before I accept an engagement. Where independence cannot reasonably be preserved, I decline the work.
06 · Representative Work
The pattern, by kind of matter.
Transaction diligence
Security testing and technical examination of companies before acquisition, so the buyer knew what transferred at close.
High-severity incidents & investigations
Response, forensic investigation, and recovery in production environments: containment, evidence handling, and the executive conclusions that follow.
Executive technical review
Hardware, vendor, and architecture assumptions examined before capital commitment. The review that happens before the invoice, not after.
Private AI & infrastructure
Building and securing private AI infrastructure for real workloads, and evaluating deployment readiness for organizations moving sensitive work onto their own systems.
Client matters are confidential by default. References and sanitized work product are shared selectively, under NDA, with serious counterparties.
07 · How It Works
Four steps. No theater.
Confidential brief
You tell me the decision, the deadline, and what failure costs. NDA first if you prefer.
Diagnosis
I separate fact from inference, assumptions from evidence, and material unknowns from noise. Then I ask what would have to be true for the proposed decision to make sense, and whether the problem deserves an engagement at all. If I am the wrong person, I say so and point you at the right one.
Scope & engagement
Scope, evidence standard, and deliverable agreed in writing. Then the work: claims tested, economics rerun, boundaries probed, evidence preserved.
Evidence & recommendation
A signed conclusion with the evidence behind it, written for the room where the decision gets made, and willing to say the inconvenient thing when the evidence says it.
Proceed
Do not proceed
Proceed only if…
More evidence required
Standing advisory
For a small number of leaders who face consequential technical decisions repeatedly: a direct line, second opinions, architecture and vendor review, board preparation, incident escalation. I keep these relationships few so each one gets my full attention.
08 · Field Notes
Selected research and field notes.
The Local AI Deployment Hardening Checklist ↗
40 checks across 6 domains for Ollama, vLLM, llama.cpp, and RAG stacks. Free, no email. Printable.
Tasia, an open-source private AI hardening tool ↗
Reviews the configuration of a private AI stack, flags exposure patterns with file and line, and writes a hardening pack. Go, Apache 2.0, prebuilt binaries.
The Private AI Exposure Index · ongoing research ↗
Measuring how private AI systems are actually exposed, and whether they can be investigated when something goes wrong. A transparent study of deployment architecture, access controls, model and data provenance, observability, and incident-response readiness. Public methodology. Source-backed observations. Controlled forensic testing. Results published only when the evidence supports them.
Field Notes, by email
One concise note when I find something worth knowing. Vendor claims tested, failure modes, infrastructure economics, lessons from incidents and live deployments. No news feed.
09 · Contact
Bring me the difficult problem.
Tell me what decision has to be made, when it has to be made, and what happens if the answer is wrong. I will tell you directly whether I am the right person for it, whether or not we work together.
Use the form · or email joey@victori.no
One or two lines is enough. Please do not send credentials, privileged material, or sensitive evidence through this form. NDA-first conversations are welcome.