OperantSolo publishes practical n8n workflows and fixes for solo operators. These notes explain how to read an article’s evidence. They do not certify a workflow for production.
Recorded learning-lab evidence
The recorded evidence includes 50 expression cases, 8 XML cases, 19 CSV parser tests, and real form/Slack approval, rejection and timeout tests. These were bounded lab tests, not production benchmarks.
What a pass means
A pass means the observed output matched the documented expected result for that case in that environment. Record the exact n8n version, test date, node settings, sample input, expected output, observed output and limits for each lab. Never infer a version from a publication date.
Failure injection
For a new lab, deliberately test relevant missing fields, invalid inputs, duplicate events, unsuccessful requests and timeouts. Approval labs should cover approval, rejection and timeout. Record only cases actually run; label planned cases as proposed.
What is not covered
Small lab runs do not prove production uptime, throughput, security certification, concurrency safety or compatibility with every n8n release. External-service availability, credentials and private customer data are outside a fixture-only test unless the article states otherwise.
Untested adaptations
A changed provider, node, input or deployment should be labeled “Adaptation, not tested.” Keep its proposed behavior separate from the original lab’s results. A workflow file or screenshot is not proof that every branch passed.
Corrections
Email hello@operantsolo.com with the article URL, n8n version and redacted expected/observed results. Do not send credentials or private customer records. Editorial Policy.