Independence cannot be manufactured, but it can be routed.

Every ungrounded verification edge in vercel-ai, paired — where a pairing exists — with an anchored producer already present in the same measurement. Nothing here invents an anchor, and nothing here has been applied.

target	vercel-ai
revision	e29788dd545f8bf2300db0885658e639b4fd91bd
source report	reports/vercel-ai.json
generated	2026-07-25T05:19:41.017Z
status	proposed (all 2)

0.80

today — measured

0.80

projection if applied — 0 re-grounded · 0 constructed

anchored / (anchored + self_referential + unknown)

anchored 8 self_referential 0 unknown 2 not_a_check 15 excluded from the denominator

The second number is a projection: the ratio this target would carry if a human applied every route below and the applied routes measured as anchored on re-measurement. It is arithmetic on a hypothetical. It is not written to any report, it is not fed back into the grounding ratio, and no proposal on this page has been applied. Projected counts, for the same conditional: anchored 8 · self_referential 0 · unknown 2 · not_a_check 15. The delta is two different claims and is reported as two: 0 re-grounded — an existing check whose signal moves outside the write boundary, the proposition it asserts unchanged — and 0 constructed — a not_a_check node that becomes a check, entering the denominator as well as the numerator. Only the first repairs something that was already being claimed.

Scope. Keel measures the shape of verification, not its quality. A repo can be 100% anchored with terrible tests. Anchoring says the signal comes from outside; it does not say the signal is sufficient.

Routes — 0 routable · 2 unroutable

Existing checks whose signal could come from somewhere they cannot write. Cheapest effort on top. no route is a first-class answer: it means the fix needs a policy decision rather than a rewiring, and it is reported here rather than dropped.

what's ungrounded	route to	why that's anchored	effort
package.json#build script · build today the signal comes from turbo, whose exit code is the maximum over ~70 per-package build commands (tsup/esbuild, vite build, next build, konsistent-convention emit, ...) unknown	no route	This edge asserts 'every one of the ~70 workspace packages produces its artifact from the committed source'. No candidate asserts that. The closest-looking one, packages/ai/vitest.config.js, does put a compiler in the path — its `typecheck: { enabled: true }` runs a real tsc pass whose verdict the authors cannot argue with — but it is scoped to the test surface of one package, packages/ai, while this node's claim ranges over the whole workspace including the tsup/esbuild children that never see a type checker. apps/docs/vercel.json is the same mismatch one level up: Vercel's builder genuinely decides whether apps/docs compiles, and says nothing about packages/*. update-model-settings.yml:64 asserts manifest/lock agreement, which is upstream of building and not a statement about build output at all. Pointing this node at any of them would let 'the monorepo builds' be scored on evidence that one package's tests type-check. why not: Two decisions are required first, and both are human. (1) What is this edge for: today its only pipeline caller is release.yml:122 on the snapshot-publish path, so it gates a publish rather than a merge — whether it should be a merge gate at all is a branch-protection decision. (2) What would have to be true for a green build to mean the tree is sound: the repository already runs a compiler over 69 project references at ci.yml:129 (`type-check:full` = tsc --build tsconfig.with-examples.json), but that edge is not a measured node in this report, so treating it as the producer behind this claim is an extraction-and-policy decision rather than a route between two nodes present here.	—
tools/konsistent-provider/package.json#build script · build today the signal comes from the `konsistent-convention` CLI from the third-party @konsistent/convention package, executing on the runner unknown	no route	The proposition this edge is trying to assert is 'the provider conventions declared in tools/konsistent-provider/src/index.ts hold' — that is what a red 'Code Consistency' job (ci.yml:62 -> turbo konsistent:validate/check -> dependsOn konsistent-provider#build) would be telling a reader. No candidate producer emits that proposition. The eight anchored producers in this report emit exactly three signals: pnpm's resolver reporting that pnpm-lock.yaml and the package.json manifests agree (update-model-settings.yml:64), Vercel's builder reporting that apps/docs compiles under next build, and six vitest/playwright runners reporting that the committed tests of packages/ai, react, vue, angular, codemod and rsc execute green. Each of those is genuinely outside the authors' write path, and each is about a different artifact than tools/konsistent-provider/src/index.ts — none of them executes the konsistent conventions, and none of them would change colour if the conventions were wrong. Wiring this node to read any of them would move the class without moving the claim. why not: This needs a policy decision about an opaque dependency, not a rewiring. The exit code is produced by `konsistent-convention emit` from @konsistent/convention ^1.0.0-beta, a caret-ranged pre-1.0 binary that is not vendored in the tree, so what the exit code MEANS is unreadable from this clone: it may validate the declared conventions or merely serialise them to dist/conventions.json. A human has to (a) pin and vendor or otherwise read that package to establish which, and then (b) decide, if it turns out to be pure generation, whether the required 'Code Consistency' gate should keep a step behind it that cannot fail on a real convention violation. Neither is a wire an agent can move.	—

