Founder-recordedRecorded session on the shipped release
Can Kin show how two pieces of code connect?
This example asks Kin what uses a piece of code and follows one connection. The saved answer can be checked against the project it came from.
A company-run historical example. It does not prove complete code coverage or that a change is safe.
Read the exact test question and interpretation
kin-demo, asked three questions on the exact public v0.7.6 release archive
Take the macOS arm64 archive GitHub publishes for this release, point it at a real Git repository it has never seen, and ask the graph three things: which build is answering, what reaches one function, and how a named caller gets to another. Then publish the exact bytes it printed.
Expected interpretation. A correct run answers from the record it built rather than from a scan of the checkout, and says how sure it is. Each command exits 0, the reference list names real entities at real paths, the route names the call sites it walked through, and the route carries its own verdict rather than leaving the reader to assume one. It does not establish that the graph holds every relationship in that repository; the reference list is a set of positive facts, not a completeness claim.
Source revision, build identity and preparation
Check versions, source and preparation
- Kin build
- v0.7.6, macOS arm64, commit 64174f30e9ffa107510bbebb8072f1be375cd77f
Release on GitHub - Source repository
- kin-demo, head 8616137f60fc5c69b7234a1c9094f2a109eebca4, 67 reachable commits, 212 files
- Released archive measured
- kin-macos-aarch64.tar.gz
sha256 4568f19d6cf8485a12374255f59357b0c6464a6e866ffc1bef80ac62235c6676 - Environment and preparation
- The capture removed every KIN_* variable except KIN_HOME before running, so no correctness-relevant override was active and the run is the plain one a reader gets. Kin prints a startup warning for each such override; the receipts carry none. KIN_HOME pointed at a scratch directory made for this run, so nothing was read from or written to an existing store.source
- Graph-readiness output
- Read back by kin status against the same store immediately after the import and before any query: 2,535 entities, 25,642 relations and 94 changes recorded in durable authority generation 2, over a tree of 212 artifacts at the head commit named above. The same read reports its own limits, including that no daemon held the live graph at that moment and that live embedding coverage was therefore not observed.source
- Capture date
- 2026-09-09. Captured on the bytes of the current published release archive, against a public repository at a named commit, and the clips on /proof are an animation of these exact streams. It is indexed on the proof archive.
Findings: original output, source and explanation
The exact public macOS arm64 v0.7.6 archive, checksum-verified against GitHub's own release assets.
Read the method and original output
sha256 of the downloaded archive, checked against the checksums-sha256.txt GitHub publishes beside the release, and the binary's own --version line read back afterwards.
kin 0.7.6 (64174f30e9ffa107510bbebb8072f1be375cd77f detached 2026-09-09T08:52:59Z)
The released binary imported a real Git repository it had never seen, end to end, exit code 0.
Read the method and original output
kin init . against a fresh clone pinned to the head commit above, with the full stdout and stderr committed.
Asked what reaches one function, it named 25 entities, each with its kind, its file and the relationship the graph records.
Read the method and original output
kin refs loadConfig against the imported store, exit code 0. Each row is a positive fact the graph holds; the command makes no claim to hold every reference in the repository.
Asked how one caller gets to another function, it returned a two-hop route naming the call sites at each hop, and marked its own verdict certified.
Read the method and original output
kin path startServer expandHome against the same store, exit code 0. The verdict line is the command's own, not a summary written here.
Timing methodology. Every elapsed figure in session.json is wall-clock time around that command, measured by the capture harness from process start to exit. No figure on this page is a separate measurement layered on top, and none of them is offered as a performance claim.
What the same run reported about itself · FIR-3417
The first query after the import waited on the daemon and the client logged that the daemon was up and serving but reporting health=attention, degraded. It served the query anyway and the answer is the one published here. This run does not establish what that degraded state was, and it did not run kin doctor to find out.
Read the exact error
daemon is up and serving but reports health=attention (degraded); continuing to use it. Run `kin doctor` for details.
The daemon start and the health line, as logged
Known gaps: what this case does not establish
- Completeness. The reference list and the route are positive facts the graph holds. Neither is a claim that the graph holds every relationship in this repository, and an absent row is not evidence that a use does not exist.
- Accuracy against a baseline. Nothing here was scored against grep, another tool, or a task set, and no comparison was run.
- Any language other than TypeScript and JavaScript. This repository is a TypeScript application; a language whose adapter this build does not wire would answer differently, and says so in its own verdict when it does.
- Anything about editing, committing, branching or merging. This case asks three read questions and makes no claim about what Kin does when the code changes.
- Performance. The elapsed figures in the session record are what the harness measured around each command on one machine, not a claim about how fast Kin is.
Not recorded
A field with no receipt behind it is listed here with the state recorded for it, rather than filled in with a plausible guess. The rows that link a source are named from that receipt's own keys and carry its exact wording, so a reader can find each one in it. Nothing below is a result.
See which checks have no recorded result
- Cold versus warm preparation
- not recorded. The import ran once on a fresh clone and the queries ran after it. No receipt in this run distinguishes a cold store from a warm one, so neither is claimed.
- The degraded daemon health state
- not recorded. kin doctor was not run, so what health=attention meant for this store is not established here.source
- Independent reproduction
- not recorded. Nobody outside the company ran this case. It is founder-recorded, as /proof/methodology defines that label.
Download the files behind this example
The saved files let you inspect the result. Each has an identity check so changes to its contents can be detected.
View all evidence files and checksums
Every file below is committed with its own sha256 sidecar, listed in manifest.json, and checked against that manifest at every build by check-proof-artifacts.mjs. This table is generated from that manifest, not typed by hand. check-case-record-integrity.mjs then reads this rendered page back and fails the build on a row the manifest does not list, a manifest row this table dropped, a row rendered twice, a row carrying another row's label, a byte count or hash here that stopped matching the manifest, and any row that did not come from the manifest at all.
How a case is built names the rules this record follows, and the archive keeps every artifact path a case was ever cited by.