User Manual
Kalman FAT Suite — Workflow and User Manual
A practical guide to project setup, roles, multi-phase sessions, independent participant decisions and controlled FAT/SAT execution.
Kalman FAT Suite organizes industrial acceptance testing without forcing several people to share and overwrite one decision. The permanent project hierarchy and each phase-specific test session are kept separate.
The core hierarchy is Project → Test Area → Test Package → Test Item. A session adds the testing context: phase, lifecycle state, assigned participants and each participant's independent response.
This manual describes the current product behavior. Where participant reporting is still separate from the established PDF workflow, that limitation is stated explicitly.
End-to-end workflow
- Create a blank project, use the demonstration project, or download and import the Excel template.
- Open Project settings to verify project information, report settings, reference documents and the permanent test hierarchy.
- Open Access management and invite project members by email. Assign Owner, Admin, Tester or Viewer according to responsibility.
- Under Test execution, create a draft phase session. Choose Internal, Pre-FAT, FAT, SAT, Punch Retest, Final Acceptance or Custom; then select participants and required responders.
- Review the draft participant list and open the session. Participant membership can be changed only while the session is Draft.
- Open a test item. Every assigned participant records their own status and comment. Status saves immediately; comments save automatically after a short pause.
- Use the item summary to find Passed, Rejected, Blocked and Pending responses. Resolve differences through the project's agreed review process; never edit another person's response.
- Close the session when the phase review is complete. Closed responses are read-only; archive the session when it no longer needs to remain active.
- Review Results & records and the established report. Confirm the shared legacy/consolidated item result separately before issuing the current PDF.
Project and testing structure
| Project | The durable project container for scope, members, references, report settings and all test phases. |
|---|---|
| Test Area | A major plant, system or discipline grouping. |
| Test Package | A manageable group of related checks inside an area. |
| Test Item | The individual IO, HMI, alarm, sequence, communication, cabinet, cybersecurity or document check. |
| Phase Session | A controlled round of testing with its own phase, participants, lifecycle and responses. |
| Participant Response | One person's decision for one test item in one session. It is stored independently from every other participant and from the shared legacy result. |
Phases and session lifecycle
| Phase types | Internal, Pre-FAT, FAT, SAT, Punch Retest, Final Acceptance and Custom describe why and when the session is performed. |
|---|---|
| Draft | Owner/Admin prepares the name, phase and participant list. Responses are not accepted. |
| Open | Assigned participants can submit their own responses. The participant list is locked. |
| Closed | The review is finished and all responses are read-only. A closed session cannot be reopened. |
| Archived | The session remains in project history but is no longer active. Lifecycle moves forward: Draft → Open → Closed → Archived; Draft may also be archived. |
Phase-specific access
| Project role | The permanent Owner, Admin, Tester or Viewer role controls project settings, hierarchy, imports, members and general project access. It does not automatically decide a person's role in every phase. |
|---|---|
| Phase Admin | Manages the selected phase, its Draft access list and lifecycle, and can also save their own independent response. A Phase Admin does not gain permanent project-administration rights. |
| Phase Tester | Can open the phase and save or update only their own decision for each test item. Testers cannot edit another person's response. |
| Phase Viewer / No access | A Viewer can review the phase but cannot respond and is never counted as Pending. No access means the phase and its responses are not visible. The Project Owner retains an emergency governance override for all phases. |
| Required responder | Only a Phase Admin or Tester can be required. Their item remains Pending until they save a decision; Phase Viewers never enter completion totals. |
Access, roles and responsibility
Project access is assigned by email and enforced in the database.
Project membership and phase access are separate: the same person can be Admin in Pre-FAT, Viewer in FAT and have no access to SAT.
Roles
| Owner | Project creator with full control over structure, settings, members, import/export and deletion. The Owner cannot be removed or downgraded by an Admin. |
|---|---|
| Admin | Manages structure, settings, reports and members. Cannot delete the project or change/remove the Owner. |
| Tester | Executes assigned tests and records their own participant responses. Cannot manage project structure, settings, imports or members. |
| Viewer | Read-only project and report access. Cannot execute tests or change project data. |
Access management
- Owner/Admin invites members and changes permanent roles from Project settings → Access management.
- When a phase is Draft, its Phase Admin assigns any project member as Admin, Tester, Viewer or No access.
- Required responder marks whose answer is expected; it does not silently create or consolidate a decision.
- The Owner record is protected and access changes remain auditable.
Security rules
- A participant may create or update only their own session response.
- One tester cannot edit another tester's decision, comment or response record.
- Owner/Admin manages the session and may review all permitted responses, but participant authorship remains separate.
- Visibility of other participants' responses follows the session access policy; users without project access cannot open the project by URL.
Offline and revoked access
- Previously authorized project drafts can remain on the same device and browser while offline.
- Revoking access does not remotely erase browser storage immediately, but the server rejects later synchronization without permission.
- Participant-session responses currently require a successful online save; do not assume an unsaved participant decision has reached the server.
Independent decisions and counts
- Responses are uniquely separated by project, session, participant and test-item ID.
- An assigned participant is Pending until they save a status for that item. Their saved status is then counted immediately in the item summary.
- The available participant statuses are Passed, Rejected, Blocked and N/A; Clear returns the response to Pending/not tested.
- Status changes save immediately. Comments save after approximately 800 ms or when the field loses focus.
- If saving fails, the interface restores the last server-confirmed value and shows an error. Refresh the responses before trying again.
- Two testers may review each other's responses only when visibility permits, but neither can write the other's decision.
Participant status legend
| Pending | The assigned participant has not saved a decision for this item in the active session. |
|---|---|
| Passed | The participant accepts the tested item for this session. |
| Rejected | The participant does not accept the tested result and expects correction or retest. |
| Blocked | A prerequisite, document, configuration or condition prevents the participant from completing the test. |
| N/A | The participant records that the item is not applicable in this session. |
Shared test criticality
Criticality belongs to the shared project test item and remains part of the established readiness/report logic.
| Standard | Normal FAT/SAT verification item. |
|---|---|
| Important | Important for operation, quality, documentation or handover. |
| Critical | A Failed or Blocked shared result blocks final report readiness. |
| Safety Related | Functional-safety item such as ESD, PSD, F&G, trip, permissive or interlock. |
| Cybersecurity Critical | OT-security item that must be accepted before final readiness. |
Test Criticality is a practical FAT/SAT prioritization and readiness-control field. It does not replace HAZOP, LOPA, SRS, SIL determination, IEC 61511 verification or IEC 62443 compliance assessment.
Results and reporting
- The item panel and row summary show participant counts for the active session.
- Participant responses are retained separately by phase and person, including revision history at database level.
- The current PDF still uses the shared legacy/consolidated project result. It does not yet generate a participant matrix or phase-filtered participant report.
- Before issuing the PDF, Owner/Admin should complete the project's agreed review and confirm the shared result without altering the underlying participant records.
- Recommended PDF settings remain A3, Landscape, one page per sheet and background graphics enabled.
Saving, connection and recovery
- Shared legacy project edits use the existing local-first save and synchronization workflow.
- Participant status buttons need an open session, assignment, execution permission and a successful server response.
- Wait for Saved before leaving the item. If an error appears, confirm connectivity and access, then retry.
- Do not clear site data before unsynchronized legacy project changes have been recovered.
Project controls and best practices
- Define phase names, acceptance criteria and required responders before opening a session.
- Use one session for one identifiable test round; create a later session for retest instead of rewriting history.
- Require participants to record their own technical judgement and explain rejected or blocked results in comments.
- Close a session only after checking Pending, Rejected and Blocked counts.
- Keep the shared final decision and the independent source responses conceptually separate.
- Verify imported data, references, criticality and report settings before formal FAT/SAT begins.