Can FAT replace SAT when the system is pre-staged?

No. Pre-staging and FAT reduce site risk, but SAT must validate the installed power, network, field wiring, live sources, site-specific failures, remote access, operational workflows and as-built condition.

Is SAT the same as commissioning?

No. SAT accepts the PrecisionDCOS installation and interfaces. Commissioning validates coordinated performance across the broader facility and may include OEM, electrical, mechanical, fire, gas, network, controls and other specialized scopes.

Can operational readiness be completed after go-live?

Some lifecycle items continue after service start, but the minimum people, access, procedures, monitoring, escalation, backup, recovery, support, evidence and customer-communication requirements must be accepted before the service is represented as operationally ready.

Who writes and witnesses the test procedures?

Responsibility is established by the project. PrecisionX may author and execute its product and integration procedures; owners, EPCs, integrators, commissioning authorities, OEMs, customers and regulated specialists witness or perform the tests applicable to their scope.

Can a failed test be accepted with a punch-list item?

Only through the defined exception process. The item must be classified, mitigated, assigned, dated and approved by the authorized parties. Blocking failures cannot be converted into conditional acceptance merely to preserve schedule.

Controlled acceptance guide

FAT, SAT and Operational Readiness Guide

A gated delivery model for proving the configured product, installed interfaces, degraded modes, procedures, evidence and operating organization before a PrecisionDCOS service enters production.

Talk to engineering Discuss the Technical Scope

Access: Open access
Resource type: Controlled engineering and acceptance guide
Primary audience: Owners, EPCs, integrators, commissioning authorities, contractors, operators, vendors and project managers
Product scope: All selected PrecisionDCOS components and interfaces

Different questions. Different evidence.

FAT, SAT, commissioning and operational readiness are related, but they do not prove the same thing.

Factory Acceptance Test validates the assembled and configured product before deployment. Site Acceptance Test validates the installed product, live interfaces and site-specific behavior. Commissioning integrates the system into the broader facility and confirms coordinated performance. Operational readiness confirms that people, access, procedures, support, spares, evidence and service governance are ready for sustained operation.

Passing one gate does not automatically pass the next. A device can pass FAT and still be wired, addressed, routed, labeled or integrated incorrectly on site. A technically complete installation can still be unready for service because users, procedures, escalation, backup, vendor support or customer communications are incomplete.

Acceptance is not a demonstration that the screen looks right. It is controlled evidence that the defined system behaves correctly in normal, failure and recovery conditions.

Gated delivery

Carry requirements and evidence from design through service commencement.

DesignGate 1

BuildGate 2

FATGate 3

DeployGate 4

SATGate 5

ReadinessGate 6

ServiceGate 7

Scroll horizontally to see the full table.

Reference table
Gate	Entry basis	Exit evidence
Approved design	Executed scope, requirements, interfaces, responsibilities and acceptance strategy	Approved Basis of Design, authority schedule, architecture and submittal plan
Ready for FAT	Approved hardware, software, configuration and test procedure	Build record, configuration baseline, simulated sources, prerequisites and open-item list
FAT accepted	Executed factory procedures	Test results, exceptions, corrective actions, configuration, backup and release record
Ready for SAT	Installed power, network, pathways, devices, source interfaces and site prerequisites	Installation inspection, as-built updates, source availability and coordinated test plan
SAT accepted	Executed site procedures	Live-interface, failure, recovery, alarm, security and operational test evidence
Operationally ready	Users, procedures, support, spares, records and service integrations complete	Readiness checklist, training, runbooks, escalation, backup/restore and accepted exceptions
Service commenced	Formal acceptance of agreed readiness and residual risk	Service-start record, operating baseline, customer communication and lifecycle ownership

Discovery
Basis of Design
Detailed engineering
Submittals
Procurement
Staging and configuration
Factory Acceptance Test
Site installation support
Site Acceptance Test
Commissioning integration
Operational readiness
Service commencement
Lifecycle operation and optimization

Prove the configured product

FAT validates the delivered baseline before the site becomes the test bench.

