Skip to content

Verification Log

Verification log appears under Reports in the menu, for a role that may see reports, in an organisation whose plan includes it.

Opened without the role, the page says Your role does not include the verification log. Opened on a plan without it, it says Your organization’s plan does not include the verification log.

Only the reading depends on the plan. The log is written for every business organisation from the start, so an organisation that moves to a plan with it sees the past year straight away.

Every verification that concerns the organisation, for the last year.

KindWhat one line means
CodewordTwo members of a connection compared their words. A match reads Confirmed, a mismatch Did not match. Both are recorded.
Guest codeSomebody checked one of the organisation’s guest codes, and the server saw it. When the owner recorded a check by hand, the line reads Reported by owner, because the server did not observe that check itself. A code used up earlier reads Already used.
StampThe same, for a provider stamp.
SealSomebody checked a seal made for the organisation.
BeaconSomebody checked a beacon the organisation publishes. The person who checked is not known.
Agent authorizationSomebody checked a signed authorisation that lets an agent act for a member.

A meeting check adds codeword lines of its own, and the What column says how the person was checked in: Words confirmed in a meeting check, QR code scanned in a meeting check, Marked present by organizer or Checked in by tap in a meeting check. The last two mean that no words were compared. See Connection Details.

Time is when the verification happened, not when it reached the server. A check made offline on a phone keeps its own time when it syncs later.

What is the kind, or the meeting-check method. Outcome is the result.

Verified by is the person who did the checking. Verified is the person who was checked. A person is named only while they are an active member of this organisation. Anyone else reads External user, and somebody on another server reads User on and that server’s name.

Name is the name of the code, where it has one. A seal shows no name: its title is encrypted with its text, and the server cannot read it.

Codeword period is the stretch of time in which the compared words were valid. It is filled for codeword lines only.

The page says so at its foot: Codewords are never shown. Only members of a connection can see them.

An administrator is not a member of the connections they oversee, and holds nothing that could produce their words. So the log does not keep the words in any form, clear, encrypted or hashed. It keeps the period instead. That tells you which words were in use without telling you what they were. Only a member’s device can work them out.

Three lists sit above the table: Kind, Outcome and Period. The period is the last 7, 30, 90 or 365 days, and 30 is the default.

Beside them, the page counts the verifications matched. The table shows fifty at a time, with Previous and Next below it.

With nothing in the period it says No verifications in this period.

A verification never fails because its copy for this log failed. If that happens, the verification still counts, and the page says how many in the period could not be logged.

A number there is not something you can repair from this page. Tell whoever runs your server.

One year. Beacon entries are kept for 90 days, which is how long a beacon keeps its own record.

This is separate from the retention of Activity, which records what administrators did, not who was verified.

Only business organisations have this log. Something a member does in their private context is never written to it. A seal made in the private context does not appear here either.