Observed
What the review directly established
Repository state, commands run, outputs returned, code paths inspected, demonstrations completed, and reproducible failures.
AI Code Reality Check / Public beta
Independent evidence for AI-built software.
Your coding agent says it’s done. I check what the evidence actually supports.
01 / Service
A second pair of eyes between “done” and trusted.
AI Code Reality Check is a focused independent review for people using Cursor, Claude Code, Codex, Lovable, Replit, and similar coding agents or app builders.
I inspect the relevant implementation and supplied evidence, run the checks that fit the agreed scope, and attempt at least one meaningful failure case where practical. The report states what was directly demonstrated, what the evidence reasonably suggests, and what still has not been established.
It answers one narrow question honestly. It does not turn a bounded result into a broad promise about an entire product.
02 / Deliverable
A report that separates fact from interpretation.
Inferred
What the evidence reasonably suggests
Conclusions supported by the observations, with the reasoning and material qualifications made explicit.
Unresolved
What remains outside the evidence
Untested environments, unavailable services, ambiguous behavior, missing access, and claims the bounded review cannot settle.
Also included: an overall verdict, material issues, review limits, and the smallest useful next actions.
03 / Portfolio sample #001
Passing tests were not the end of the check.
Disclosure: Nemoir is Thom’s own public project. This sample demonstrates the review process; it was not a paid client engagement.
Overall verdict
Substantially works with issues
The claim-relative decomposition path worked offline and had extensive test coverage. An additional consistency probe still exposed a structural gap.
- Repository
- FREQUENCITY15/Nemoir-public
- Audited commit
460034fe…b944a- Offline suite
- 443 passed
- Independent probe
- Unexpectedly accepted
Material finding
A source unit could point to the wrong Tendril while validation still returned valid=true.
The unit’s evidence existed in a different Tendril, so a global “evidence exists somewhere” check passed even though the stated unit-to-Tendril mapping was internally inconsistent. The supplied suite passed; the added counterexample found a case the suite did not cover.
The complete offline suite reported 443 passing tests at the audited commit. The synthetic, network-free decomposition workflow completed. A deliberately misrouted coverage entry was then accepted as valid.
The main feature is credible as an offline portfolio specimen, but the validator does not fully enforce the relationship its coverage map claims to represent.
Live-provider behavior, Discord behavior, production suitability, and semantic performance on unfamiliar conversations were outside this bounded review.
- Validate that each covered source unit is evidenced by its specifically named Tendril.
- Add the counterexample as a regression test.
- Rerun the targeted and complete offline suites.
04 / Boundaries
Small scope. Explicit limits.
Included in the beta
- One accessible repository
- One bounded feature or change, or one genuinely small project
- Relevant implementation and supplied evidence inspection
- Proportionate checks and an adversarial probe where practical
- A written evidence report and next actions
Not included
- Security audit
- Compliance assessment
- Production-readiness certification
- Deployment
- Repair or implementation work
If a request does not fit the beta, I will narrow or decline it before the review begins.
05 / Request a review
Bring one claim that matters.
Contact Thom through FREQUENCITY’s existing GitHub presence. Include the repository, the exact feature or change, the commit or branch, and the claim you want checked.
Contact Thom on GitHub