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.
Start with these six steps
Follow this route for your first project. Each card opens the relevant instructions.
- Prepare the projectCreate the project, import the checklist and define acceptance criteria.
- Assign responsibilitiesInvite members and set each person's access for the phase.
- Open a test sessionSelect the phase and review participants before opening.
- Record your responseSave your own decision and technical comment; check confirmation.
- Resolve findingsReview differences, track corrective action and run a retest.
- Review and hand overConfirm shared results and prepare the PDF report.
What you can do
Checklists and ExcelHierarchical tests, standard templates, import and export.Multiple test phasesInternal, FAT, SAT and retest sessions with separate records.Controlled collaborationProject and phase roles, independent responses and counts.Punch items and evidenceTechnical findings, severity, owners and corrective action.Readiness and reportingCriticality, acceptance blockers, report profiles and PDF.Local saving and recoveryLocal drafts of shared data and server synchronization.
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.
Engineering tools, references and checklist configuration
Adapt the checklist to the control-system scope and approved engineering documents.
- Configure package procedures, references, visible detail fields, order and report inclusion. Record document titles, numbers, revisions and availability; attachments can be added to areas, packages and items.
- Use safety-function, SIL-relevance and OT-security fields where applicable. The Cybersecurity FAT/SAT module covers practical checks such as access control, segmentation, hardening and recovery; it is not an IEC 62443 certification.
- Use search, filters, Next open, Next failed and Next punch to find items. Review progress, criticality and cybersecurity summaries. Report profiles, logos, notes and attendance/signature fields support handover; signature fields are project records, not a certified digital-signature service.
Excel import and export
Use the standard workbook and check imported data before formal testing.
- Download the template above, keep its sheet and column structure, and complete the project and test data. Owner/Admin can use Data tools → Import Excel. Export a backup before importing into a project with existing data; then check hierarchy, counts, references and acceptance criteria.
- Export workbook downloads the current shared project data, including Punch_List. It is not a participant-response matrix or a replacement for the PDF. Attachment names are exported; the workbook is not a complete backup of attached files.
Punch items, evidence and retesting
Make every finding understandable and actionable for the next reviewer.
- For Rejected or Blocked, record the equipment tag, test conditions, expected and observed values, and reference. Complete shared punch evidence, severity, responsible person and due date. An individual's Rejected response does not automatically change the shared result or create its punch entry.
- After correction, create a Punch Retest session and record the new result there. Keep the original responses. Reconcile the shared punch list and exported Punch_List before handover.
Worked example: one item, two testers
Two required testers check a high-pressure alarm in a FAT session.
- One records Passed. The other observes excessive delay and records Rejected with a technical comment. Both have responded, but the disagreement remains unresolved.
- The team reviews the finding and confirms the shared item result under the agreed acceptance procedure. Record the retest in a new session. The current PDF uses the shared result, rather than printing a matrix of these two responses.
Troubleshooting
Check the active phase, your access and the save confirmation first.
- Disabled response buttons: the session must be Open and you must be its Admin or Tester. Viewers cannot respond. Participant changes are allowed only in Draft; closed sessions cannot reopen. A comment alone does not replace saving a status.
- Save errors: check connectivity, sign-in and project/phase permissions, refresh responses and retry. Shared results use Not Started, Passed, Failed, Punch, Blocked and N/A; individual responses use Passed, Rejected, Blocked and N/A. Clear returns your response to Pending.
- No critical blockers does not mean all tests or required responses are complete. The PDF uses shared results; review these separately from participant counts. For clipped print tables, check A3 landscape, one page per sheet, background graphics and print scale.
- Local drafts stay with the same browser, device and site address. Before moving from the old website to kalmanfat.com, synchronize or export outstanding shared changes at the old address. Participant responses require successful online saving.
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.