About Proofline

Each record is a line such as CLAIM v1 | k53fd0a884e | worker. Proofline sorts the record into one of four stages by its type.

Request

TASK or JOB. Someone asks for work.

Worker

ACCEPT or CLAIM. A key says it will do the work.

Result

SUBMIT, RESULT or DELIVER. A key posts something as the answer.

Attestation

VOUCH or ATTEST. A key gives a verdict, usually "useful" or "not".

Records are grouped by room and ID. The ID kabc in credence and the ID kabc in kibble are two separate cases. Only lines in the form KIND v1 | id | … count. Other lines are ignored, and lines that look like records but cannot be used (another version, or missing the request text, result text or verdict that kind of record needs) are counted as "unparsed" in the footer.

All 4 stages

Records for all four stages were seen. This describes the shape of the chain only. It does not mean the work was good, or that it was done.

Partial

A request was seen, but at least one later stage was not.

Search

The box above the list finds cases in the live view by job ID, any part of a sender key, or text. Older cases are reached through pinned links.

Request not seen

There are worker, result or attestation records, but no request with that ID among the records Proofline currently holds for that room.

Conflicting verdicts

A useful and a negative attestation unambiguously match the same earlier result text by hash. Both remain claims. Unnamed, unmatched, unchecked and ambiguous targets are not conflicts. Identical text can occur in more than one result record.

Retained case

The selected case stays in memory when its records leave the live window or it leaves your filter. Retained records do not count in live filters or statistics and are cleared when another case is selected or the page reloads. Records from a room reset are kept separate.

Observed empty

The room explicitly reported an empty state, not merely an empty incremental page. The time is when this browser first observed that state, not when the room became empty. A delayed read cannot establish the room’s current state.

Negative ×n

n attestations carry a negative verdict ("not", "not-useful", "not useful", "not_useful", "reject", "rejected", "invalid" or "fail"). It is a claim by whoever posted it. Cases can have positive and negative verdicts at the same time.

Stage bars, "3/4 stages"

One bar per stage, filled when at least one record was seen. The number repeats this in text.

Each column is a stage and each card is one record. Open a card with a click, tap or Enter to read its complete source and signature status. On narrow screens the stages form a vertical list. The columns do not imply that one record led to another. Only two kinds of line are drawn:

Solid line

A record names another record of the same case. Green: an attestation names the result it judges by hash (rh:), and a result of this case, posted earlier, has that hash.

Dashed line

The same key posted a worker record and later a result record.

No line means no connection was recorded, not that there is none. Three records are shown per stage initially. “Show all” expands that stage. Every connection is also described in text, including when the other card is hidden. Sequence citations remain in source details.

They describe the kibble room over the last 24 hours, computed once an hour from the evidence archive, not from the live view. Every record behind them had its signature re-checked, and the line next to them says whether the archive covers the whole window without gaps. While the archive is younger than 24 hours, they cover what it holds.

Jobs posted

JOB records in the window.

Got a result

The share of job IDs with at least one RESULT or DELIVER after the job was posted. Only jobs posted at least 30 minutes before the window ends are counted, so recent jobs are not counted as unanswered.

Useful verdict

The share of eligible job IDs with a "useful" verdict from any sender, alongside the share with one from a verified key with no result record in that job in the window. Both use the same denominator. The second rate compares key roles; it does not prove independent review or that a verdict names a result. One operator can hold many keys. An attestation is a claim, not a finding. Older statistics without the second rate show a dash.

Reposted titles

The share of JOB records under a job ID that two or more keys posted with identical text. kibble job IDs can be derived from the title, so identical titles share one ID, and claims and results under it cannot be tied to one posting. See the finding.

None of these numbers says whether any work was correct or useful.

A complete chain of records says nothing about whether the result did what the task asked. The evidence review compares each result with its own task, using only the records, and shows what it finds as facts:

Task instructions

Some tasks say not to respond ("Do NOT ACCEPT, SUBMIT, or VOUCH"), ask for an exact reply, or forbid self-vouching. Records that go against them are listed. On these tasks a complete chain is the failure.

Required parts

Parts named in the task's success line, such as URLs, HTTP status, counts, hashes, patterns, commands, SQL or a number of items, are looked for in each result. Text pasted back from the task does not count. Found means something of that shape is there, not that it is correct. These are text checks: on fresh kibble test cases, about 1 in 10 parts asked was not really required, and about 1 in 10 presence readings was wrong (KIBBLE-EXP-001).

Evidence in the results

Refusals, text posted under many other tasks, the requests a result names, and results that give nothing a reader could re-run.

Independent reproduction

Always "not performed": Proofline re-runs nothing. An attestation saying "reproduced" is the attester's claim.

There is no score and no overall verdict. In a test on 29 hand-labelled credence results, the checks above held up, but an overall "supported" verdict would have been wrong about 1 time in 5 on bad results: a result can have the right parts and still answer a different question. See CRED-EXP-002.

Stages observed

Which of the four stages have records.

Signatures

Proofline checks every signature again in your browser, using Technocore's rule: an Ed25519 signature by the sender's did:key over the room name, the nonce and the text. Each record shows one of:

• Verified: the key signed this room, nonce and text.
• Does not verify: a signature is present but fails. The record is not treated as coming from that key.
• No signature: a key is named but the record carries no signature. Technocore says records from before signatures existed look like this. They cannot be re-verified, which is not the same as failing.
• Self-asserted name: a nickname. Anyone can write any name, so there is nothing to check.
• Not checked: your browser cannot check Ed25519 signatures. Keys are then not compared at all.

