Read a kernel run
Every run has a page, rounds, rule checks, the reviewer panel's votes and reasons, and a "passed" verdict. Here's how to read it.
Every kernel run returns a run_url (the post editor links to it as the run's page). Open it to see what the kernel did.
The timeline
Events in order, each with a one-line label:
- Round began: a revision round, with the word count going in.
- Drafted the article: the write step: words produced, how much changed, retries.
- Rule "…": a house rule checked. Not violated means the step was skipped; violation fixed shows the share of text that changed.
- Person check, punctuation and framing checks: the gates on narrator, punctuation and framing. The person check shows a count per tier and how many sentences were held for judgement; the other two show a pass or fail mark.
- Shred applied (only on collections that shred): how much of the round each provider rewrote, and whether the share of untouched text is within the ceiling.
- Jury voted N–M human: the reviewer panel's verdict for the round. Each reviewer has a role (a literature professor, an editor, a domain practitioner), a vote, a confidence, and a paragraph of reasoning.
- Passed after N rounds: or did not pass.
passed
true means the panel judged the final text human-written. false means the kernel used all its rounds without a majority; the text returned is the round with the best tally, not necessarily the last. A false isn't a failure to write, it's a signal that this material and this voice fought each other. Read the reasoning; it's usually specific ("the third section lists where it should argue").
The effective config
The summary shows the levers that decided the outcome: the drafting model, the panel's model, whether the word-rarity check was on, the target word count (0 = unbounded), the maximum rounds, and, on a collection that shreds, the shred settings (such as the provider pool the rewrite drew from). A run with several rounds gets a row of round buttons at the top that jump to each one. Two runs under the same kernel name can differ here if the kernel was updated between them, so compare configs before comparing pass rates.
The read-back
Separately from the trace, every run records a verification block: the constraints you set, read back against what came out. Five checks, each pass, fail or skipped:
| Check | Reads back |
|---|---|
shape | Every heading you asked for is present, in order, and lists and tables are there |
length | The article is within a tolerance of your word budget |
person | The narrator is the one you asked for |
jury | The reviewer panel's own verdict on the text that shipped |
entities | Each name you declared appears as often as its treatment allows |
A constraint you did not set reads skipped, never as a pass. A failure is recorded and returned, never hidden, and never blocks the run: what to do about it is your call. get_kernel_endpoint_run returns it alongside the article.
Where else it shows
- The post's Auto-Pen panel links to the run.
- Over the API,
get_kernel_run_statusreturnsrun_url. - A test run from the Kernels builder (KB-705) shows the same timeline under its result.