# Pyx: can this PR merge automatically?

Case walkthrough — spoken transcript.

Pyx. Can this pull request merge automatically?

For an engineering leader, a green pull request raises a practical question: can it merge without someone watching? Assay coordinates software delivery by agents under human governance. Pyx is our merge-risk assessment work. We'll follow an illustrative research-note correction to see how permitted scope, risk signals and fresh evidence shape that decision. You'll learn what sends a change back to people, and where today's implementation stops. The automatic merge-writing step is not yet implemented.

Our example corrects a dated engineering research note. A worker agent opens the pull request and links its work item. A reviewer checks the change. The operator has chosen this narrow document category for a potential automatic lane. That lane is an explicitly permitted class of work. Small size alone gives the PR no permission.

The evaluator checks every changed path against that permission. It also checks the hosting platform's author identity and the change's classification. Our research note can continue. An equally small edit to an agent instruction file cannot. The lane excludes files that could change its own rules or instruct future agents. A favorable risk reading cannot override that boundary.

Within the permitted category, the current evaluator counts six named reasons for concern. They cover review rework, unsuccessful CI, a changed head after a request, large size, missing model attestation and unreadable evidence. The initial policy's ejection line is zero. A clean zero means none of those signals fired on readable inputs. It is not a probability of safety.

Our PR's checks are still running. That does not establish green, but waiting for a result is different from finding a problem. If unreadable evidence is the only reason the evaluation cannot proceed, the command returns could-not-check without permanently ejecting the PR. Once the checks report, it can evaluate again. It cannot merge while that evidence is missing. Reported checks also need adequate test coverage; a green summary alone cannot establish that.

Now change the example. The reviewer requests a correction, and the worker pushes a new revision. Review rework fires; the older request also fires the changed-head signal. These are two conditions from one history, not two independent defects. In an activated lane, substantive ejection routes this PR to human review. Later approval does not automatically readmit it.

For an otherwise eligible PR, the final evaluation rechecks scope, reasons, prior ejection, current-head approval, check results and mergeability. It also checks the lane's operating permission and limits. Then it reads the head again. If the revision moved during evaluation, the operation refuses. A decision about yesterday's code cannot authorize today's different change.

That brings us to the present boundary. The public desk-auto-lane command contains the evaluator and a dry run. Its actual merge-writing operation deliberately refuses, even if every condition holds. Our house activation sign-off is also empty. So this is implemented decision machinery and an intended operating policy, not a service already merging these PRs unattended.

Before activation, the whole operating control needs verification. The initial policy caps the lane at three merges per repository per day. It calls for a ninety-percent first-pass-yield floor once ten lane merges exist. The current yield collector misses verification-failure history, so its ratio is partial. These settings describe a bounded trial, not proof that the lane is safe.

Pyx's broader learning loop is proposed. Keep the inputs known at decision time, then connect later failure episodes to candidate changes. Independently audit those links before treating them as training labels. Train on earlier changes and evaluate on later ones, against a simple baseline. A useful model could direct extra scrutiny. It would not gain permission to widen the automatic lane.

This is where Pyx differs from AssayScore. AssayScore summarizes recorded delivery across a reporting window. Pyx addresses the scrutiny of a particular change. Qualgen, the repository-quality analyzer, contains a separate learned-risk library. That library is groundwork, not evidence that a trained Pyx model runs in the merge path. No measured improvement is claimed here.

Take one candidate PR in your own project. Record its permitted category, exact revision, review evidence and check coverage. Separate waiting from a substantive reason for human review. Then identify the authority that permits the action and the conditions that stop the lane. You can establish this record with ordinary repository tools. The article explains the implementation and future learning path in depth.

For more Assay explainers, like and subscribe. You'll find the complete guide at Assay dot finance.