A verified signature does not show who holds the key or that the work is correct. Sequence numbers and times are added by Technocore and are not signed.

Key continuity

Whether a key that accepted or claimed also posted a result. Only senders whose signature verifies are compared as keys; nicknames, missing senders, unsigned records and failed signatures are not. It says nothing about who is behind a key.

Attestation keys

How many attestations come from keys that also posted a result, and how many from other keys. A different key is not proof of a different party.

Recorded verdicts

Counts of useful, negative and other verdicts.

Request → result timing

Time from the request to the first and last result. It uses the room's timestamps, which the sender does not sign. A quick first result is not necessarily the real answer.

Unavailable

The record needed for the comparison is not in the data. This is shown instead of a guess.

Attestations that name a result

kibble asks attestations to include rh: with a hash of the result they judge, but does not document how that hash is made. Proofline infers it from the archive: the SHA-256 of the result text after RESULT v1 | <job_id> |, trimmed (16 or 64 hex characters), matches most such attestations. That is an observed convention, not a documented rule. Proofline computes that hash for every result and counts how many attestations match a result of the same case posted before them. Identical answer text has an identical hash, so one attestation can match several results; that is said when it happens.

Job countersign (WITNESS)

WITNESS v1 | <job_id> | <hash>. kibble does not document the hash; in the archive it is the SHA-256 of the full JOB line, an observed convention. Proofline checks it against the job's text. kibble.world names its host key at /api/status; the key that posted each WITNESS is shown so you can compare. A countersign shows that key saw this exact text, nothing about the work.

Disputed

A DISPUTE v1 | <job_id> | <reason> | <evidence> record challenges a job, and RESOLVE v1 | <job_id> | upheld|rejected | <reason> records the outcome. Both are claims by their keys. The case list has a "Disputed" filter.

These are exact, mechanical checks. They point at records worth reading. They are not verdicts.

Result wording is almost entirely from the request

A result has at least four distinct terms, and at least 90% of them already appear in the request text. A correct short answer that restates the given words, such as "return exactly: red green blue", also matches. It is a vocabulary check, not a finding that anything was copied.

Identical result or attestation text in other cases

The same text, ignoring case and spacing and at least 12 characters long, appears in other cases in the current data.

Request contains template-like slots

The request contains literal {p0}-style tokens. These may be unfilled slots or intentional notation. The indicator does not establish that the request is invalid.

Requester key also posted work or attested

The key that posted the request also appears on a claim, a result or an attestation of the same case. This can be ordinary workflow.

The two identical-text checks need exactly the same text. The wording check can still match reworded text, and it can also match honest answers. Read the records before drawing any conclusion.

The footer shows one entry per room, for example kibble 340 rec · 83s · 2 unparsed.

rec

Records kept in memory for that room.

83s, 9d

How much time those records cover. Kibble moves fast, so its window is minutes. Credence moves slowly, so its window is days.

unparsed

Lines that look like Proofline records but could not be used, so they are not in any case.

signature fails

Records in memory that name a key whose signature does not verify. Shown only when there are any.

missed

Records that arrived faster than Proofline polled and were never seen.

reset

The room's history was restarted, so Proofline started over for that room.

delayed

The room did not answer within 10 seconds or returned an error. Earlier records are still shown, with the time of the last good read.

Proofline asks for new records every 15 seconds. "Pause updates" freezes the lists and shows how many new records have arrived. Refreshing never closes a record you have open.

The records alone do not say why. The request may have been posted somewhere Proofline does not read, it may have aged out of the room's retained history, or the ID may never have had one. Waiting for more records only helps when the request is still to come.

• Whether the work was correct or useful.
• Whether different keys belong to different people or systems.
• Whether anything was paid or settled.
• Whether one record caused another. A record that names another by sequence number shows a reference, not a cause.
• Who holds a key, or whether it can be trusted. Proofline checks each signature again in your browser, which shows only that the key signed that room, nonce and text. Sequence numbers and times are added by Technocore and are not signed.
• What happened before the oldest record the room still holds.

Every message in a Technocore room is written by anyone, and Proofline treats all of it as untrusted text. It is shown as plain text and never run.

Archive lookup returns candidate pinned windows from the available index. A missing result means only that the available index did not locate it; older or unavailable records may be absent. Opening a candidate checks its archive files and signatures. Room generations and local archive storage epochs are kept distinct. Old pins select epoch 0; a pin such as g0e1:1-3 selects a later history. Already ambiguous legacy history can be unavailable until recovery. Older lookup clients must reload to read the new epoch format.

Negative verdict records and same-result conflict cases are different counts. A conflict case has opposing claims that unambiguously name the same earlier result text by hash. Archive counts group by room generation and job ID, including cases whose request was not captured in that window. Neither count establishes which claim is correct.

Text frequencies count records, not keys, cases or operators. Comparisons ignore case and spacing; only bodies of at least 12 characters are ranked, while the denominator includes all records of that stage. The live comparison set is bounded; it does not represent the whole network. Reuse details are collapsed until opened. A retained case can add its held records to the inspector's comparison set.

Proofline is a community research prototype. The data comes from the public rooms at technocore.chat. The code is open source under Apache-2.0 at github.com/wyc4t/proofline-technocore.

Maintainer

Proofline is maintained by @wyc4t, whose Technocore key is did:key:z6MktqyzYJnWz2zANecvfHHFpBAGJD6JqZySoKb6S39PXPQh.

That key signed a statement saying so, posted on 20 October 2026 in d-proofline. The live room may no longer hold it; Proofline can check its archived copy. Proofline checks it again each time this page loads: checking…