How to judge a Kin example
A useful example says what was tested, what happened and what remains unknown. Use these rules to judge the evidence behind Kin's claims. The examples were run by the company; independent reproduction is stated separately.
Who ran the test, and what kind of test was it?
Every case on this site is exactly one of three things, and its card says which:
- Founder-recorded
- Captured and audited by the company itself. No outside party ran it. This is what every case on the site is today.
- Independently reproduced
- Run again by someone outside the company against the same source revision and build, with their own result recorded. No case on the site carries this label yet.
- Comparison benchmark
- Measures Kin against a named baseline on a defined task set. The one benchmark this site has run this way is archived, not current; see /proof/archive.
Check the exact version and starting point
Repository and build pinning
A case is not called reproducible when its source revision or its preparation steps are missing, whichever one is absent. Every case record names the exact Kin build (version, commit, platform, the released archive's own checksum) and the exact source repository (name, head commit, commit and file counts) it ran against. A current-release page does not generalize a claim measured on an older build; a case pinned to an older build says so on the page, not only in a receipt.
Check what the task and timing include
Task selection, accuracy and performance
A founder-recorded case is not selected to make an accuracy or comparative performance claim, and none of the founder-recorded cases on this site makes one. A case may still report an elapsed time, and one on this site does; that is the figure its own receipt recorded for that command, not a claim about how fast Kin is. Task selection exists to exercise a real, checkable mechanism (a real migration, a real edit, a real restart) end to end, not to sample a task distribution. Timing figures, where a case states one, are the wall-clock elapsed time the harness itself recorded around that command, not a separate benchmark measurement; a case names its own timing methodology if it claims a time at all. Cold-versus-warm preparation is recorded per case only when it was actually measured; where it was not, the case record says so rather than assuming either state.
Empty and partial results
A check that did not run, or a field with no receipt behind it, is recorded as "not recorded," and a check that ran and failed is named directly, with its own tracking reference where one exists, rather than folded into a passing summary. A gap is disclosed beside the finding it sits next to, not only in a separate list a reader might not reach.
Check whether a comparison is fair
Comparison baselines and pass/fail criteria
A founder-recorded case has no baseline to compare against; it states what happened, not whether it beat something. A comparison benchmark names its baseline explicitly, and its result stands beside that baseline on the same page, including on the axis where the baseline came out ahead. Pass/fail criteria are stated per finding, on the case page that finding belongs to, not as one global bar every case must clear.
Check the saved files against their recorded checksums
Artifact schema
Every case's receipts are committed under apps/marketing/public/proof/<case>/, one manifest.json naming each file's path, byte count, sha256 and which claim it backs, and one .sha256 sidecar per file. A build-time check reads the manifest, recomputes every hash and fails the build if a file goes missing or its bytes stop matching what the manifest recorded. A case page's own artifact table is generated from that manifest, not typed by hand, and a second build-time check reads the rendered page back: it fails on a row the manifest does not list, a manifest row the page dropped, a row rendered twice, a row carrying another row's label, a byte count or hash on the page that stopped matching the manifest, and any table row that did not come from the manifest at all. The two cannot drift apart silently.
Independent reproduction
No case on this site has been independently reproduced today. Where a specification and a standalone checker genuinely exist for a different, comparison-benchmark result this company has published, this page opens it rather than implying it covers a founder-recorded case: Read the merge-trust specification specifies and scores a merge-trust review benchmark, a different benchmark from the one archived at /proof/archive, and it neither specifies nor scores that one. A private harness stays labeled private.
Read the merge-trust specificationWhat we have not measured
Every line below is an absence rather than a result, so the list stays true as work lands and only gets shorter, one line at a time, when a measurement replaces one. It is the whole of it, not a selection.
- No accuracy claim about the build we ship. We have run no governed comparison on it.
- No claim that Kin broadly beats grep, text search, Git, or GitHub.
- No token-reduction, time-to-merge, bug-catch, or merge-gate accuracy claim.
- No claim that advisory review automatically blocks a merge.
- No end-to-end result. We have not measured whether a change Kin helped locate goes on to pass tests or land.
Where to read a case
Every case that follows these rules is on /proof, with its full record on its own page and its dated entry in the archive.