Verify approved equipment, options, versions and quantities
Verify panel, rack, server, network and power assembly
Verify labeling, terminals, harnesses, ports and internal wiring
Load and record the controlled software and configuration baseline
Verify identity, time, certificates, roles and administrative access
Exercise representative acquisition, alarms, quality and staleness
Validate IO, output arbitration and GMS monitor-only boundaries where included
Validate network segmentation, routing, firewall, OOB and configuration backup
Exercise node, interface, service and power failures appropriate to the build
Validate buffering, replay, backup, restore and recovery assets
Verify dashboards, reports, notifications and workflow integrations
Capture exceptions, corrections, retest and release evidence
Produce a transportable backup and installation package

FAT may use approved simulators, representative devices or recorded interfaces where live site equipment is unavailable. The test record must identify what was simulated, what remains for SAT and any assumption that could change site behavior.

FAT evidence package: approved FAT procedure and witness record; equipment and serial-number record; firmware, OS, application and configuration versions; configuration export and checksum where appropriate; network and port baseline; user, role and certificate baseline; point, alarm and source simulation record; test results and screenshots or machine evidence; failure and recovery results; backup and restore record; open-item and deviation register; corrective action and retest; shipment or deployment release.

Prove the installed system

SAT validates actual power, network, field interfaces and operating behavior at the site.

Verify installed equipment, location, power, grounding, environment and access
Verify field wiring, polarity, shield, termination, labeling and source identity
Verify network ports, addressing, routing, segmentation, DNS, NTP and remote access
Verify live protocol, API, event, trap, serial and physical-point acquisition
Verify source time, receive time, quality, range, units and staleness
Verify alarm priority, notification, escalation, maintenance and suppression
Verify local, hosted and customer views
Verify OOB and recovery from the actual authorized remote location
Exercise node, link, power, collector, WAN, identity and source failures as applicable
Verify approved commands, feedback and inhibition only where separately included
Verify GMS local operation remains independent and PrecisionDCMS status remains monitor-only
Verify incident, work, change, maintenance and evidence integrations
Verify backup, restore and post-failure return to normal
Update as-built, point, asset, dependency and authority records

SAT validates the accepted site configuration and interfaces. It does not replace the OEM's own startup, functional testing, electrical protection testing, fire-alarm acceptance, gas-system proof testing, mechanical commissioning or other regulated and specialized work.

Prove the organization can operate it

Technical completion is not service readiness.

People and coverage

Named customer, PrecisionX, site, vendor, carrier, security, commissioning and emergency contacts; staffing, hours, on-call and field-response coverage.

Identity and access

Production users, roles, MFA, privileged access, service identities, customer access, emergency access, credential custody and deprovisioning.

Procedures and runbooks

Alarm, incident, escalation, change, maintenance, impairment, backup, restore, failover, recovery, safety, communications and service-restoration procedures.

Monitoring and workflow

Production sources, dashboards, alerts, tickets, incident, work, maintenance, change, notification, status and customer workflow.

Asset and configuration

As-built asset, interface, point, dependency, firmware, configuration, certificate, license and support records.

Backup and recovery

Successful backup, protected storage, restore validation, recovery image, spare, replacement and disaster-recovery responsibilities.

Vendor and carrier support

Entitlements, portals, contracts, escalation, RMAs, circuit IDs, maintenance notices, warranty and renewal dates.

Spares and field execution

Critical spares, tools, access, logistics, qualified labor, dispatch, chain of custody and replenishment.

Evidence and assurance

Acceptance packages, training, access, changes, backups, tests, exceptions, risk acceptance and control-owner records.

Customer and service governance

Service scope, operating tier, service clocks, severity, communications, review cadence, reporting, exclusions, handback and change process.

Test what happens when the architecture is not healthy

Normal-state demonstrations are insufficient for critical operations.

The failure-mode matrix records, for each injected condition, the expected state, operator visibility, automated behavior, manual response, recovery and evidence. Required injected conditions include:

