March 2026 archive: an operational acceptance checklist for ComfyUI
A graph that works once is not yet an operational service. Before relying on it for repeated delivery, verify saved outputs, recoverable configuration, failure handling and the permissions of every execution route, using the same workload that operators will actually run.
Define the service boundary
Write down who starts a job, which inputs are permitted and where the final files must appear. Identify whether the graph is entirely local or calls an external service. A local user interface does not prove that every extension or model integration remains inside the same data boundary.
For any remote component, review that provider's current documentation and terms for the actual endpoint. OpenAI's API data documentation, for example, applies to its covered API services and is not a statement about arbitrary ComfyUI extensions. Record the route rather than inheriting a generic privacy assumption.
Test the full delivery path
Run the intended workload with permitted inputs and check the final saved file, its format and its destination. Include optional stages that are part of the promised delivery. A completed sampler and a browser preview are insufficient if a later save or enhancement step fails.
Measure setup and repeated execution separately. Include human review and correction where the output requires them. Keep unsuccessful jobs in the record and establish how an operator can tell whether retrying is safe, necessary or likely to repeat the same underlying fault.
Make configuration recoverable
Preserve the accepted graph, dependency versions and model identities together. Keep a known working configuration before updating components. Test changes in a recoverable copy, and identify the point at which the change must be rejected rather than continuing to modify a failing production environment.
Check that an operator other than the author can follow the recovery instructions with the permissions available to them. Do not place secrets in shared workflow exports or public logs. Document where authorised credentials are managed without copying the credential values into the run record.
Set observable acceptance criteria
State the required output checks, allowed workload and failure-reporting route before release. Verify those criteria after restart and after a representative dependency change. Treat uncertain capacity as a limit to investigate, not as permission to promise an unmeasured throughput target.
This archive provides an acceptance checklist rather than a claim that any particular deployment has passed it. Retain the actual evidence for each environment: conditions, logs, saved outputs and the person responsible for accepting them. Revisit the checklist when inputs, models, hosting arrangements or delivery requirements change, keeping previous decisions available for comparison.