發生了什麼事
Three researchers posted a preprint introducing PROVE-RT, an LLM-assisted pipeline for generating mechanized proof scripts in the PROSA/ROCQ framework used to verify that real-time systems meet their deadlines. The paper reports a 44.7% success rate on a curated and describes a corpus built from 1,191 real-time systems papers.
A preprint submitted to arXiv on 13 August 2026 and filed under Artificial Intelligence introduces PROVE-RT, a framework that uses large language models to generate mechanized theorem prover scripts for real-time systems. The listed authors are Sadat Shahriyar, Shareef Ahmed and Abdullah Al Arafat. Their stated starting point is that schedulability analysis, the step that certifies whether a set of tasks will always meet its deadlines, is usually established through pen-and-paper proofs that the authors describe as difficult to scale, validate and maintain. The record supplied by arXiv lists a single version, v1, and no journal or conference venue.
Some background is independently established rather than drawn from the paper. Real-time systems are those where a late answer counts as a wrong answer, which is why schedulability results underpin certification arguments in domains such as avionics, automotive control and industrial automation. PROSA is an open-source library of machine-checked schedulability proofs written for the Rocq proof assistant, the system formerly named Coq. Its appeal is that a proof accepted by the tool's kernel has been checked mechanically rather than reviewed by eye. Its cost is that writing such proofs demands both real-time domain knowledge and substantial proof-engineering skill.
PROVE-RT, as the abstract describes it, does not simply ask a model for a finished proof. Generation is broken into stages: dependency-aware informal sketches of the argument, retrieval from processed PROSA documentation, staged generation of a proof skeleton, and then proof completion. To support this, the authors say they built a mechanization-oriented corpus from 1,191 real-time systems papers containing 13,134 informal sketches annotated with dependency information. The abstract's diagnosis of why off-the-shelf models struggle is specific: state-of-the-art LLMs lack PROSA-specific knowledge of its modeling abstractions and proof patterns, rather than lacking general reasoning ability.
The headline result is that PROVE-RT reaches a 44.7% success rate on a curated , while direct prompting of state-of-the-art models 'fails to reliably generate valid PROSA mechanizations.' Several things that would let a reader weigh that number are absent from the material available here. The abstract does not name the models tested, does not give a numeric baseline for direct prompting, does not state the size or selection criteria of the evaluation set, and does not spell out what counts as success — whether, for example, a script must be accepted by the prover, must match the original paper's theorem, or both. Availability of the corpus, code and prompts is likewise not stated.
The paper is a preprint. It has not been peer reviewed, no independent replication is reported, and arXiv's automated posting process implies no vetting of the claims. Everything above about PROVE-RT's design and performance is the authors' account of their own system.
為什麼這很重要
Proof assistants give machine-checkable output, which makes them an unusually good testbed for automated code generation, and schedulability analysis feeds safety-critical certification in areas such as avionics and automotive control. But a majority of attempts still fail, and a script that compiles only guarantees the theorem it actually states.
Formal verification is a comparatively favorable setting for LLM code generation, because the proof assistant supplies an oracle. Where a model writing prose or ordinary software can produce fluent output that nobody can cheaply check, a proof script either is accepted by the prover's kernel or it is not. That property caps one failure mode: a rejected script wastes time but does not silently enter a certification file. It is the main reason automated proof generation has attracted research attention, and it is what makes a reported success rate meaningful in a way that a subjective quality score would not be.
That guarantee is narrower than it first appears, and the distinction matters for how this result should be read. A mechanized proof establishes exactly the statement it makes, under exactly the system model it assumes. If a generated theorem statement misdescribes the scheduling policy, the task model or the interference assumptions, a script that the prover accepts still says nothing useful about the real system. Human review of specifications therefore remains necessary. The abstract does not describe how the fidelity of generated statements to the original papers was checked, which is among the most important open questions for anyone assessing the work.
The practical stake is the cost of mechanization. Much of the published schedulability literature exists only as informal proofs; mechanizing an existing analysis in PROSA is skilled work that few groups undertake. Assistance that clears part of that burden could, in principle, widen the set of results that are machine-checked, which is the kind of infrastructure improvement that matters more to certification practice than to headline AI capability. The paper does not claim to have found errors in any published analysis, and no such claim should be read into it.
A 44.7% success rate should be read as assistance, not automation. More than half of the attempts in the authors' own evaluation did not succeed, and the abstract does not quantify how much human effort the remaining cases require, nor how much compute or how many sampling attempts each success consumed. In a domain where the alternative is an expert writing the proof by hand, a tool that solves some cases and fails visibly on others can still be worth using — but the value depends on details the abstract leaves out. Separately, the 13,134-sketch corpus may prove as durable a contribution as the pipeline itself, if it is released.
互動機制：它實際上是如何運作的
以互動方式探索這項發展背後的基礎技術。
Before relying on ChatGPT & LLMs for an important decision, what should you confirm first?
接下來看什麼
Whether the paper clears peer review, whether the corpus, code and prompts are released, how 'success' is defined and measured, and whether independent groups reproduce the result or the approach transfers to other proof assistants and domains.
The first thing to watch is the artifact question. Whether the corpus of 13,134 dependency-annotated sketches, the retrieval index over PROSA documentation, the prompts and the generated scripts are published will largely determine whether this result can be checked or built on. A preprint reporting a single aggregate percentage is difficult to evaluate without them, and reproducibility in LLM-assisted proof work is particularly sensitive to model versions, sampling settings and retry budgets.
Second, the measurement details. Readers should look for a stated definition of success, the size and construction of the curated , whether problems were drawn from the same distribution as the corpus, and whether any contamination check was run against material the base models may already have seen. Ablations matter too: the abstract attributes gains to retrieval, staged skeleton generation and dependency-aware sketching together, without separating their contributions.
Third, durability. If the advantage over direct prompting comes mainly from supplying PROSA-specific knowledge that base models lack, that gap may narrow as models improve or as PROSA material enters training data — in which case the scaffolding's value would shift toward the corpus and the staging discipline rather than the retrieval step. Watch whether the authors or others re-run the comparison against newer models.
Fourth, uptake and transfer. Concrete signals would include generated proofs being reviewed and merged into the PROSA library upstream, independent groups reproducing the success rate, and adaptations of the approach to other proof assistants such as Lean or Isabelle, or to verification domains beyond schedulability. Peer review at a real-time systems or formal methods venue would also add scrutiny that arXiv posting does not provide.
Finally, the certification question, which remains genuinely open. Machine-checked proofs have the useful property that their validity does not depend on who or what wrote them, which is an argument for treating AI-assisted mechanization as acceptable in safety cases. Whether standards bodies and regulators governing safety-critical software take that view — and what evidence they would require about specification fidelity — is not addressed by this paper and has not, as far as the available material shows, been settled.