Loss of one Field Core
Loss of one NX Node
Loss of a Standard-node power source
Loss of an access or aggregation switch
Loss of a collector or proxy
WAN or tunnel loss
Hosted-service impairment
DNS or NTP impairment
Identity-service impairment
Database or storage impairment
Event storm
Source-system or API unavailable
Sensor open, short, out-of-range or stale
A/B source disagreement
Output-authority conflict
Backup failure
Restore to replacement hardware
OOB primary-path loss
Carrier maintenance or circuit failure
Security controller or VMS impairment
Primary NOC unavailable
Regional recovery activation where included

Each test must define prerequisites, injected condition, expected local and hosted state, alarms, quality, workflow, command inhibition, customer impact, recovery sequence, return-to-normal validation and required evidence. Do not test a hazardous or destructive condition without the approved safe simulation, OEM procedure, site authorization and qualified personnel.

Controlled acceptance record

Preserve what was tested, what passed and what remains open.

Test evidence must identify the requirement, procedure, environment, version, participant, date, source, expected result, actual result, attachments, exception, corrective action, retest and approval.

Blocking: Prevents progression to the next gate or service commencement
Conditional: May proceed only with documented mitigation, owner, due date and approval
Deferred: Scheduled for a later approved phase because the prerequisite is genuinely unavailable
Informational: No acceptance impact, retained for lifecycle awareness

Do not convert an untested requirement into a pass. Mark it not tested, blocked or deferred with the reason and controlling approval.

Screenshots may support a result, but they should not be the only evidence where machine logs, configuration exports, source records, test instruments or signed procedures provide stronger proof. Evidence remains linked to the tested baseline and version.

Formal transition to operations

Start service with an accepted baseline and named ownership.

Effective date and time
Sites, systems and services entering scope
Operating-authority tier
Monitoring and support hours
Customer and PrecisionX responsibilities
Accepted configuration and document baseline
Open exceptions and risk acceptance
Active users and access methods
Escalation and communication paths
Backup, restore and recovery status
Spares and field-response status
Vendor and carrier support status
Reporting and service-review cadence
Warranty and lifecycle dates
Handback and exit records
Approval signatures or equivalent controlled acknowledgment

Service commencement does not erase unresolved risk. It records the accepted production boundary, residual exceptions, accountable owners and the lifecycle processes that will manage them.

The controlled guide includes

Delivery and acceptance lifecycle
Gate-entry and gate-exit criteria
FAT planning and prerequisites
Hardware, software and configuration verification
Source simulation and live-interface testing
SAT and commissioning coordination
Failure and degraded-mode test matrix
IO, command and GMS safety boundaries
Network, OOB and connectivity acceptance
Security-system acceptance
Backup, restore and recovery testing
Operational-readiness checklist
Evidence package and exception control
Service-commencement record
Roles, witnesses, approvals and handoff
Lifecycle retest and change implications

Frequently asked

Questions and answers

Can FAT replace SAT when the system is pre-staged?: No. Pre-staging and FAT reduce site risk, but SAT must validate the installed power, network, field wiring, live sources, site-specific failures, remote access, operational workflows and as-built condition.
Is SAT the same as commissioning?: No. SAT accepts the PrecisionDCOS installation and interfaces. Commissioning validates coordinated performance across the broader facility and may include OEM, electrical, mechanical, fire, gas, network, controls and other specialized scopes.
Can operational readiness be completed after go-live?: Some lifecycle items continue after service start, but the minimum people, access, procedures, monitoring, escalation, backup, recovery, support, evidence and customer-communication requirements must be accepted before the service is represented as operationally ready.
Who writes and witnesses the test procedures?: Responsibility is established by the project. PrecisionX may author and execute its product and integration procedures; owners, EPCs, integrators, commissioning authorities, OEMs, customers and regulated specialists witness or perform the tests applicable to their scope.
Can a failed test be accepted with a punch-list item?: Only through the defined exception process. The item must be classified, mitigated, assigned, dated and approved by the authorized parties. Blocking failures cannot be converted into conditional acceptance merely to preserve schedule.

Related resources

PrecisionDCMS

Define the acceptance strategy early

Make the required behavior testable before procurement and installation.

Share the Basis of Design, project schedule, system boundaries, commissioning plan and operating model. PrecisionX will identify the applicable factory, site and readiness gates.