About Ghost Works

Why the company exists

The interesting problem in software right now is not whether AI can write code. It can. The problem is that it writes toward the average of everything it has seen, while you are trying to build one specific thing, for one specific set of reasons, under constraints that exist mostly in your head and in decisions nobody wrote down.

Every existing safeguard sits on the wrong side of that gap. Linters read syntax. CI reads tests. Code review reads whatever a tired human catches on a Thursday. None of them can read intent, because intent is not a data type — it is context, history, and judgment that no tool in the chain currently holds.

We build the layer that holds it. That is the entire thesis of the company, and every product we ship is an expression of it.

Who we are

Trevor Lukanen

Co-Founder & CEO

Trevor is a systems architect and a product and UX leader whose career spans two successful startups, Fortune 500 companies, and federal contracts. x-Arbiter began as a side project, while he was prototyping his own startup ideas — Whowe and Community Air — with AI-assisted coding. Hitting the same wall over and over — AI drifting from what he actually meant — he built a governance layer that keeps any model aligned to the human's intent, standards, and hard-won decisions instead of the training-data average. When that layer proved more valuable than the apps that produced it, he paused them to finish x-Arbiter — the culmination of fifteen years designing products, shaping development workflows, and leading delivery across the public and private sectors.

Yeng Lukanen

Co-Founder & COO

Yeng is a senior UX researcher on federal contracts — she studies how people actually work with complex systems, which is the exact lens x-Arbiter is built on: it governs the human–AI relationship, not just the code. A former business owner and certified Scrum PM with hands-on AI-assisted R&D, she runs operations and delivery and keeps the product honest about the people it is for.

That is the whole team, and it is deliberate. The people who build x-Arbiter and the people accountable for it are the same two people — and we run it on our own code every day, so nothing reaches you that we have not already had to trust ourselves. A small, focused team is how a product keeps one coherent point of view instead of drifting toward the average of a large one — which is, after all, the problem we built the company to solve.

How we work

We use our own governance tooling on our own codebases, including this website. Every rule that would apply to a customer applies to us first. It is the only honest way to sell governance — if the framework cannot survive being pointed at its own authors, it is not ready to point at anyone else.

We use AI heavily, and we are explicit about who decides. The human sets direction and holds the override at every gate; the AI executes inside that boundary and declares ambiguity rather than filling it with its own judgment. We think that distinction is the difference between AI that compounds a team's work and AI that quietly replaces its intent.

And we try not to say things that are not true yet. Where a product is unreleased, our site says so in the place you would otherwise assume otherwise. A company selling accountability infrastructure does not get to be loose about its own claims.

Who we build for

We build for developers first. The person who feels the problem — AI drifting from what they meant, the same correction made twice — is the person who adopts the tooling, so everything starts with making their work better. What one developer adopts, a team can run on together: the same intent, standards, and hard-won history applied to everyone's AI, rather than re-explained person by person.

And the work a team directs still has to answer to the people they report to. Keeping AI aligned to what a developer — and a whole team — intends, in a way a security lead, a CTO, or a federal compliance reviewer can also stand behind, is a harder thing to build, and it is the thing we are building. The audit trail that supports a NIST 800-53 or ATO review is meant to fall out of that alignment, not a separate project bolted on at the end.

That range is deliberate: credible to the developer writing the code, to the team building alongside them, and to the executive who has to sign off on it. It is also why we are strict about our own claims — the people we ultimately serve are the ones who get audited.

Where we are

We are pre-launch and pre-revenue — deliberately, getting the foundation right before chasing growth rather than the other way around. The flagship product has not shipped yet; when it does, local enforcement will be free permanently — not a trial that expires — because a governance layer you can lose access to is not a governance layer.