what's ungrounded

route to

why that's anchored

effort

package.json#build

script · build

today the signal comes from turbo, whose exit code is the maximum over ~70 per-package build commands (tsup/esbuild, vite build, next build, konsistent-convention emit, ...)

unknown

no route

This edge asserts 'every one of the ~70 workspace packages produces its artifact from the committed source'. No candidate asserts that. The closest-looking one, packages/ai/vitest.config.js, does put a compiler in the path — its `typecheck: { enabled: true }` runs a real tsc pass whose verdict the authors cannot argue with — but it is scoped to the test surface of one package, packages/ai, while this node's claim ranges over the whole workspace including the tsup/esbuild children that never see a type checker. apps/docs/vercel.json is the same mismatch one level up: Vercel's builder genuinely decides whether apps/docs compiles, and says nothing about packages/*. update-model-settings.yml:64 asserts manifest/lock agreement, which is upstream of building and not a statement about build output at all. Pointing this node at any of them would let 'the monorepo builds' be scored on evidence that one package's tests type-check.

why not: Two decisions are required first, and both are human. (1) What is this edge for: today its only pipeline caller is release.yml:122 on the snapshot-publish path, so it gates a publish rather than a merge — whether it should be a merge gate at all is a branch-protection decision. (2) What would have to be true for a green build to mean the tree is sound: the repository already runs a compiler over 69 project references at ci.yml:129 (`type-check:full` = tsc --build tsconfig.with-examples.json), but that edge is not a measured node in this report, so treating it as the producer behind this claim is an extraction-and-policy decision rather than a route between two nodes present here.

—

tools/konsistent-provider/package.json#build

script · build

today the signal comes from the `konsistent-convention` CLI from the third-party @konsistent/convention package, executing on the runner

unknown

no route

The proposition this edge is trying to assert is 'the provider conventions declared in tools/konsistent-provider/src/index.ts hold' — that is what a red 'Code Consistency' job (ci.yml:62 -> turbo konsistent:validate/check -> dependsOn konsistent-provider#build) would be telling a reader. No candidate producer emits that proposition. The eight anchored producers in this report emit exactly three signals: pnpm's resolver reporting that pnpm-lock.yaml and the package.json manifests agree (update-model-settings.yml:64), Vercel's builder reporting that apps/docs compiles under next build, and six vitest/playwright runners reporting that the committed tests of packages/ai, react, vue, angular, codemod and rsc execute green. Each of those is genuinely outside the authors' write path, and each is about a different artifact than tools/konsistent-provider/src/index.ts — none of them executes the konsistent conventions, and none of them would change colour if the conventions were wrong. Wiring this node to read any of them would move the class without moving the claim.

why not: This needs a policy decision about an opaque dependency, not a rewiring. The exit code is produced by `konsistent-convention emit` from @konsistent/convention ^1.0.0-beta, a caret-ranged pre-1.0 binary that is not vendored in the tree, so what the exit code MEANS is unreadable from this clone: it may validate the declared conventions or merely serialise them to dist/conventions.json. A human has to (a) pin and vendor or otherwise read that package to establish which, and then (b) decide, if it turns out to be pure generation, whether the required 'Code Consistency' gate should keep a step behind it that cannot fail on a real convention violation. Neither is a wire an agent can move.

—

Construct — not yet.

A route makes a check read a signal from outside itself. It does not pair that check with a counter-metric, name who arbitrates when the pair disagrees, or set a cadence at which the route is re-audited. Those three fields are declared in schemas/route.ts and are filled by keel construct, which is not built. The columns are empty by construction, not by omission.

route	pairedWith	arbitratedBy	auditEvery
no routes on this run