The First Halfway Model: Capability Is a Pipeline Property

AIxCC’s evidence contract and the finalist architectures now fit together into one practical judgment: a cyber reasoning system’s capability is visible only after it survives a chain of handoffs. The useful question is no longer simply which system had the cleverest technique. It is where a capability entered the chain, what evidence it produced, which boundary preserved or weakened that evidence, and what finally reached the evaluator or a developer.

This perspective connects three ideas that are easy to keep separate. AIxCC defined the kinds of evidence that counted. The finalists built different routes to produce that evidence. And every route had to operate under time, accuracy, resource, and coordination constraints. A system could therefore contain a powerful technique without converting that technique into a reliable result. The same evidence contract could yield different outcomes because the systems did not expose the same failure surfaces.

One chain, multiple places to lose the thread

Start with a development signal: a release, a pull request, or a static-analysis alert. The signal gives the CRS an initial question, not an answer. A release opens a broad search; a pull request supplies a narrower but incomplete clue; an alert proposes a possible problem that must be judged. The first transformation is from that signal to a candidate vulnerability.

The candidate becomes meaningful when the system produces a proof of vulnerability. The PoV connects a hypothesis to an observed runtime behavior. That handoff can fail in several ways. The system may never reach the relevant path. It may generate an input that looks promising but does not reproduce the behavior. It may find a crash whose signature is too coarse to distinguish it from other bugs. Or it may discover several inputs that all describe one underlying flaw and then mistake them for separate findings.

A successful proof creates a new obligation rather than ending the process. The patching system must infer a cause, decide what to change, and validate the edit. The validation boundary is where a plausible repair becomes more or less credible. Building the project shows that the edit is syntactically and structurally acceptable. Replaying the PoV tests whether the observed behavior has stopped. Project tests provide some protection against functional regression. None of these checks, by itself, proves that the root cause has been completely repaired, but together they create stronger evidence than a generated diff alone.

The final handoff is relational. The system must decide which proof, patch, and alert belong to the same vulnerability. If it submits every input separately, it can waste time and create duplicates. If it groups distinct flaws, it can make the report misleading. If it pairs a patch with the wrong proof or alert, the pieces may each look reasonable while the overall claim is false. The evidence contract therefore runs through identity as well as content: the system has to preserve what an artifact means and what it is connected to.

flowchart LR A["Research techniques and model reasoning"] --> B["Candidate and proof"] B --> C["Patch and validation"] C --> D["Linked submission"] E["Integration and state management"] --> B E --> C F["Operating conditions"] --> E G["Submission strategy"] --> D D --> H["Observed score or maintainer-facing result"]