Institution application
Register your school with yoklama.ai
The form is filled in by someone authorised to act on behalf of your institution. Once the application has been reviewed, your institution is created and a single-use administrator invitation link is sent to the designated contact. Teacher accounts are opened from your own admin dashboard after that.
The system is fully functional even with face verification completely disabled: proximity verification, the QR code and teacher-approved manual marking work on their own.
Technical setup
Eight steps
The flow below has been tested live and works end to end.
-
Submit an institution application
yoklama.ai runs as one installation, many institutions: a single server serves all schools. You do not need to set up a separate server for your institution. When your application is approved, your institution is created and an administrator invitation is sent to the designated contact; you reach the admin dashboard at /panel.
A separate installation on your institution's own server is not offered today. If you are an institution required by regulation to do so, say so on the application form — this is a decision that needs discussing, not a ready-made option.
No biometric data is stored on the server; at the schema level there is no column for a face template.
-
Create the institution and the first administrator
On the dashboard, “Run first-time setup” creates the institution record and the administrator account. This step only works while the system is empty; it cannot be used a second time.
-
Pick your university from the list
The system ships with reference data taken from the Higher Education Programme Atlas of the Turkish Council of Higher Education (YÖK): 228 universities, 3,011 faculties, 21,493 programme records and 634 distinct department names. You search for your own institution and select it; you do not type department names by hand.
Search folds Turkish characters: bogazici, Boğaziçi and BOGAZICI all return the same result.
-
Define classrooms and inter-building travel times
Every classroom belongs to a building. The institution defines, once, a building travel time matrix: how many minutes does it take to walk from building A to building B?
This matrix is the only data source for the “impossible travel” risk signal. The system collects no location data; the signal is derived from two attendance records contradicting each other. If the matrix is filled in incompletely, the signal turns into noise.
-
Enter the student information system addresses optional
In the SIS connection tab of the dashboard, four addresses are defined per university: the login page, the course list, the student list (CSV) and the attendance upload page.
There is no automatic discovery. You enter the addresses. There is no password field and there never will be — the server only knows which page is where.
To enable it, an institutional permission reference is mandatory (for example “Rectorate letter 2026/114”). Without a reference the system will not enable the connection.
You can skip this step entirely. CSV import is always available to everyone.
-
Open teacher accounts
There are two routes and both end in the same place — an invitation is generated:
Adding directly: you enter a name and an institutional email address on the dashboard, and an invitation link is generated.
Approving an application: the teacher applies through yoklama.ai/en/application; they appear on the dashboard in the “Pending applications” list. When you approve, an invitation is generated.
The invitation link is shown only once and is valid for 14 days. It is single-use.
-
Choose the policy
Policy values frozen when a session opens: the number of freshness channels required (2 or 3), the number of rounds, the attendance threshold (min_present, default 0.70) and the partial attendance threshold (default 0.40).
The attendance rule is deliberately not fixed: the Turkish Council of Higher Education's rules on distance education leave the attendance rule to faculty boards, so the institution sets the threshold.
-
Monitor attendance
The dashboard has live sessions, receipt verification and a reconciliation report. Reconciliation compares the number of receipts with the number of verifications: if there is a discrepancy, the loss is on your side and it is visible before the student files an appeal.
Administration
What an administrator can and cannot see
The raw risk signal history can be seen only by the institution administrator; a teacher cannot see it. Every read is written to the audit log and a reason field is mandatory.
This is not a formality: if it is not traceable who looked at profiling data and why, the system itself turns into a surveillance tool.
A teacher never sees a numeric risk score. A teacher who has seen the score no longer gives an independent “not in the room” answer, and the single ground truth the engine relies on is contaminated. The teacher only sees “confirm this person” and a short reason.
The proportion a teacher marks “present” by hand is reported per course. This is not a catching mechanism but a transparency mechanism: the teacher is the system's authorised actor and cannot be technically restricted.
There are two kinds of appeal: my attendance was not recorded (the student holds a receipt) and I object to a risk flag about me. In the second case the reviewing administrator sees the evidence for the signal; if they accept it, the signal drops out of evaluation and the same kind is suppressed for 30 days. An accepted appeal really does correct the attendance record, and the correction is written to the audit log.
Appeals against a risk flag are decided from the Risk engine tab on the dashboard. Attendance appeals are resolved from the teacher app — that decision belongs to the teacher of the course. Detail: features page.
Start of term
Setting up a whole term in a single upload
The eight steps above get the system running. Filling a term is a separate job, and it is not done by hand.
-
Prepare five files
Teachers, courses, the weekly timetable, students and course enrolments. The dashboard provides a template with the column headers for each.
-
Do a dry run first
The upload writes nothing by default. It first reports, line by line, which row would be rejected and why: a missing column, an unrecognised course code, a clashing timetable slot.
You do not have to move on to writing before the report is clean — and when you do, the upload is either applied in full or not at all. A half-loaded term is worse than a term that was never loaded.
-
Write, and repeat if needed
When the same file is uploaded a second time, the same row does not produce two records. Re-uploading a corrected file is safe.
Uploading a roster does not enable face verification. A bulk upload creates student records and course enrolments, and nothing else. For face verification to be usable, the student has to give consent separately on their own phone; this step cannot be skipped and cannot be given in bulk.
Monitoring
What you see during the term
Distribution of methods, manual-marking and paper ratios, average participation, number of appeals, number of teachers who have opened a session and the number of students who have never used the app. Per-course and per-teacher extracts are downloadable as CSV.
These reports never touch the risk tables. The possibility of a risk score being misread as an “attendance status” is thereby removed entirely.
When a student brings you a receipt number, you verify it from the dashboard. The reconciliation report compares the number of receipts with the number of verifications; if there is a discrepancy, the loss is on your side.
Days without teaching are defined at institution level: on those days no reminder is sent, no student comes in for nothing, and a class that never happened does not enter the absence calculation. A holiday does not have to be entered separately for every section — if one were forgotten, students in that course would be recorded absent.
It is defined from the Academic calendar tab on the dashboard. Public holidays do not come preloaded — each institution has to enter its own days.
Class cancellation and make-up classes are not dashboard work — they belong to the teacher app, because that decision belongs to the teacher of the course. The administrator's counterpart is the Academic calendar tab: you define a public holiday once at institution level instead of entering it for every section.
The full list, each item with its limit, is on the features page. That page was not shortened: saving for the last meeting what an institution will find out in the first deployment meeting helps nobody.
Before you apply: the product's limits
What has been designed and what has been measured are not the same thing:
We publish no accuracy figures. The accuracy of face verification and the spoof resistance of liveness detection have not been measured; that is why we give no success rate. Hardware attestation is verified, but nothing is done with the result: the attestation chain is verified up to the manufacturer's root certificate, yet proof that arrives unsigned or looks tampered with is not rejected — it is flagged. The default mode is permissive; moving to enforcing mode is a decision the institution makes after it knows its own device fleet. The risk engine runs in shadow mode: the rules run, the engine takes no action and changes no attendance result. Every limit, one by one: Features.
Form
Application
Your application has been received
Your application will be reviewed. If it is approved, your institution is created and a single-use administrator invitation link is sent to the email address you gave; you set your password from there.
The invitation is valid for 14 days.
An application does not create an institution
Until it is approved, no record, account or permission comes into existence. No one can open an institution on their own: whoever creates an institution administers all of that school's teacher and student accounts. That is why every application is reviewed by hand.
Process
From application to the first class
-
You fill in the form
If you are a university, you pick your institution from the list of the Turkish Council of Higher Education (YÖK). For high schools and other institutions we do not use a ready-made list — you type the name and add the Ministry of Education institution code if you have it; we verify by hand.
-
The application is reviewed
We check that the contact person represents the institution and that the institutional email domain belongs to it. The same domain is never given to two institutions.
-
Your institution is created
On approval the institution record is created and an administrator invitation link is sent to the contact person. From that moment your data belongs to your institution alone; no other institution's administrator can see it.
-
You invite the teachers yourself
From the admin dashboard you invite teachers, open courses and set your attendance policy. Teacher applications made with your institutional email domain land directly on your dashboard.
Frequently asked
Yes. yoklama.ai serves several schools from a single installation. Isolation is provided not at the database level but at the application level, by institution identity: every query is limited to your own institution and that boundary is bound by tests. We write the cost of this down plainly: one isolation bug affects not a single school but every school. If you would prefer to run it on your own server, the setup guide is in the setup section of this page.
No. The platform operator's role is limited to creating institutions, editing institution details and, if necessary, suspending an institution; its access to the student, attendance, risk and biometric endpoints is blocked on the server side, and that is pinned by a test.
No. Suspension only stops sign-ins; the records stay where they are. Deletion is a separate process that runs at your request.
Yes, the teacher application form is separate. If the domain of the institutional email address matches your institution, the application lands directly on your dashboard and you give the approval.
They take part with proximity verification or the QR code, at the same speed and with no extra step. Their attendance is exactly as valid.
Teacher-approved manual marking is always available. A reason is mandatory and is written to the audit log. No student is excluded from attendance.
Yes. The student's template is already on the device; verification can be done offline. Proofs accumulate on the teacher's device and are sent when the connection returns. Only the third channel (the server challenge) does not work offline — in that case the record passes with two channels and the student is not penalised.
Verification happens in parallel across the room: each student verifies on their own phone, so the duration of a round is not expected to grow linearly with class size.
This is a design expectation, not a measurement. Round duration has not been measured in any classroom; we do not know how long it takes in a crowded lecture hall and we are not giving a number.