Kanan Journey — certification by doing
Grade a run inside your own product: which checkpoints they reached, how directly, how long it took, whether they recovered from their own mistakes — with anti-gaming signals that call a human rather than fail anyone.
- Evidence of real in-product behaviour, not recall
- Five independent signals, all computed on the server
- Automation and scripting are detected and referred to a person
- Capture only ever runs on the web, with consent, on domains you allowlist
Watching the work, not the answer sheet
A Journey asks whether someone can do the thing inside your product. You declare the checkpoints a competent run reaches; the server detects them from the observed event stream and grades five signals:
- Follow-through — the required checkpoints reached, weighted by importance.
- Path quality — how directly they got there.
- Time on task — active time with idle gaps excluded, against what the specification expects. Implausibly fast is penalised exactly as much as far too slow.
- Recovery — when something went wrong, did they fix it themselves?
- Anti-gaming — does this look like a person?
Anti-gaming calls a human, never a verdict
Automation markers, API-shaped events, machine-uniform timing and superhuman speed each raise a signal. A signal never fails anyone. It sends the run to a moderator, who decides — the same posture Miatz Kanan takes with proctoring flags.
Capture has four gates
1. the flag is on (it ships off),
2. the platform is web — the store apps declare no camera or microphone permission,
3. consent is on record,
4. the host is on your allowlist — an exact match or a real subdomain. A lookalike domain such as evilacme.com never passes for acme.com.
Nothing is client-decided
The client sends raw observed events. Checkpoint detection, the grade and the band are all computed on the server, and the grade is recomputed from everything recorded so far — so a partial or replayed batch cannot inflate a result.
Frequently asked
What is a checkpoint?
A step in your product that a competent run reaches — a record created, a rule configured, a result shared. You declare them in a journey specification, and the server detects them from the observed event stream. The client never tells us which checkpoints it hit.
What is actually graded?
Five things: follow-through (did they reach the required checkpoints, weighted by importance), path quality (how directly), time on task (active time with idle gaps excluded, compared to what the specification expects), recovery (did they fix their own mistakes), and an anti-gaming pass.
What happens if the run looks scripted?
Anti-gaming never fails anyone by itself. Automation markers in the browser, API-shaped events, machine-uniform timing between actions and superhuman speed each raise a signal — and any signal sends the run to a human moderator, who decides.
Where can capture run?
On the web, with the flag on, with consent recorded, and only from a host that exactly matches or is a genuine subdomain of one you allowlisted. A lookalike domain does not pass. The mobile apps never capture: they declare no camera or microphone permission.
Is any video or audio sent to this endpoint?
No. The ingest endpoint takes small JSON descriptions of observed steps. Recordings, when capture is ever enabled, live in a private evidence bucket reached through short-lived signed links.
Can a partial upload inflate a result?
No. The grade is recomputed from everything recorded for the run so far, not from the batch that just arrived, so replaying or trickling events changes nothing.
Related guides
Four deeper ways to establish that someone can actually do the work: an adaptive viva, in-product Journey runs, LTI launches from your LMS, and partner tiers that follow certified headcount.
ReadHow exams are monitored, what needs consent, and how a person reviews a flagged session.
Read