The bottleneck moved from writing to verifying.

Why the name

Moonlight is how you see in the dark. It does not make the night into day, and it does not pretend to. It shows you enough of what is in front of you to move, and it is honest about the edges of what it lights.

That is the product. A change arriving for review is dark: nobody has the whole picture, and under queue pressure nobody has time to get it. We light as much of it as we can, we show you what we saw, and we say where the light stopped.

What we are actually building

The near-term product is a reviewer. The long-term asset is calibrated judgement: a growing record of how our confidence compared to how real teams judged real changes. Every time a team agrees with a position, overrules it, or ignores it, we learn whether our confidence was justified.

The underlying models will keep changing, and we are built to swap them out as they do. Knowing when to be confident is the part that takes time to earn, and it is the part that lasts.

How we intend to behave

The hard limits are the short version. The longer version is that this product only works if a team believes what it says, and belief is spent faster by one confident wrong answer than it is earned by fifty right ones. So we would rather report a gap than fill it, and rather lose a deal than overstate what the product checked.

You can see the same discipline on this site. The pricing page states a number rather than asking you to book a call to hear it. Capability pages describe what each check does and where the boundary is.