# Work Instruction (WI) — Detailed Functionality & Feature List

**Purpose:** an exhaustive, code-grounded inventory of every WI capability, data element, and
cross-module touchpoint — deliberately more granular/checklist-style than
`Docs/WorkInstruction-Feature-Functionality-Guide.md` (the narrative version). Use this as raw
material when building audience-specific documents (dev spec, implementation/config guide, admin
manual, end-user help, marketing/sales collateral) in other tools. Grounded in
`GB5Solution/WorkInstruction` (backend) and `gb4.7mfe/projects/workinstruction` (frontend) as of
2026-08-20.

**How to read this document:** §1 is the feature inventory by area. §2 is the cross-module
integration map (what WI genuinely depends on vs. what's declared-but-unused). §3 is roles/personas.
§4 is the setup/go-live sequence. §5 is day-to-day operating cycles. §6 is the non-production
adaptability case. §7 is a raw glossary of every enum/status code, useful for building picklists,
help text, or training material without re-deriving them from source.

---

## 1. Feature Inventory by Area

### 1.1 Work Instruction Authoring
- Entity hierarchy: **Process → Sub-Process → Work Instruction → Section → Step → Step Content**.
- Work Instruction header fields: code, title, activity type, activity sub-type, version string,
  status, display context, step-advance mode, standard cycle time (minutes), effective date, review
  due date, approver, tags, free-text description, active flag.
- **Step** fields: display number (independent of sequence number — e.g. "1a", "2b"), title, warning
  level (None/Caution/Warning/Danger), standard duration, tools-required list (JSON), optional flag,
  require-sign-off flag, auto-advance seconds, active flag.
- **Step Content** — one or more content blocks per step, each with:
  - **Content Type**: Rich Text, Image, Video, PDF, Checklist, Warning, Decision Branch, File, QR
    Code, Data Table.
  - **Content Source** tag: Inline, CMS, File Store, External URL (see §2.3 — CMS is a
    classification tag today, not a live pull from the CMS module).
  - **Layout placement**: which of 5 container types the block renders in (Single, Two-Column,
    Banner, Accordion, Tab), which zone within that container, and its position within the zone.
  - **Checklist blocks** specifically: a list of checklist items, each with a label and an optional
    mandatory flag; responses are captured per employee per step (current-state only — no
    versioned history of checklist responses, unlike the WI itself).
- **Governance workflow**: Draft → In Review → Approved → Published → Archived. Illegal transitions
  are rejected in code (e.g., cannot publish from Draft). Every transition snapshots the complete WI
  state (header + sections + steps + content) as a permanent version record — this history can never
  be deleted, by design.
- **Version Compare** — side-by-side diff between any two version snapshots of the same WI.
- **Version log** — who transitioned the WI, from which status to which, and when, for every
  transition ever made.

### 1.2 Workstation & Line Master Data
- **Workstation**: code, name, bay code, floor description, workstation type, max operators.
- **Workstation Config** (one row per workstation, unique per tenant): display mode (Single Screen /
  Twin Monitor / Tablet / Kiosk), step-advance mode (Manual / Barcode Scan / Timer Auto / Spacebar /
  Configurable), auto-advance seconds, font scale (Normal / Large / XLarge), show-step-timer flag,
  show-cycle-timer flag, require-acknowledgement-per-unit flag, connected work-order data-feed
  reference, remarks. **As of 2026-08-20 the Workstation Display Screen actually reads and applies
  this config** (display mode → layout class, font scale → text sizing, the two show-timer flags →
  conditional rendering) — previously fully configurable but silently ignored.
- **Production Line**: code, name, description.
- **Line–Station Map** (`MPRODUCTIONLINESTATION`): which workstations belong to a line and in what
  sequence (`PositionNo`, "1 = first station"), effective-dated (open row = currently active). This
  is the literal spatial/process layout the Line Digital Twin renders as an ordered flow-strip.
- **Line–Operation Map** (`MLINEOPERATIONMAP`): maps a routing operation/step to a workstation on a
  line, effective-dated, with a manpower-count expectation — the basis for staffing-gap detection.

### 1.3 Skill/Competency Requirements & Eligibility
- **Skill Requirement**: attach a Skill Management skill + minimum proficiency level + enforcement
  level (Log / Warn / Block) + mandatory flag + remarks to a Work Instruction.
- **Competency Requirement**: same shape, for a Skill Management "competency" instead of a skill —
  **exists as a configuration field only; always evaluates as "Unverifiable"** because no
  employee-competency data source exists anywhere in the system (see §2.1).
- **Eligibility Evaluation** (query-only, no side effects): given an employee + WI, returns per-
  requirement Met / NotMet / Unverifiable, and an overall `IsEligible` that is `false` only if a
  Block-level Skill requirement is NotMet (Warn/Log-level gaps never block, only inform).
- **Enforcement semantics**:
  - `Log` — gap is recorded/visible but never surfaced as a blocker.
  - `Warn` — gap is surfaced to the operator/supervisor but execution still proceeds.
  - `Block` — execution is refused outright at start, with the specific missing skill(s) named.

### 1.4 Assignment Resolution
- A Work Instruction is attached to an **assignment** row carrying up to 7 matchable dimensions:
  workstation, work center, routing, routing operation, model, item group, and entity
  type+id (a generic fallback dimension). Any dimension can be a wildcard (`-1`).
- **Specificity scoring**: when multiple assignments could match the same real-world context, the
  one with the most non-wildcard (exact) dimensions wins — reproducible, inspectable (the FE's
  "Why this WI?" panel shows exactly which dimensions matched vs. wildcarded, and the weight of each).
- **Resolution entry points**:
  - `ResolveForWorkstation` — given a workstation (+ optional work center/routing/model/item-group
    context) + a trigger event, return the winning assignment or a reason code for zero matches
    (`NoAssignmentExistsForEntity`, `NoScheduleForTriggerEvent`, `OutsideEffectiveDateWindow`).
  - `ResolveForEntity` — same resolution, keyed by a generic entity type + id instead of a
    workstation (the more generic form; historically under-used by the FE until the unified
    scan-verify work wired it up for `WI:` scans).
- **Trigger events**: JobStart, PerUnit, BatchStart, JobEnd, EveryNUnits, EveryNHours,
  ModelChangeover, FirstUnitOfBatch, OnDemand, Manual.

### 1.5 Acknowledgement
- An employee can be required to acknowledge (confirm they've read/understood) a specific WI version
  before executing it, tied to a work order (or none, for non-work-order-linked WIs).
- Acknowledgements are invalidated en masse whenever the WI transitions to a new published version —
  an old acknowledgement never silently covers a newer revision.
- `CheckAcknowledgement` returns the most recent valid acknowledgement for an employee+WI+work-order
  triple, or none.

### 1.6 Execution
- **Start Execution** — a numbered gate sequence, all-or-nothing:
  1. If a work order is supplied, it must be a real, existing work-order-detail row.
  2. A valid acknowledgement must exist.
  3. No unmet Block-level skill requirement (execution refused, naming the missing skill(s), if any
     exist).
  4. Only then: an execution record is created, and one Pending step-execution row is seeded for
     every active step of the WI (so step completion is trackable from second one, never inferred
     after the fact).
- **Execution status**: InProgress / Completed / Abandoned / FlaggedIssue.
- **Step status**: Pending / InProgress / Completed / Skipped / Flagged.
- **Complete Step** — updates a step-execution row's status, actual duration, advance-trigger method
  used, optional barcode scanned, optional skip reason, remarks.
- **Complete Execution** — marks the whole run Completed with a total actual duration.
- **Step-execution history** — every step-execution row for a run, browsable.
- **Activity types tracked per execution**: Cycle, Setup, Teardown, Cleaning, Inspection,
  FirstArticle, FirstLot, Preventive Maintenance, Corrective Maintenance, Safety, Changeover,
  Rework — the same execution/acknowledgement/eligibility machinery applies regardless of which of
  these an execution represents, not just "normal production cycle" work.
- **As of 2026-08-20, execution status changes push live** to any open Line Digital Twin/Plant
  Overview/Workstation Display Screen watching that workstation/line (SignalR — see §1.11).

### 1.7 Roster & Shift Staffing
- **Line Shift Roster**: one header per line+date+shift, typed Planned or Actual, statused
  Draft/Confirmed/Closed. A Planned roster can never be directly confirmed — only an Actual roster
  can (prevents a forecast being mistaken for a locked-in schedule).
- **Copy-Forward**: clone the most recent Planned roster for the same line+shift into a new date,
  including its staffing rows, with absence flags/reasons/replacements reset (a fresh day starts
  clean, not carrying yesterday's exceptions forward).
- **Line Shift Staffing**: assign an employee to a workstation for a roster, with a staffing role, a
  primary/secondary flag, and planned start/end time. Guardrail: only one primary, non-absent
  operator per workstation per roster.
- **Mark Absent**: staffing rows are never deleted (an append-only attendance record) — marking
  absent sets a flag + reason + optional replacement employee, in one action.
- **Planned vs. Actual report**: line+date+shift comparison between the planned and actual roster,
  keyed against the planned in-charge employee.
- **As of 2026-08-20, a staffing save/absence-mark pushes live** to any open Digital Twin/Plant
  Overview watching that line.

### 1.8 Line Production Plan Allocation
- Links a production-plan detail line (item + quantity + date range, from the MM/Production module)
  to a specific production line, shift, date, and — optionally — a specific workstation and a time
  window within the shift (start/end minutes). Omitting workstation/time window means "the whole
  line, the whole shift."
- This is the lighter-weight, plan-driven alternative to full work-order generation — a line
  supervisor can allocate a plan line to a shift without waiting for a formal work order to exist.
- **As of 2026-08-20, an allocation save/delete pushes live** to any open Digital Twin/Plant Overview
  watching that line.

### 1.9 Skill Gap for Roster (readiness report)
- For a given line+date+shift, unions two sources of "what's planned to run here": explicit
  allocation rows (§1.8) and real MM work orders active on the line's work centers whose item isn't
  already covered by an allocation.
- For each planned item, resolves the applicable WI (§1.4), then unions two sources of "who's
  actually here": the roster/staffing rows (§1.7) filtered to the item's workstation (or the whole
  line if unallocated to a specific station), and — for work-order-sourced items — the MM
  work-order's own planned resource list.
- For every resulting employee, evaluates their skill level against every skill requirement of the
  resolved WI, tagging each employee row with **how** they were resolved (`ResolvedVia`:
  Allocation/WorkOrder) and **where** they came from (`EmployeeSource`: Roster/IndentResource) —
  transparency is the point of this report, not a hidden implementation detail.

### 1.10 Line Digital Twin & Plant Overview
- **Plant Overview**: one summary card per production line for the tenant, for a selected date+
  shift — total stations, occupied vs. idle count, total employees, employees with a skill gap.
  Tenant-scoped (a genuine, newly-added tenant filter — the pre-existing line list/select-list
  queries elsewhere in this module are not tenant-filtered, a known pre-existing gap, see §2.4).
- **Line Digital Twin (detail)**: the same line's workstations rendered in `PositionNo` order as a
  left-to-right process-flow strip. Each station tile shows: code/name, live execution status (a
  pulsing "live" indicator + current step title if an execution is InProgress there, "Idle"
  otherwise), and every employee assigned there with their item/WI and a skill-gap chip strip
  (Met/Gap/NoProfile per skill, expandable to full detail).
- Both screens share one component with two view-states (overview ↔ detail), not two separate menu
  entries.
- **As of 2026-08-20, both are genuinely push-updated** (§1.6/§1.7/§1.8 trigger points), not just
  poll-on-open.

### 1.11 Real-Time Push (SignalR)
- One hub, `/hubs/wi`, three event types: execution status changed (workstation-scoped), staffing
  changed (line-scoped), allocation changed (line-scoped). Clients join a `wi:line:{id}` or
  `wi:workstation:{id}` group and get pinged — the FE then re-fetches its normal data, so the pushed
  payload is intentionally minimal (a "something changed here, refetch" signal, not a data carrier)
  and can never drift out of sync with what a real reload computes.
- Consumed by: Line Digital Twin/Plant Overview (join a line's group on entering detail view),
  Workstation Display Screen (join its own workstation's group).
- Deliberately **not** wired into scan-code generation screens — generating a QR code is a one-shot
  action, not a live dashboard.
- Transport: LongPolling forced (this codebase's custom `Login`-header auth model doesn't survive a
  WebSocket handshake in-browser) — same constraint and same fix as CollabSpace elsewhere in GB5.

### 1.12 Scan-Code Generation & Verification
- **Generation**: any Work Instruction, Workstation, Employee, or Work-Order-Detail can produce a
  scannable QR code encoding a plain `"{Prefix}:{EntityId}"` string (`WI:`, `WS:`, `EMP:`, `WOD:`).
  Generation always re-checks the target entity exists for the caller's tenant first — a code is
  never handed out for a nonexistent or cross-tenant entity.
- **Unified verification** (`VerifyScan`, added 2026-08-20): one endpoint parses the prefix and
  dispatches:
  - `WS:` → does a WI assignment resolve for this workstation right now (reuses §1.4).
  - `EMP:` → does this employee have a current roster/staffing assignment today (reuses §1.7).
  - `WI:` → does this WI exist **and is it Published** (Draft/Approved/Archived scans are correctly
    flagged invalid — a WI id existing is not the same as it being live).
  - `WOD:` → does this work-order-detail exist for this tenant **and is its parent work order still
    open** (not cancelled/closed).
  - All four return one uniform shape: `{IsValid, EntityType, EntityId, Message, Data}`.
- All four scan surfaces support live camera scan or hardware barcode-scanner input (keyboard-wedge),
  not just manual ID entry or QR display.

### 1.13 Analytics
- **Compliance Summary** (per WI, or all): total operators, acknowledged count, compliance rate,
  completed/abandoned/flagged run counts, over a date range.
- **Execution History** (filterable by WI/workstation/employee/date range): raw execution rows —
  who, where, when started/completed, status, actual duration vs. standard cycle time.
- **Time Study Summary** (per WI, required — no "all WIs" mode): per step, standard duration vs.
  execution count, average/min/max actual duration — the "is this step really taking as long as
  designed" view.
- A dedicated **WI Analytics** screen (added 2026-08-20) renders all three: a compliance-rate chart
  + tiles, a Std/Avg/Max grouped bar chart per step, and a plain execution-history table. No
  server-side paging on any of the three endpoints today — fine for typical ranges, a caveat for
  very wide date ranges on Execution History.

---

## 2. Cross-Module Integration Map

WI is architecturally self-contained (own `WiSL`/`WiBLL`/`WiDAL`, own frontend project) but reads
several other modules' data directly at the table level — **no outbound API calls from WI into any
other module's service layer, ever**. This section is the honest inventory of what's real vs.
declared-but-dormant.

### 2.1 Skill Management (`SkillManagementSL/BLL/DAL`) — real, load-bearing
- WI queries `MEMPLOYEESKILLPROFILE`/`MSKILL`/`MSKILLLEVEL` etc. directly (same tables, no API call)
  for eligibility evaluation (§1.3) and skill-gap computation (§1.9).
- **Competency** side of this integration is dormant: `MWICOMPETENCYREQUIREMENT` has a config UI and
  a data model, but no employee-competency profile table exists anywhere in the system (not even in
  the dedicated CompetencyMgmt module) — so it can never evaluate as anything but "Unverifiable."
  Do not build client expectations around Competency Requirements gating anything.
- Schema-change risk: any change to the employee-skill table shapes must be coordinated across both
  codebases manually — there's no compile-time dependency forcing it.

### 2.2 Production / MM Module (`MMSL/BLL/DAL`) — real, load-bearing
- **Work orders**: `TINDENT`/`TINDENTDETAIL` are MM's tables; WI's "work-order-detail" scan type and
  the skill-gap report's `IndentResource` employee source both read them directly. `WOD:` scan
  verification checks `TINDENT.STATUS` for open/cancelled.
- **Production plans**: `TPRODUCTIONPLAN`/`TPRODUCTIONPLANDETAIL` feed the Line Production Plan
  Allocation flow (§1.8) — an item+quantity+date-range plan line, allocated to a line/shift/
  workstation without needing a formal work order first.
- **Item/model master**: `MITEM`, item-group, model — used as assignment-resolution dimensions
  (§1.4) and for display (item name on skill-gap/digital-twin screens).
- **Shared master data**: `MORGANIZATIONUNIT` (tenant resolution — several WI/production tables have
  no `TENANTID` column of their own and reach it via an OU join), `MWORKCENTER`, routing/routing-
  detail tables.

### 2.3 CMS Module (`CMS`/`TCMS`) — declared, not actually integrated
- Step content has a `ContentSource` field that can be tagged `CMS` (vs. Inline/FileStore/
  ExternalURL) — but this is a classification byte on the row, not a live join or query into the
  real CMS module's tables. `ContentRef` holds whatever reference string was entered regardless of
  the tag. **Do not describe this as "pulls content from the CMS" in any customer-facing material**
  — today it's "you can label a content block as CMS-sourced," nothing more.

### 2.4 HR / Attendance (`PayRoll` module, which is this codebase's HR/attendance/payroll system) —
real but shallow
- `MEMPLOYEE` (employee identity master) is owned and maintained by the PayRoll module; WI reads it
  directly wherever an employee needs a name/identity (roster staffing, scan verification, execution
  records) — the same read-only cross-module pattern as Skill Management.
- **No deeper integration exists**: WI does not check actual attendance/clock-in records before
  allowing execution, and nothing in WI writes to or reads from payroll data. "HR/Attendance
  integration" in WI today means exactly "we know who this employee is," not "we know if they clocked
  in" or "this feeds timesheets."

### 2.5 Known pre-existing tenant-isolation gap (flag, not fixed)
- Several pre-existing WI/MM queries (e.g. the plain production-line select-list/list queries) accept
  a `TenantId` parameter but never actually filter by it in their `WHERE` clause. The newer
  Plant-Overview line list (§1.10) was deliberately built with a real tenant filter rather than
  reusing those queries. Worth a dedicated audit before any multi-tenant go-live that relies on line
  master data being tenant-isolated.

---

## 3. Roles & Personas

| Persona | What they do in WI |
|---|---|
| **WI Author / Quality** | Authors the full process→step→content hierarchy; moves WIs through Draft→Review→Approve→Publish; uses Version Compare to audit changes; defines skill/competency requirements and their enforcement level. |
| **Implementer / Admin** | Configures Workstation/Workstation Config/Production Line/Line-Station Map; sets enforcement levels per client risk appetite; seeds menu access (`MMENU`/`MWEBFORM`/`MROLEVSMENU`) for every screen a client needs to reach; coordinates with Skill Management setup as a prerequisite. |
| **Line Supervisor / Team Lead** | Plans and confirms rosters; assigns staffing; marks absences/replacements; allocates production-plan lines to shifts; checks the Skill Gap for Roster report before a shift starts; watches the Line Digital Twin during the shift. |
| **Plant / Operations Leadership** | Uses Plant Overview for a site-wide readiness view; uses Compliance/Execution-History/Time-Study analytics for adoption and process-performance monitoring. |
| **Operator / Worker** | Scans in at a workstation or via badge; acknowledges the assigned WI; is stopped or warned at execution start based on skill eligibility; steps through the WI with checklist responses; scans a work-order/WI/workstation code to verify identity/validity at any point. |

---

## 4. Setup & Go-Live Sequence

1. **Skill Management prerequisite**: skill taxonomy, role/job skill requirements, and employee
   skill profiles must exist *before* WI enforcement rules are configured — an eligibility check
   against empty skill data simply finds nothing, not an error, so this fails silently if skipped.
2. **Master data**: Workstations → Workstation Config (display mode/font scale/timers per device
   type actually in use) → Production Lines → Line–Station Map (the physical/process sequence) →
   Line–Operation Map (which operation runs at which station).
3. **WI authoring**: build the process/sub-process/section/step/content hierarchy; attach skill
   requirements with a deliberately-chosen enforcement level per requirement (see the Block-vs-Warn/
   Log guidance in the companion Feature Guide §4); move through governance to Published (only a
   Published WI is a valid scan-verify target, §1.12).
4. **Assignment**: create the assignment row(s) resolving a WI to the right workstation/work-center/
   routing/model/item-group combination, including any wildcard dimensions needed for a
   catch-all/default assignment.
5. **Roster/staffing setup**: create the first roster (Planned, then confirm as Actual per shift),
   staff workstations, and — if using plan-driven allocation instead of/alongside formal work
   orders — allocate production-plan lines to shifts.
6. **Menu wiring** (mandatory, not optional): every screen the client needs to reach requires a real
   `MMENU`/`MWEBFORM` row (and a Roles & Rights grant) — confirm this for every feature promised in a
   demo or go-live, not just the ones that happen to have been wired by a previous rollout.
7. **Go-live smoke test**: scan-verify a real workstation/employee/WI/work-order-detail of each type;
   confirm a real Block-level skill gap actually stops execution; confirm the Digital Twin/Plant
   Overview render and push-update on a live staffing/execution change; pull each of the 3 analytics
   reports for a real date range.

---

## 5. Day-to-Day Operating Cycles

**Creator / Author cycle** (as-needed, not daily): draft a new WI or a new version of an existing
one → attach/adjust skill requirements → move through review/approval → publish → (if replacing a
prior version) acknowledgements against the old version are invalidated automatically.

**Supervisor / Manager cycle** (once per shift, typically): confirm or copy-forward today's roster →
staff workstations → mark any absences and name replacements → check Skill Gap for Roster before the
shift starts (catch a gap before it becomes a Block-level stoppage on the floor) → watch the Line
Digital Twin during the shift for live coverage/status → review Compliance/Time-Study analytics
periodically (weekly/monthly cadence, not per-shift).

**Worker / Operator cycle** (per work session): scan in at the workstation (or badge-scan for
identity) → the resolved WI's acknowledgement gate, if any → attempt to start execution (stopped
outright on a Block-level skill gap, warned but allowed on Warn/Log) → step through the WI, completing
checklist items as required → complete the run. Scan-verify is available at any of these points to
confirm identity/validity before proceeding.

**Leadership cycle** (periodic, not daily): Plant Overview for a same-day snapshot; Compliance/
Execution-History/Time-Study analytics for trend review.

---

## 6. Beyond Production — Sector Adaptability

Nothing in WI's data model or execution logic is manufacturing-specific by construction — "Work
Instruction," "Workstation," "Production Line," and "Work Order" are the production-domain *names*
for what are actually generic concepts: **a governed procedure, a place/context it's executed in, a
grouping of related contexts, and a unit of work that triggers it.** The same engine maps cleanly
onto non-production settings:

| Production concept | Field-service equivalent | Call-center equivalent | Software/IT-ops equivalent |
|---|---|---|---|
| Work Instruction | Service/repair procedure | Call script / compliance checklist | Runbook / incident procedure / onboarding checklist |
| Workstation | Service van / site / bench | Agent desk / queue | On-call engineer's role, or a specific environment |
| Production Line | Service team / region | Campaign / department | Team / squad |
| Work Order | Service ticket | Call / case | Incident / deployment / ticket |
| Skill Requirement | Certification (e.g. electrical, refrigerant handling) | Language/product-line qualification | Access level / technology certification |
| Roster & Staffing | On-call/shift roster | Agent shift schedule | On-call rotation |
| Execution + Acknowledgement | Proof-of-service checklist, signed off | Call disposition + compliance script confirmation | Incident runbook step completion, post-mortem checklist |
| Scan-code verify | Asset/equipment QR at a site | N/A (or badge-in at a desk) | Environment/host tag scan for a physical-access step |
| Digital Twin / Plant Overview | Live field-team coverage map | Live queue/agent coverage board | Live on-call/incident-board view |

What carries over directly, with zero code change, for any of these sectors: the full governance
workflow (Draft→Review→Approve→Publish→Archive) and version history; the Block/Warn/Log enforcement
model (e.g., a "PCI compliance script" step could `Block` an agent without the right certification
from proceeding on a payment call); the specificity-based assignment resolution (e.g., "which
runbook applies" resolved by environment + incident-type + team, the same mechanism as workstation +
work-center + model); and the scan-verify/analytics/roster layers, which are all keyed on generic
IDs and enforcement/status enums, not on anything shop-floor-specific.

What would need new UI language (not new backend logic) to feel native outside production: renaming
"Workstation"/"Production Line"/"Work Order" in the FE labels per client vertical, and possibly a
different Workstation-Display-Screen layout for a desk/on-call context vs. a shop-floor kiosk — the
`DisplayMode` config (§1.2) already anticipates more than one physical form factor.

---

## 7. Glossary — Enums & Status Codes

| Enum | Values |
|---|---|
| `WiStatus` | Draft=0, InReview=1, Approved=2, Published=3, Archived=4 |
| `Enforcement` | Log=0, Warn=1, Block=2 |
| `ExecStatus` | InProgress=0, Completed=1, Abandoned=2, FlaggedIssue=3 |
| `StepStatus` | Pending=0, InProgress=1, Completed=2, Skipped=3, Flagged=4 |
| `StepAdvanceMode` | Manual=0, BarcodeScan=1, TimerAuto=2, Spacebar=3, Configurable=4 |
| `DisplayMode` | SingleScreen=0, TwinMonitor=1, Tablet=2, Kiosk=3 |
| `FontScale` | Normal=0, Large=1, XLarge=2 |
| `ContentType` | RichText=0, Image=1, Video=2, PDF=3, Checklist=4, Warning=5, DecisionBranch=6, File=7, QRCode=8, DataTable=9 |
| `ContentSource` | Inline=0, CMS=1, FileStore=2, ExternalURL=3 |
| `WiContainerType` | Single=0, TwoColumn=1, Banner=2, Accordion=3, Tab=4 |
| `WarningLevel` | None=0, Caution=1, Warning=2, Danger=3 |
| `TriggerEvent` | JobStart=0, PerUnit=1, BatchStart=2, JobEnd=3, EveryNUnits=4, EveryNHours=5, ModelChangeover=6, FirstUnitOfBatch=7, OnDemand=8, Manual=9 |
| `ActivityType` | Cycle=0, Setup=1, Teardown=2, Cleaning=3, Inspection=4, FirstArticle=5, FirstLot=6, PreventiveMaintenance=7, CorrectiveMaintenance=8, Safety=9, Changeover=10, Rework=11 |
| `EligibilityStatus` | Met, NotMet, Unverifiable |
| `WiResolveReasonCode` | NoAssignmentExistsForEntity, NoScheduleForTriggerEvent, OutsideEffectiveDateWindow |
| Scan prefixes | `WS:` Workstation, `EMP:` Employee, `WI:` Work Instruction, `WOD:` Work Order Detail |

---

*Companion to `Docs/WorkInstruction-Feature-Functionality-Guide.md` (narrative version, audience-
sectioned) — this document is the exhaustive inventory version. Both are grounded in the same
2026-08-20 code audit; re-verify against current code/DB state before relying on either in a live
client conversation, especially the enum tables in §7 which are copied verbatim from source and will
drift if the backend enums change.*