What the records establish across 15 repositories
A lot of my code from this period was written quickly, with heavy AI assistance, and most of it had green checks. I wanted to know what I could actually show for it. So I audited my own fifteen repositories the way I would audit someone else’s, asking four questions of each, each harder than the last:
- Did the checks pass on the exact version?
- Was that version accepted by someone with the authority to accept it?
- Can the published copy be traced, as a whole, to the source it came from?
- Did anyone other than me see it running?
What made a single verdict unhelpful
The answers fell away after the first question.
| Question | Yes | Out of |
|---|---|---|
| The checks on the exact candidate passed | 13 | 15 repositories |
| …and acceptance of that candidate was recorded | 1 | 15 repositories |
| The whole candidate was traced to its exact source | 0 | 15 repositories |
| A deployed surface was independently observed running | 0 | 25 published surfaces |
Thirteen green results would have read as a healthy estate. The checks were the easy part. The evidence that lets someone else trust the software (a recorded acceptance, an exact link from published copy to source, an independent sighting of it running) only exists if someone produces it on purpose, and mostly I hadn’t.
Read per repository, the drop is real rather than an artefact of separate totals. Operations, the one accepted repository, is one of the thirteen that passed:
The chapters take one question each:
- Passing checks and software acceptance are different findings: why 13 passes became 1 acceptance, and what Operations had that the others didn’t.
- One failed check and a 27-file provenance match: the one repository that shows the method catching both a failure and a positive result.
- Published code is not observed runtime: what an independent runtime observation would have taken.
- Findings and unanswered questions: the findings, and ten tempting claims the records rule out.
Four short notes define the terms the chapters rely on: candidate verification, engineering acceptance, evidence verification and lineage and provenance.
How the comparison was assembled
I started with three deliberately different repositories (Cohort 1): a private control, a multi-projection platform and a generated public projection with almost no history. The method was tested on those three, then applied to all 15 in-scope repositories, each with its own reviewed evidence package. An accepted evidence package means its collection was reviewed for this study. It does not mean the software was accepted or deployed.
Each question was collected separately: source identity, candidate checks, acceptance authority, publication relationships and runtime observations. Where the evidence was missing or contradictory, the record says so instead of filling the gap. The comparison and final tables are downstream views of that accepted evidence, not independent repeated measurements. Some projection observations have no stable identifier and stay unkeyed; the method reference covers those counting rules and the W0–W8 stages, and the tables page has the frozen values and a downloadable extract.
What this study can and cannot support
- Scope. The method was developed on the three Cohort 1 repositories. The fifteen-repository comparison is broader and descriptive; it does not extend every Cohort 1 conclusion to all fifteen.
- Zeros are gaps, not failures.
NOT_ESTABLISHEDmeans the evidence wasn’t in the frozen collection. It does not mean a system broke or never ran. - No activity metrics. Commit and issue counts are left out: their windows weren’t aligned, and they measure activity, not quality.
- AI is the motivation, not a finding. The comparison can’t say whether AI assistance caused any of these gaps; there’s no comparison period.
- Reproducible tables, private sources. You can reproduce the tables from the public extract, not the private repositories behind them.
Edge Evidence is a separate engineering project; this frozen study did not evaluate it. It is where I build the evidence this study kept finding missing (exact identities, readback before a copy counts, recorded refusals) into the system itself.
This is a historical schema-v1.1 comparison, not a current audit. Counts are copied from its locked final aggregate, not recomputed.
Where this note sits
On the timeline · 12 linked pages
Graph View
Completion and acceptance
- Candidate verificationboth ways
- Engineering acceptanceboth ways
Verification and provenance
- Evidence verificationlinks out
- Lineage and provenance — evidence bindingboth ways
From the projects
- One gap closed, one narrowedlinks here
Other notes
Projects
- Edge Evidenceboth ways
From Project 03
- One failed check and a 27-file provenance matchboth ways
- The 15-repository comparison: tables and methodboth ways
- Published code is not observed runtimeboth ways
- Passing checks and software acceptance are different findingsboth ways
- Findings and unanswered questionsboth ways
Linked from
- Candidate verificationlinks here
- Engineering acceptancelinks here
- Lineage and provenance — evidence bindinglinks here
- One gap closed, one narrowedlinks here
- Edge Evidence: how it was checked, and what's openlinks here
- Edge Evidencelinks here
- One failed check and a 27-file provenance matchlinks here
- The 15-repository comparison: tables and methodlinks here
- Published code is not observed runtimelinks here
- Passing checks and software acceptance are different findingslinks here
- Findings and unanswered questionslinks here
Connected work
- Carried forward into
- Edge Evidence — its method, carried into a working system · source
- Edge Evidence — its two questions, put afterwards to the hosted demo · source
- Threads
- Evidence honesty
Stated in the linked source unless marked as recollection. Connected work