Skip to content
refereekit

Architecture

Three pictures of refereekit: where the paper’s text may go, who decides what, and how one review runs over time. The first two use four colors. Green is refereekit, and amber is what it adds to your agent. Purple is a service or file it does not own. Red is a step only you take.

The big picture

Section titled “The big picture”

You chat with a coding agent. Its model calls refereekit’s tools, which answer with counts, codes and page numbers only. You ask the questions, give the verdict, read the answers and edit the drafts in a private view. refereekit never gives what it shows there to the agent’s model. You submit by hand.

The referee, the coding agent, the private view, refereekit, and what refereekit touches: the submitted PDF, the session folder, the model backend, OpenReview, the memory file and the Q&A page. The agent calls the refx tools and gets counts, codes and page numbers; the referee reads and types in the private view, which alone gets the private parts. Manuscript text goes only to the model backend, and only if the venue permits it and the referee attested zero retention. The hook guard blocks the agent from the session folder, .env and the PDFs.

The paper’s text leaves your computer by one route: the model backend. Two checks stand on it, in order. The venue gate refuses a venue known to forbid outside models. Then refereekit refuses any backend you have not declared keeps no data. OpenReview is read-only. The memory file holds your own notes, each checked against the paper before it is stored.

Where you stay in control

Section titled “Where you stay in control”

On one side, what refereekit decides mechanically: every anchor’s verdict, which claims enter the pool, which draft citations are flagged, and the refusals before any send. On the other, what only you decide: the verdict, the section lengths and the answers for the editor, every word of the drafts and every FLAG, and submitting and deleting the session. Only your decisions lead to the report sent under your name.

refereekit’s decisions are mechanical and repeatable. The same quotation on the same page gets the same verdict every time. Every judgment is yours. The triage list puts what needs you first, so you read a list rather than a transcript.

How one review flows over time

Section titled “How one review flows over time”

A sequence between the referee, the coding agent, the private view, refereekit, the local PDF, OpenReview, the model backend and the memory file: the agent starts a session and gets a reference; it opens the review in the private view; the referee asks each question there and reads each checked answer there; the referee gives the verdict, the lengths and the editor’s answers there; refereekit drafts from the pool and shows the drafts there, while the agent gets counts; the referee edits; the agent runs check and finish and sees only counts; the referee submits by hand; the agent asks to close the session, refereekit shows the referee what deleting destroys, and the referee says yes on their own screen, in pi’s dialog, the client’s confirmation form or the review window, never in the chat.

The agent starts the session, opens each view, checks the drafts and asks to delete the session at the end. The questions and the drafts send the paper’s text, but only from refereekit’s own process, through your model backend. No paper, question, answer, verdict or draft goes from refereekit to the agent’s model.

Why it is built this way

Section titled “Why it is built this way”
  1. Confidentiality is in the structure. The paper reaches a model only through one gate. The agent’s model is never trusted with it. This prevents accidental leaks. It is not a sandbox.
  2. Verification is narrow on purpose. A PASS on a quotation means these words are on that page, and nothing broader. It would rather refuse than assert. A false PASS would put a wrong citation in a report under your name.
  3. A session is bound to one PDF. A claim checked against one version is never read again against another.
  4. Your edits are kept. A draft you edited is replaced only on your yes, and the earlier copy is kept.
  5. Notes hold your words, never the paper’s.

Everything drawn is built and tested offline. The agent integrations are not yet checked against the real agents (see Reviewing in your coding agent).