Completion records presence. Proof-of-work records evidence.
Completion records participation. Proof-of-work can support a narrower, more useful claim: what a learner produced, the standard applied, and the provenance of the verdict.
The metric mismatch
Large-scale online learning has repeatedly shown that enrollment, attendance, and completion are different measures, with outcomes varying widely by audience and program design. The product mistake is to treat a progress bar as proof of capability. Streaks, badges, and videos watched can measure presence. They cannot, on their own, establish what someone can do.
Completion is not useless; it is simply too broad a claim. A learner who watches everything and builds nothing has completed content. A learner who produces inspectable work has created evidence. Those are different activities. Finishing a course is an input or participation metric. Reviewed work can become a capability signal, but only within the scope of the artifact, rubric, and recorded reviewer.
Quizzes test recall. Artifacts expose capability to review.
A conventional quiz asks whether you recognize the right answer when it is placed in front of you. Much of real work has a different shape: a blank file, an ambiguous brief, or a tool that fails at the wrong moment. Artifact-based verification can test work in that shape: produce the thing under constraints and let it be judged against a declared standard.
At the graph's authored evidence gates, progress requires an artifact — for example, a workflow, a constrained prompt system, or an agent design with contracts and evals attached. The artifact is concrete enough to inspect against its published rubric. That gives a hiring manager evidence to examine; it does not turn one submission into a hiring guarantee.
A representative synthetic brief illustrates the bar: extract structured data from messy inbound emails using a declared schema, ten test cases, and a failure log. The example is not presented as a learner result or live cohort assignment. Its value is testability: either the system survives the cases or it does not, and the failure log makes the operator's reasoning visible.
The review loop: rubric first, provenance always
The running review path can send a submission to a live model for scoring against a published rubric. When no live provider is reachable, the platform records an offline check but forces it to be non-verifying: it cannot close a graph node or mark the artifact verified. The evidence record states which path ran instead of blending them into one result.
Expert review is a separate review kind with separate provenance. The proposed service adds spot-checks for selected passes, borderline cases, and unusual submissions only after the founding roster has coverage. It is not an always-on layer today, and no learner record should imply otherwise.
The rubric is public before you submit. Gaming a published rubric is just meeting the standard. We'll take it.
When expert coverage is active, the spot-check is meant for exactly the submissions that look best at a glance: an artifact that hits every rubric line but solves the wrong problem, or a polished write-up wrapped around a system that does not run. A rubric sees structure. An expert can test whether the structure makes sense.
No LockedIn cohort has yet operated this review model as a live service, so this essay makes no claim about completion, hiring, or cohort outcomes.
Model review and expert review are different evidence. The record should say which one happened — and say plainly when neither can verify the work.
What a hiring manager can actually read
A verified portfolio entry can state what the person built, the standard applied, and the provenance of the qualifying review. The record distinguishes live-model verification from expert verification; verified does not automatically mean expert-reviewed. A hiring manager can inspect the artifact and rubric and decide whether the work resembles the work they need done. That is legible evidence within a defined scope — closer to a design portfolio or merged pull request than to an outcome guarantee.
The uncomfortable consequence
Real verification has to be able to say no. The platform implements verified and needs-work states and permits revision and resubmission, so a failed gate does not become a cosmetic completion. Feedback and a route back matter, but the verdict stays a no until qualifying evidence changes it. That friction is not a bug in the model; it is the source of the signal. A credential that cannot record failure is a receipt for participation, not evidence of skill.