# Operator Login and Analysis

Operator login is not the same as signing in to Kanoa. It records an operator **badging in** to the line they're working, and badging out when they go on break, finish their shift, or move to another line. These sessions are the raw presence data OLE is built from.

Badging into a new line automatically ends the operator's session on their previous line, so nobody appears to be working two lines because they forgot to badge out. A lead who really does cover two lines can be allowed multiple sessions.

:::warning[Badge in during the scheduled window]
Login time only counts inside the operator's shift assignment from the previous lesson. If you badge in outside it, for example at 8:00 PM against a 7:00 AM to 3:00 PM Day Shift, none of the time is counted and the operator leaderboard comes back empty. Before you start, check on **Ops → Scheduling → Crews** that Day Crew is assigned to a shift that covers now.
:::

:::action[Badge operators in and out]

1. Make sure Machine 1 is running in production, so there is runtime to measure against.
2. Navigate to **Ops → Operations → Operator Login**.
3. Badge `johnDoe` in to **Machine 1**.
4. Badge `marcoDiaz` in to **Machine 1** as well.
5. After about 10 minutes, badge `johnDoe` out.
6. Leave `marcoDiaz` logged in for another 20 minutes or so. Machine 1's simulator drops into downtime states at random, so some of that time the operator may be present while the machine isn't running.
7. Review the sessions table and confirm the login and logout times.

:::

Attendance compares these sessions with the crew's shift assignments from the previous lesson. Login time outside an operator's assigned window isn't counted, which is why the assignment should cover the time you're actually working. An operator with no assignment at all is measured against the whole report window instead.

You now have two people sharing one line for part of the time, one leaving early, and probably a stretch where someone was present but the machine wasn't running. Those are the situations OLE is designed to separate.

:::action[Read the Operators dashboard]

1. Navigate to **Ops → Analysis → Operators**.
2. Select **Machine 1**, today, and the **EvenSplit** attribution mode.
3. Read the KPI tiles for the whole line. Hover each one to see what it measures:
   - **Attendance** is well below 100%, because both operators were logged in for only part of their scheduled time, and `marcoDiaz` left early.
   - **Labor Gap** compares OLE and POLE for the line. The tiles divide POLE by the report window rather than by scheduled labor time, so if Machine 1 ran most of the day while your operators were logged in for only half an hour, Labor Gap goes negative and is labeled **Understaffed** (see the tip below).
4. Review the **Utilization breakdown** bars. Asset time and labor time are shown separately, because a line's runtime and the people's presence are independent.
5. In the **Operator leaderboard**, compare the two operators, ranked by POLE. For each operator, POLE is never higher than OLE. If Machine 1 went down while `johnDoe` was still logged in, their POLE is lower than their OLE: that difference is present-but-not-producing time.
6. Change the asset to the **Philadelphia** site. The same numbers roll up across every line beneath it, without scheduling anything again.
7. Click `operator` in the leaderboard to see their numbers broken down by each line they worked.

:::

| Attribution mode | How a shared line's output is credited | Use it for |
|---|---|---|
| **EvenSplit** (default) | Shared between everyone logged in at the same time | Normal crew work |
| **FullCredit** | Everyone logged in gets full credit | Training and shadowing |
| **PrimaryOnly** | Only the first person logged in gets performance and quality credit | One operator running the line with helpers |

:::tip[Reading the Labor Gap]
At the line or site level, Labor Gap can go **negative**. That means the line kept running near its normal rate even though fewer scheduled people showed up: understaffed, but holding for now. It's an early warning, and the dashboard labels it **Understaffed** rather than **Present, not producing**.
:::

:::check

Run this in the Script Console. It lists today's sessions on Machine 1, checks each operator's login time against their shift assignment, then prints the leaderboard. If the leaderboard is empty, the FAIL lines above it say why.
<details>
<summary>Show the check script</summary>

::check-script{src="ops/11-operator-effectiveness/2-operator-login-and-analysis.py" title="operatorLeaderboard.py"}
</details>
:::

If OLE and POLE come back as `0` while attendance looks right, check that Machine 1 has a standard rate for the item it's running. Performance, and so OLE and POLE, can't be calculated without one.
